<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hi,</div><div><br></div><div>The test-phgrid.zip contains the example related to the xml missing information (also the celldm).</div><div><br></div><div>Folders and content:</div><div>i) check-full-qe-5.1.1 contains the single-q without grid.</div><div>ii) qe-5.1.1-grid contains the single-q with grid.</div><div>iii) check-full contains the single-q without grid using 3D and 2D codes .. the corresponding outputs have 3D and 2D appended in their filename.</div><div> iv) cpBands, linkBands, and noXML contain tests with grid in the qe-6.3-bkp using 2D code trying different "small changes" on the grid script. I have some issue with the huge amount of data in scratch/_ph0 when your system has, say 270 irrs, ... so I symlink some files which are created and use just for reading in the dfpt scf steps of the irrs. I thought the xml issue was due that, but it appears it is not. Regardless these small changes, all them lead to the same identical wrong frequencies in comparison to without grid 6.3-bkp 2D code in iii).</div><div><br></div><div>In the below, I set q=1 and j loops over the irrs, and I copied the test.phsave (and did others grid steps)<br></div><div>In the cpBands, I cp the scratch/_ph0/test.save to scratch/1.X/_ph0/test.save, where X is the irr.</div><div> for data in `ls scratch/_ph0 | grep -e $prefix.xml -e $prefix.wfc -e $prefix.save | xargs `; do<br> cp -r scratch/_ph0/$data scratch/$q.$j/_ph0/. <br>done</div><div><br></div><div>In the linkBands, I just link it (ln -s ../../_ph0/$data scratch/$q.$j/_ph0/)<br></div><div> for data in `ls scratch/_ph0 | grep -e $prefix.xml -e $prefix.wfc -e $prefix.save | xargs `; do</div><div> ln -s ../../_ph0/$data scratch/$q.$j/_ph0/. <br>done</div><div><br></div><div>In the noXML, I forgot the -e $prefix.xml in the script for linkBands and did not copied the xml (it is inside the scratch/_ph0/test.save/ anyway).</div><div><br></div><div>v) reduce-io-false is a double-check of the tests in iv) ... with grid in qe-6.3-bkp with 2D.</div><div><br></div><div>vi) reduce-io-false-3D just unset the 2D cutoff. The results are the same of the folders i) ii) and iii) with 3D name, as expected.<br></div><div><br></div><div>vii) reduce-io-true is the 2D test of the 6.3-bkp where I set reduce_io true. The results are like the ones in the folder iii) with 2D name (6.3-bkp without grid)</div><div><br></div><div>About celldm, you can see for example the scfout and phout in the folder iii) check-full. e.g.</div><div>scfout2D<br></div><div>celldm(1)= 1.889726 celldm(2)= 0.000000 celldm(3)= 0.000000<br>celldm(4)= 0.000000 celldm(5)= 0.000000 celldm(6)= 0.000000</div><div>phout2D</div><div>celldm(1)= 4.620461 celldm(2)= 0.000000 celldm(3)= 7.361835 <br>celldm(4)= 0.000000 celldm(5)= 0.000000 celldm(6)= 0.000000<br></div><div><br></div><div>or <br></div><div><br></div><div>scfout3D</div><div>celldm(1)= 1.889726 celldm(2)= 0.000000 celldm(3)= 0.000000<br>celldm(4)= 0.000000 celldm(5)= 0.000000 celldm(6)= 0.000000</div><div><br></div><div>phout3D</div><div>celldm(1)= 4.620461 celldm(2)= 0.000000 celldm(3)= 7.361835<br>celldm(4)= 0.000000 celldm(5)= 0.000000 celldm(6)= 0.000000<br></div><div><br></div><div>and the dyn header</div><div> 1 2 0 4.6204611 0.0000000 7.3618345 0.0000000 0.0000000 0.0000000</div><div><br></div><div>by opening the scf and axsf in xcrysden you can see it.</div><div><br></div><div>The examples of disp case are in the disp-grid-no-grid-6.3-bkp.tar.gz ... the comparison of the dynX obtained without grid (in file k661-grid) and with grid (k661-check-full) shows same frequencies.<br></div><div><br></div><div>best,</div><div><br></div><div>I'm very sorry Professor Giannozzi ... I compiled the 6.3-bkp by these days (after Carnival, actually ... )
... previously (Carnival) I kept hand-correcting the dyn header before post-processing it while using previous versions I reported the celldm thing, six months ago.<br></div><div><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em ter, 12 de mar de 2019 às 11:21, Paolo Giannozzi <<a href="mailto:p.giannozzi@gmail.com">p.giannozzi@gmail.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">Please provide an example backing your claim (NOW, not in 6 months)<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 12, 2019 at 2:26 PM RAPHAEL LONGUINHOS MONTEIRO LOBATO <<a href="mailto:raphael.lobato@ufla.br" target="_blank">raphael.lobato@ufla.br</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif;font-size:small">Hi,</div><div style="font-family:arial,helvetica,sans-serif;font-size:small">Thanks for be working to fix it.</div><div style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small"> The other subject of the message ... "wrong celldm values" ... was previously replied at <br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small"><a href="http://lists.quantum-espresso.org/pipermail/users/2018-October/041419.html" target="_blank">http://lists.quantum-espresso.org/pipermail/users/2018-October/041419.html</a></div><div style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small">which thought it was solved with the modification reported in:<br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small"><a href="https://gitlab.com/QEF/q-e/commit/9a579539b65bd1502d1f28747e483a1d1059f5f8" target="_blank">https://gitlab.com/QEF/q-e/commit/9a579539b65bd1502d1f28747e483a1d1059f5f8</a></div><div style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small">In the pw_restart_new.f90 of qe-6.3-bkp I see as reported above<br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small">1199 CALL at2celldm (ibrav,1.0_dp,at(:,1),at(:,2),at(:,3),celldm) ! chance to 1.0_dp in the place of the removed alat<br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small">Yet,
the ph.x reads wrong celldm values, prints them wrongly in the dyn
header, and the issue of rescaling some quantities from dynmat.x
remains.<br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small">best,</div><div style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small">Sorry ... I forgot to mention in previous post I'm from:</div><div style="font-family:arial,helvetica,sans-serif;font-size:small">Associate Professor Raphael Longuinhos Monteiro Lobato
<br>CV:<a class="gmail-m_-4136893084346531637m_6272918451432072263gmail-m_8380414167801608125gmail-m_2511768992879587542gmail-moz-txt-link-freetext" href="http://lattes.cnpq.br/1475483971471395" target="_blank">http://lattes.cnpq.br/1475483971471395</a>.
<br>Research Group site:<a class="gmail-m_-4136893084346531637m_6272918451432072263gmail-m_8380414167801608125gmail-m_2511768992879587542gmail-moz-txt-link-freetext" href="http://jenainassoares2.wixsite.com/nanomat" target="_blank">http://jenainassoares2.wixsite.com/nanomat</a> (Portuguese only - English version on the way)
<br>Departamento de Fisica, Universidade Federal de Lavras
<br>Av. Dr. Silvio Menicucci 1001, bairro Kenedy
<br>Post office box 3037
<br>37200-000 - Lavras, MG, Brazil
</div><div style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
------------------------------<br>
<br>
Message: 8<br>
Date: Tue, 12 Mar 2019 11:04:58 +0100<br>
From: Pietro Davide Delugas <<a href="mailto:pdelugas@sissa.it" target="_blank">pdelugas@sissa.it</a>><br>
To: <a href="mailto:users@lists.quantum-espresso.org" target="_blank">users@lists.quantum-espresso.org</a><br>
Subject: Re: [QE-users] pw_readschema_file failed retrieving input<br>
info from xml file ph.x using grid in qe-6.3-bkp and 2D cutoff<br>
Message-ID: <<a href="mailto:a89d561d-1029-5416-7229-da026757a704@sissa.it" target="_blank">a89d561d-1029-5416-7229-da026757a704@sissa.it</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
Hi<br>
<br>
Thanks for reporting the issue.<br>
<br>
As for the message about the missing input element, no problem it is the <br>
desired behavior, run_nscf started bby ph would not be able to fill <br>
correctly the<br>
input element because the variable in input_parameters are not <br>
initialized, so the element is? not printed at all.<br>
<br>
The isseus comes from the fact that in writing the status of the 2D <br>
cutoff we are currenlty using the value stored in input_parameters <br>
which, not being initialized, has in this case a wrong .false. value.<br>
<br>
I will fix the issue in the develop, for further information check this <br>
issue on gitlab <a href="https://gitlab.com/QEF/q-e/issues/102" rel="noreferrer" target="_blank">https://gitlab.com/QEF/q-e/issues/102</a><br>
<br>
Pietro<br>
<br>
<br>
<br>
On 03/11/2019 09:11 PM, Raphael Longuinhos Monteiro Lobato wrote:<br>
> Hi,<br>
><br>
> Using ph.x with grid may lead to<br>
><br>
> ????? Reading data from directory:<br>
> ????? scratch/X.Y/_ph0/test.save/<br>
> ????? Message from routine pw_readschema_file:<br>
> ????? failed retrieving input info from xml file, check it !!!<br>
><br>
> and wrong results.<br>
><br>
> In more details (sorry if not too methodical ... but I tried ... spent <br>
> all day on it):<br>
><br>
> There is no problem with Gamma calculations ... as there is no bands <br>
> to be read from /scratch/_ph0/ ... I guess.<br>
><br>
> Single-q, out Gamma (say X Y 0 instead 0. 0. 0.): tests without grid <br>
> (without breaking in start_irr) in qe-6.3-bkp (3D), and in qe-5.1.1 <br>
> without/with grid leads to same results (as expected).<br>
><br>
> Using grid in qe-6.3-bkp (2D):<br>
><br>
> ? + using only_init true leads to the message of error above ... the <br>
> calculations goes on as if all were all right, and the frequencies are <br>
> all wrong at the end (after collect).<br>
><br>
> ? + using only_init true and reduce_io true (thus repeating the band <br>
> structure calculations done at only_init calculations each time ... <br>
> the xml is not saved in /scratch/_ph0/) leads to frequencies as <br>
> expected when comparison to without grid calculations.<br>
><br>
> Using grid in qe-6.3-bkp (3D):<br>
> ? + using only_init true leads to the expected results (comparison <br>
> with previous 3D cases).<br>
><br>
> For me, it indicates it may be a problem when reading the information <br>
> of 2D cutoff in the in /scrath/_ph0/test.save/data-file-schema.xml <br>
> (same as /scrath/_ph0/test.xml).<br>
><br>
> The comparison between the scrathc/test.xml and /scratch/_ph0/test.xml <br>
> when using the only_init true and reduce_io false shows indeed some <br>
> unexpected discrepancies (e.g., from what I could get, it misses the <br>
> fact that the scf was performed with assume isolated flag)<br>
><br>
> (note ... I use wf_collect false in the scf calculation and norm <br>
> conserving pseudopotentials)<br>
><br>
> The above were single-q calculations. For the case of dispersion <br>
> calculations using 2D, reading from /scratch/X.Y/test.save/ does not <br>
> display the message. However, when reading the bands (reading from <br>
> /scratch/X.Y/_ph0/test.q_X/test.save/data-file-schema.xml) it does <br>
> display it (except for the 0. 0. 0. point ... in this case the bands <br>
> are read from /scratch/test.save/ ) ... surprisingly, the calculations <br>
> are correct ... I guess because in this case the code, somehow, does <br>
> not miss the 2D flag, as it informs on the output of out.X.Y it is <br>
> using 2D... the question remains "what is the information it misses <br>
> when reading the bands from xml ... and when it will lead to error on <br>
> the results ? "<br>
><br>
> Also, a previous post <br>
> <a href="http://lists.quantum-espresso.org/pipermail/users/2018-October/041419.html" rel="noreferrer" target="_blank">http://lists.quantum-espresso.org/pipermail/users/2018-October/041419.html</a><br>
> ... the celldm problem in the dyn header remains in 6.3-backports ... <br>
> and one have to correct it by hand on the .dyn<br>
><br>
> If these are indeed unexpected error (not my ...? if someone can <br>
> reproduce it) yet not solved (sorry if I miss the solution in older <br>
> posts), the real problem is ... I don't have idea to help solving them <br>
> ...? although I could give it a try with some guide.<br>
><br>
> best,<br>
><br>
</blockquote></div></div>
_______________________________________________<br>
users mailing list<br>
<a href="mailto:users@lists.quantum-espresso.org" target="_blank">users@lists.quantum-espresso.org</a><br>
<a href="https://lists.quantum-espresso.org/mailman/listinfo/users" rel="noreferrer" target="_blank">https://lists.quantum-espresso.org/mailman/listinfo/users</a></blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail-m_-4136893084346531637m_6272918451432072263gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche,<br>Univ. Udine, via delle Scienze 208, 33100 Udine, Italy<br>Phone +39-0432-558216, fax +39-0432-558222<br><br></div></div></div></div></div>
</div><br clear="all"><br>-- <br><div dir="ltr" class="gmail-m_-4136893084346531637gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche,<br>Univ. Udine, via delle Scienze 208, 33100 Udine, Italy<br>Phone +39-0432-558216, fax +39-0432-558222<br><br></div></div></div></div></div></div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Associate Professor Raphael Longuinhos Monteiro Lobato<br>CV: <a href="http://lattes.cnpq.br/1475483971471395" target="_blank">http://lattes.cnpq.br/1475483971471395</a>.<br>Research Group site: <a href="http://jenainassoares2.wixsite.com/nanomat" target="_blank">http://jenainassoares2.wixsite.com/nanomat</a> (Portuguese only - English version on the way)<br>Departamento de Fisica, Universidade Federal de Lavras<br>Av. Dr. Silvio Menicucci 1001, bairro Kenedy<br>Post office box 3037<br>37200-000 - Lavras, MG, Brazil <br></div></div></div>