[QE-users] pw_readschema_file failed retrieving input info from xml file ph.x using grid in qe-6.3-bkp and 2D cutoff

[Pietro Davide Delugas]

Hi

Thanks for reporting the issue.

As for the message about the missing input element, no problem it is the 
desired behavior, run_nscf started bby ph would not be able to fill 
correctly the
input element because the variable in input_parameters are not 
initialized, so the element is  not printed at all.

The isseus comes from the fact that in writing the status of the 2D 
cutoff we are currenlty using the value stored in input_parameters 
which, not being initialized, has in this case a wrong .false. value.

I will fix the issue in the develop, for further information check this 
issue on gitlab https://gitlab.com/QEF/q-e/issues/102

Pietro



On 03/11/2019 09:11 PM, Raphael Longuinhos Monteiro Lobato wrote:
> Hi,
>
> Using ph.x with grid may lead to
>
>       Reading data from directory:
>       scratch/X.Y/_ph0/test.save/
>       Message from routine pw_readschema_file:
>       failed retrieving input info from xml file, check it !!!
>
> and wrong results.
>
> In more details (sorry if not too methodical ... but I tried ... spent 
> all day on it):
>
> There is no problem with Gamma calculations ... as there is no bands 
> to be read from /scratch/_ph0/ ... I guess.
>
> Single-q, out Gamma (say X Y 0 instead 0. 0. 0.): tests without grid 
> (without breaking in start_irr) in qe-6.3-bkp (3D), and in qe-5.1.1 
> without/with grid leads to same results (as expected).
>
> Using grid in qe-6.3-bkp (2D):
>
>   + using only_init true leads to the message of error above ... the 
> calculations goes on as if all were all right, and the frequencies are 
> all wrong at the end (after collect).
>
>   + using only_init true and reduce_io true (thus repeating the band 
> structure calculations done at only_init calculations each time ... 
> the xml is not saved in /scratch/_ph0/) leads to frequencies as 
> expected when comparison to without grid calculations.
>
> Using grid in qe-6.3-bkp (3D):
>   + using only_init true leads to the expected results (comparison 
> with previous 3D cases).
>
> For me, it indicates it may be a problem when reading the information 
> of 2D cutoff in the in /scrath/_ph0/test.save/data-file-schema.xml 
> (same as /scrath/_ph0/test.xml).
>
> The comparison between the scrathc/test.xml and /scratch/_ph0/test.xml 
> when using the only_init true and reduce_io false shows indeed some 
> unexpected discrepancies (e.g., from what I could get, it misses the 
> fact that the scf was performed with assume isolated flag)
>
> (note ... I use wf_collect false in the scf calculation and norm 
> conserving pseudopotentials)
>
> The above were single-q calculations. For the case of dispersion 
> calculations using 2D, reading from /scratch/X.Y/test.save/ does not 
> display the message. However, when reading the bands (reading from 
> /scratch/X.Y/_ph0/test.q_X/test.save/data-file-schema.xml) it does 
> display it (except for the 0. 0. 0. point ... in this case the bands 
> are read from /scratch/test.save/ ) ... surprisingly, the calculations 
> are correct ... I guess because in this case the code, somehow, does 
> not miss the 2D flag, as it informs on the output of out.X.Y it is 
> using 2D... the question remains "what is the information it misses 
> when reading the bands from xml ... and when it will lead to error on 
> the results ? "
>
> Also, a previous post 
> http://lists.quantum-espresso.org/pipermail/users/2018-October/041419.html
> ... the celldm problem in the dyn header remains in 6.3-backports ... 
> and one have to correct it by hand on the .dyn
>
> If these are indeed unexpected error (not my ...  if someone can 
> reproduce it) yet not solved (sorry if I miss the solution in older 
> posts), the real problem is ... I don't have idea to help solving them 
> ...  although I could give it a try with some guide.
>
> best,
>