How important is it to store 1WF files?

Hi everyone,

I’ve been using Abinit for a couple of months only, so I’m sorry if my question sounds dumb. I’ve been asked by my supervisor to calculate the phonon dispersion for a material that has 7 atoms in the unit cell. I’m using PAW with an energy cutoff of 15 hartree, an 8x8x8 k-point grid and a 4x4x4 qpoint grid. I’ve just adapted one of the input files from the DFPT tutorials (I’m a new user in the forum so it looks like I’m not allowed to upload files, otherwise I would’ve uploaded my input file…).

Since I’m doing these calculations on a cluster where I’ve been allocated a quota of space of 100 GBs, I’m actually worried that the space won’t be enough because the first order WF file that are being produced are very heavy (around 1GB each). So, my question is: how important is it for Abinit to store these files after it has moved on from one qpoint to the next? From what I understand, the important information is all stored in the derivative database (DDB file), which is way lighter (around 2 MBs). Can I just remove the 1WF files from older datasets while Abinit is running? Is there a way to tell Abinit to not store these files once it has moved to the next dataset?

Again, I’m sorry if the question is dumb and I thank you in advance for any answer/suggestion.

Hi Luca,

for normal phonon runs there is no need to keep the 1WF files. You can avoid even printing them with prtwf 0 and prt1wf 0

However, if you want to calculate Raman intensities or electro - optic tensors etc then you need to keep all of the 1WF files, as these 3rd derivatives are calculated from the 2n+1 theorem by mixing different 1st order derivative quantities.

Remember you need to keep the 1WF files for the DDK in case you want to run DDE calculations, they are an intermediate step. However there are only 3 of them, so the damage is limited.


1 Like

Hi @mverstra ,

thanks for your answer! Unfortunately if I try to use prt1wf I get an error telling me this variable doesn’t exist :confused:


next version 9.8 then. For the moment prtwf should do the trick for all WF files

1 Like

It looks like in my version (9.4.2) using prtwf 0 just makes it so the WFK file doesn’t get printed, but the 1WF still gets printed… But thanks for the answer nevertheless, I’ll just manually remove them to save space!


I came to the same conclusions as Luca, that prt1wf is not yet implemented in ABINIT v 9.6, and that prtwf 0 does not suppress the writing out of the 1WF files in a DFPT calculation. In my case, these files range from 38 to 68 GB each, posing a serious problem for my storage quotum on the cluster I’m using.

Has anyone found a solution to this problem?

1 Like

@JBekaert I haven’t found any solution unfortunately. @mverstra do you think it would be easy for us to go and change the fortran code on our own Abinit installation to make it so the 1WF file doesn’t get printed?

1 Like

Hello Jonas and Luca,

sure: either you wait patiently for 9.8, or (if you’re like me), edit the file

in your abinit sources, and you can comment or condition the line (2109 for me) with
call wfk_write_my_kptbands(…)
and recompile

Note that if you comment it you will not even have the DDK file outputs, probably not what you want. The dtset%prtwf variable should be accessible in this routine, so
if (dtset%prtwf != 0) then
call wfk_write_my_kptbands(…)
end if

may be enough. A possibility is that your 1WF files are not fully converged, in which case abinit enforces the output, to make sure you can restart (new prtwf -1 behavior introduced at some point).



Hi Matthieu,

I tested the second option, with the condition, and it works as intended.

Thanks a lot!

Dear Matthieu and others,
Thanks very much for this discussion which is related to the question of how one might efficiently calculate phonons for large unit cell materials. I too tried to use prtwf 0 but found that the very large _1WFx files are still being written. (By the way – prt1wf does not seem to exist for version 9.8.1 which was released yesterday (1/2/2023).) Most likely I am making a very silly mistake. For example, the following *abi file for NaCl writes out all _1WFx files while my intent was to only write it for datasets 4-10. Thanks in advance for any suggestions. Natalie Holzwarth
-----*abi file for NaCl phonons----

Crystalline NaCl : computation of the phonon spectrum

ndtset 10
#Set 1 : ground state self-consistency

getwfk1 0 # Cancel default
kptopt1 1 # Automatic generation of k points, taking
# into account the symmetry
nqpt1 0 # Cancel default
tolvrs1 1.0d-18 # SCF stopping criterion (modify default)
rfphon1 0 # Cancel default
prtwf1 1

