The ABINIT Users Mailing List ( CLOSED )

[Xavier Gonze <gonze@pcpm.ucl.ac.be>]

Dear Gilles,


On 04 Jun 2007, at 18:30, Gilles Zerah wrote:

> Dear Maurice,
>
> Note that the prtden and prtwfk flargs are not working yet in the  
> MPIFFT mode (it is currently under tests) , and this might induce  
> problems.
> Also I am not sure the = sign works (e.g. for ixc)

Although it is not mentioned in http://www.abinit.org/Infos_v5.3/ 
users/abinis_help.html , the = sign should work.
I wonder why this is not mentioned, actually ...

Xavier

> Cheers,
>
> Gilles
>
> > Dear Gilles,
> >
> > Here is the input file I have been using:
> >
> > --------------------------------------------------------------------- 
> > -------------------------------------------------------
> > #Definition of the unit cell
> > acell 13.1493536801862057 15.1976493759670106 14.3247149284289197  
> > angstrom
> >
> > #Definition of the planewave basis set
> > ecut   850 eV # Maximal kinetic energy cut-off, eV
> >
> >
> > #Definition of k-points
> > nkpt 1    #Definition of the SCF/Ionic relaxation procedure
> > ionmov  3           # Use the modified Broyden algorithm
> > ntime  1000         # Maximum number of Broyden "timesteps"
> > tolmxf 1.d-3       # Stopping criterion for the geometry  
> > optimization : when
> >                     # the residual forces are less than tolmxf,  
> > the Broyden
> >                     # algorithm can stop. The maximum force should  
> > be less than 0.015 eV/A
> > toldff 1.0d-4       # Will stop the SCF cycle when, twice in a row,
> >                     # the difference between two consecutive  
> > evaluations of
> >                     # forces differ by less than toldff (in  
> > Hartree/Bohr)
> >
> >
> >
> > #Parallelization specifications
> > npband 16 npfft 1
> > timopt -1
> > fftalg 401
> > nloalg=4
> > wfoptalg 4
> > fft_opt_lob 2
> > iprcch 0
> > intxc 0
> > istwfk 1 #Do not take advantage of time-reversal symmetry
> >
> > #Exchange-correlation functional
> > ixc=11            #PBE
> >
> > #Electron bands
> > nband 400  #Output options
> > enunit 2    #Print energies in Hartrees and eV
> > prtden 1
> > prtwf 1
> > prtgeo 1
> > chkexit 1 #Check for soft exit
> >
> > #Definition of the atoms
> > natom  288
> > ntypat 2
> > typat  96*2 192*1
> > znucl  1 8
> > xred
> >  0.0845189269132292  0.0836540240171464  0.0938979747640865
> >  0.2509028928683434  0.1665132426871575  0.1569498160978585
> >  0.0832245541612382  0.0833713592505196  0.4056550678678152
> >  0.2499432940905800  0.1673060143511642  0.3441180505891231
> >  0.2505816959654373  0.3327266212961689  0.0944438710086825
> >  0.0832112596230180  0.4163646775571404  0.1555981974101562
> >
> > .....
> >
> > --------------------------------------------------------------------- 
> > --------------------------------------------------------------------- 
> > ------------------------------
> >
> >
> > gilles zerah wrote:
> >
> > > Dear Maurice,
> > >
> > > The best distribution of npbands and npfft depends presumably  
> > > upon the implementation of MPI you are using and of many
> > > other parameters. Now, it should work for this distribution, but  
> > > the case npfft=1 is treated differently.
> > > Is it possible you post your input file?
> > >
> > > Gilles
> > >
> > > > Dear all,
> > > >
> > > > I noticed strange behavior while using the bands/fft  
> > > > parallelization features of abinip (compiled with -DMPI_FFT  
> > > > preprocessor flag),
> > > > running on an SGI Altix system with 16 CPU´s.
> > > >
> > > > The calculation in question involves a geometry optimization  
> > > > using only the gamma point:
> > > >
> > > > 1) The first calculation was run using the parameters:
> > > >
> > > > npbands=8, npfft=2
> > > >
> > > > This calculation runs fine and the geometry optimization  
> > > > converges without any trouble.
> > > >
> > > > 2) Then I tried a different distribution, using the parameters
> > > >
> > > > npbands=16, npfft=1
> > > >
> > > > According to the documentation, this should be more efficient  
> > > > than the first choice.
> > > >
> > > > But while running this calculation something strange happens.  
> > > > After a while, only a few
> > > > of the 16 CPU´s are actually processing, with the remainder in  
> > > > "uninterruptable sleep".
> > > > This already occurs during the first SCF cycle, effectively  
> > > > interrupting the progress of
> > > > the calculation.
> > > >
> > > > Any ideas?
> > > >
> > > > Cheers,
> > > >
> > > > Maurice
>
> <gilles.zerah.vcf>