Introduced additional cutoff_ng variable in order to avoid overwriting wf_ng when reading an existing ndb.cutoff.
wf_ng is read from WF_G_COMPONENTS in ns.db1, while cutoff_ng is read from PARS (it is also a dimension of CUT_BARE_QPG) in ndb.cutoff.
The two values could be different if, for example, the user has previously calculated the cutoff with decreased FFTGvecs value. Despite this, during setup, io_COL_CUT is always called and thus the value of wf_ng was always overwritten if an existing database was found.
This could create issues when working with WF_load in susbsequent runs, because it can lead to the case where the number of wavefunction components wf_ncx is larger than the overwritten wf_ng.
NB: I changed only io_COL_CUT by introducing cutoff_ng. The Coulomb driver and all the geometry subroutines that compute the various cutoffed potentials still use wf_ng. In principle I don't see any obvious problems since during writing, cutoff_ng is set to wf_ng by default.
Fix for issue #75.
Introduced additional
cutoff_ngvariable in order to avoid overwritingwf_ngwhen reading an existingndb.cutoff.wf_ngis read fromWF_G_COMPONENTSinns.db1, whilecutoff_ngis read fromPARS(it is also a dimension ofCUT_BARE_QPG) inndb.cutoff.The two values could be different if, for example, the user has previously calculated the cutoff with decreased
FFTGvecsvalue. Despite this, during setup,io_COL_CUTis always called and thus the value ofwf_ngwas always overwritten if an existing database was found.This could create issues when working with
WF_loadin susbsequent runs, because it can lead to the case where the number of wavefunction componentswf_ncxis larger than the overwrittenwf_ng.NB: I changed only
io_COL_CUTby introducingcutoff_ng. The Coulomb driver and all the geometry subroutines that compute the various cutoffed potentials still usewf_ng. In principle I don't see any obvious problems since during writing,cutoff_ngis set towf_ngby default.