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,
_______________________________________________
users mailing list
[email protected]
https://lists.quantum-espresso.org/mailman/listinfo/users
