Skip to Content.
Sympa Menu

forum - Re: [abinit-forum] ecutsm and electronic convergence

forum@abinit.org

Subject: The ABINIT Users Mailing List ( CLOSED )

List archive

Re: [abinit-forum] ecutsm and electronic convergence


Chronological Thread 
  • From: "Josef W. Zwanziger" <jzwanzig@jzwanzig.org>
  • To: forum@abinit.org
  • Subject: Re: [abinit-forum] ecutsm and electronic convergence
  • Date: Thu, 18 Dec 2008 05:57:32 -0800 (PST)

Hi,

I replicated Emmanuel's problem with paral_kgb set to 1. With kpt only parallelization, everything works fine (with and without ecutsm). It seems to only go bad with band parallelization turned on.

Joe
 
Josef W. Zwanziger
Professor of Chemistry
Canada Research Chair in NMR Studies of Materials
Director, Atlantic Region Magnetic Resonance Centre
Department of Chemistry
Dalhousie University
6274 Coburg Road
Halifax, Nova Scotia B3H 4J3 Canada
tel: +1.902.494.1960
fax: +1.902.494.1310
web: http://jwz.chem.dal.ca
jzwanzig@jzwanzig.org,jzwanzig@dal.ca



From: BOTTIN Francois <francois.bottin@cea.fr>
To: forum@abinit.org
Sent: Thursday, December 18, 2008 9:48:05 AM
Subject: Re: [abinit-forum] ecutsm and electronic convergence

Hi Emmanuel, Joe and Marc,

Emmanuel Arras a écrit :
I got the same results as you : It works just fine without band parallelization.
The parameters I use are :
paral_kgb 1
fftalg 401
wfoptalg 4
noalg 4

I'm afraid I'm not qualified to look into this any further... I'll just have to avoid the use of ecutsm in the futur, and hope the bug has no other consequences...

Thanks a lot for the help.

Emmanuel ARRAS


PS : the input file I gave you was an old version. I agree with everything you say. (However, it is interesting to notice that it is actually not necessary to define paral_kgb 1 to turn on the band parallel stuff. Some how, it works without it, but twice slower. Thus it can be confusing).

Your problem is very interesting and I have paid a large attention to the discussion
(I am concerned and perhaps implicated in the problem...). I have a few comments and questions about your problem.

Emmanuel, I think the band/FFT/kpoint parallelism is not allowed without the explicit use of paral_kgb=1.
(see http://www.abinit.org/Infos_v5.6/input_variables/varpar.html#paral_kgb)
The default is paral_kgb=0, which is the traditionnal k-point-only parallelization.
So, if you don't explicitely write paral_kgb=1, you work on the k-point-only parallelization.
In this case, there is no use of npband, npkpt and npfft (if I'm right, the echo of outvars is probalby misleading), and you just use the number of processors you require at the execution.
This probably explains your scaling and timing report.

I have also some questions: Is it the triple parallelization (paral_kgb=1, npkpt/=1, npband=npfft=1),
                                                   the band level of parallelization (paral_kgb=1 and npband/=1) or
                                                   the LOBPCG algorithm (paral_kgb=0, wfoptalg=4 with or without nloalg=4 and fftalg=401)
which causes some troubles of convergence, with respect to sequential CG and parallel-k-point CG (paral_kgb=0, wfoptalg=0)?

Emmanuel, could you send me your LAST input and output files (as well as the pseudo). Many thanks.
Perhaps, you detect a problem which is present in the triple parallelization or LOBPCG since a long time and
is related to other troubles of convergence seen elsewhere.
Good work,
Francois
-- 
##############################################################
Francois Bottin                    tel: 01 69 26 41 73
CEA/DIF                            fax: 01 69 26 70 77
BP 12 Bruyeres-le-Chatel         email: Francois.Bottin@cea.fr
##############################################################



Archive powered by MHonArc 2.6.15.

Top of Page