#Q vectors for all datasets

#Complete set of symmetry-inequivalent qpt chosen to be commensurate

with kpt mesh so that only one set of GS wave functions is needed.

#Generated automatically by running GS calculation with kptopt=1,

nshift=0, shiftk=0 0 0 (to include gamma) and taking output kpt set

file as qpt set. Set nstep=1 so only one iteration runs.

 nqpt   1            # One qpt for each dataset (only 0 or 1 allowed)
                     # This is the default for all datasets and must
                     #  be explicitly turned off for dataset 1.

 qpt2              0.00000000E+00  0.00000000E+00  0.00000000E+00
 qpt3              0.00000000E+00  0.00000000E+00  0.00000000E+00
 qpt4              2.50000000E-01  0.00000000E+00  0.00000000E+00
 qpt5              5.00000000E-01  0.00000000E+00  0.00000000E+00
 qpt6              2.50000000E-01  2.50000000E-01  0.00000000E+00
 qpt7              5.00000000E-01  2.50000000E-01  0.00000000E+00
 qpt8             -2.50000000E-01  2.50000000E-01  0.00000000E+00
 qpt9              5.00000000E-01  5.00000000E-01  0.00000000E+00
 qpt10            -2.50000000E-01  5.00000000E-01  2.50000000E-01

#Set 2 : Response function calculation of d/dk wave function

iscf2   -3         # Need this non-self-consistent option for d/dk

kptopt2 2 # Modify default to use time-reversal symmetry
rfphon2 0 # Cancel default
rfelfd2 2 # Calculate d/dk wave function only
tolwfr2 1.0d-22 # Use wave function residual criterion instead
prtwf2 1

#Set 3 : Response function calculation of Q=0 phonons and electric field pert.

getddk3 2 # d/dk wave functions from last dataset
kptopt3 2 # Modify default to use time-reversal symmetry
rfelfd3 3 # Electric-field perturbation response only

#Sets 4-10 : Finite-wave-vector phonon calculations (defaults for all datasets)

getwfk 1 # Use GS wave functions from dataset1
kptopt 3 # Need full k-point set for finite-Q response
rfphon 1 # Do phonon response
rfatpol 1 2 # Treat displacements of all atoms
rfdir 1 1 1 # Do all directions (symmetry will be used)
tolvrs 1.0d-8 # This default is active for sets 3-10
prtwf 0 # donot save wfn??
prtpot 0 # donot save pot??
prtden 0 # donot save den??

#Common input variables

paral_kgb 1
autoparal 1
timopt -2

#Definition of the unit cell
acell 3*10.3340116399024

rprim 0.5 0.5 0.0
0.0 0.5 0.5
0.5 0.0 0.5

#Definition of the atom types
ntypat 2
znucl 11 17

#Definition of the atoms
natom 2
typat 1 2
0.0 0.0 0.0
0.5 0.5 0.5

#Definition of the planewave basis set
ecut 35.0 # Maximal kinetic energy cut-off, in Hartree
pawecutdg 35.0
usexcnhat 0
pawxcdev 0
chksymtnons 0

#Definition of the k-point grid
ngkpt 8 8 8
nshiftk 4
shiftk 0.5 0.5 0.5
0.5 0.0 0.0
0.0 0.5 0.0
0.0 0.0 0.5

#Definition of the SCF procedure
nstep 120 # Maximal number of SCF cycles
nband 8
diemac 9.0 # Although this is not mandatory, it is worth to
# precondition the SCF cycle. The model dielectric
# function used as the standard preconditioner
# is described in the “dielng” input variable section

add to conserve old < 6.7.2 behavior for calculating forces at each SCF step

optforces 1

pp_dirpath “/deac/phy/natalieGrp/natalie/wfurc9/EL6/rc9/PAWatoms/poscorenhatPBESOL/libxc/”
pseudos “Na/Na.GGA_X_PBE_SOL+GGA_C_PBE_SOL-paw.xml, Cl/Cl.GGA_X_PBE_SOL+GGA_C_PBE_SOL-paw.xml”

Apologies. At the time that I posted this message, I was using version 9.6.2 and now I see that the issue has been resolved in 9.8.1. That is prtwf 0 does now prevent the writing out of the very large wavefunction derivative files. Thanks so much. Keep up the great work. Natalie