Use of different diagonalization methods

[JulioNascimento500]

Dear contributors,

First of all thanks for releasing the d3q code, I'm hopeful it will be very helpful in my research.

I'm starting this discussion here because I've been having some issues with the code where too many bands are not being converged. I tried solving the problem by running nscf runs with different parameters and the only solution that gave me consistent results was changing the diagonalization method from 'david' to 'cg'.

I tried changing it, by changing the source code variables from:

isolve = 0
david = 4

to:

isolve=1
david=1

(as indicated in the Quantum Espresso source code setup_nscf.f90)

in the file run_nscf_d3.f90 and recompiling it, but the code used the Davidson method anyway.

Is there something that I'm missing or some guidance that could help me get around it?

kind regards,
Julio

[paulatz]

Hello Julio,
I have never done it myself, but I think setting isolve=1, david=1 is correct (as long as you recompile the code afterwards)

Are you using CG ins pw.x? Because there is not specific reason for the NSCF convergence in d3q to be harder to converge than the scf one in pw.x.

Maybe if you have a large number of electrons, the threshold becomes too strict. Can you change at the line 202 of run_nscf_d3.f90
ethr_nscf = 1.0D-12 / nelec
to something like
ethr_nscf = 1.0D-12
?

It is an old default that "should be good for all cases" but has probably never been tested. Let me know if this solves your problem, this way I can fix it in future releases.

cheers

[JulioNascimento500]

Thanks for the reply Dr Paulatto,

I tried reducing the ethr_nscf but still no luck.

It worked by changing the diagonalization method to 'CG' instead of 'david'.

Just a quick follow up question:

Does d3q carry the disk_io variable from the scf calculation namelist?

i.e. if I set disk_io = 'nowf' in the scf calculation will the io be reduced in the d3q run?

kind regards

[paulatz]

i.e. if I set disk_io = 'nowf' in the scf calculation will the io be reduced in the d3q run?

I'm not sure, d3q was mostly developed before this option, but it uses standard i/o subroutine, so there is a chance that it could work. However, unperturbed wfcs are only a small part of the disk i/o in d3q. Most of the i/o comes from wavefunction perturbations (d^q wfc) which are written directly. One could convert those calls to "davcio" that involve iu_dwfc, to save_buffer/read_buffer and have them stored in memory (feel free to send a patch if you do).

That said, d3q does not enforce disk flushing or consistency, unless you explicitly set safe_io=.true., which is very slow. This means that the operating system should cache all the "disk" writes in memory if it can. If you want to be absolutely sure that everything stays in RAM, you can set d3dir to a ramdisk location (typically /dev/shm is available on modern Linux), but then, if there is not enough space something ugly may happen.