<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div style="word-wrap:break-word">Dear QE developers,
<div>I believe that I managed to narrow down the problem of my mail of last month.</div>
<div>A detailed description follows below.</div>
<div><b>The short summary is that I believe that there is a subtle case that may occur when restarting (see below), and when it occurs, wrong data is stored in the dynamical matrix. </b></div>
<div><b>To fix it, probably someone who is expert of the internals of the phonon code is needed… (Andrea Dal Corso?)</b></div>
<div><br>
</div>
<div><br>
</div>
<div>Description of the problem:</div>
<div>* the summary of my mail of last month is the following: there was a phonon calculation of a cubic system, but for which no symmetries were recognized by QE. A 2x2x2 full q-grid was therefore calculated; however for one of the q points we were getting
 wrong results (some negative and some very large frequencies), and in particular very different from those expected from symmetry arguments from the equivalent q points</div>
<div>* After my last mail, I tried to rerun the calculation with same machine, executable, and number of nodes, but only for the 'wrong' q-point. The results were this time correct (also from comparison from the other q points).</div>
<div>* I thus compared the dynamical matrices of the two runs from the two matdyn files. It turned out that (apart small numerical differences) all differences were only for atom 37 (don't consider the units of the color map; to get an idea of the magnitude
 of this problem, take into account that, in the unit of the matdyn file, there were some matrix elements of approx. 1. instead of values of approx 0.01).</div>
<div>* I then checked the restarts in the 'wrong' run. Indeed, there was a restart for that specific q point, at representation #111 (note that 111=37*3). The end of the first run was:</div>
<div><br>
</div>
<div>
<div>     Representation #111 mode # 111</div>
<div><br>
</div>
<div>     Self-consistent Calculation</div>
<div><br>
</div>
<div>      iter #   1 total cpu time : 81737.1 secs   <a href="http://av.it">av.it</a>.:   8.9</div>
<div>      thresh= 0.100E-01 alpha_mix =  0.700 |ddv_scf|^2 =  0.305E-06</div>
<div><br>
</div>
<div>      iter #   2 total cpu time : 81800.9 secs   <a href="http://av.it">av.it</a>.:  21.4</div>
<div>      thresh= 0.552E-04 alpha_mix =  0.700 |ddv_scf|^2 =  0.127E-05</div>
<div><br>
</div>
<div>      iter #   3 total cpu time : 81861.0 secs   <a href="http://av.it">av.it</a>.:  19.2</div>
<div>      thresh= 0.113E-03 alpha_mix =  0.700 |ddv_scf|^2 =  0.975E-07</div>
<div><br>
</div>
<div>[…]</div>
<div><br>
</div>
<div><br>
</div>
<div>      iter #  17 total cpu time : 82715.5 secs   <a href="http://av.it">av.it</a>.:  19.6</div>
<div>      thresh= 0.589E-08 alpha_mix =  0.700 |ddv_scf|^2 =  0.118E-14</div>
<div><br>
</div>
<div>      iter #  18 total cpu time : 82776.1 secs   <a href="http://av.it">av.it</a>.:  19.6</div>
<div>      thresh= 0.343E-08 alpha_mix =  0.700 |ddv_scf|^2 =  0.304E-15</div>
<div><br>
</div>
<div>      iter #  19 total cpu time : 82837.2 secs   <a href="http://av.it">av.it</a>.:  19.9</div>
<div>      thresh= 0.174E-08 alpha_mix =  0.700 |ddv_scf|^2 =  0.596E-16</div>
<div><br>
</div>
<div>     Maximum CPU time exceeded</div>
<div><br>
</div>
<div>     max_seconds     =   82800.00</div>
<div>     elapsed seconds =   82814.09</div>
</div>
<div><br>
</div>
<div><br>
</div>
<div>while at the beginning of the restart we got (I just report the relevant parts of the output)</div>
<div>
<div>[…]</div>
<div>     Representation   108      1 modes -  Done</div>
<div><br>
</div>
<div>     Representation   109      1 modes -  Done</div>
<div><br>
</div>
<div>     Representation   110      1 modes -  Done</div>
<div><br>
</div>
<div>     Representation   111      1 modes - To be done</div>
<div><br>
</div>
<div>     Representation   112      1 modes - To be done</div>
<div><br>
</div>
<div>     Representation   113      1 modes - To be done</div>
<div><br>
</div>
<div>[…]</div>
<div><br>
</div>
<div><b>     Representation #111 mode # 111</b></div>
<div><b><br>
</b></div>
<div><b>     Self-consistent Calculation</b></div>
<div><b><br>
</b></div>
<div><b>     End of self-consistent calculation</b></div>
<div><b><br>
</b></div>
<div><b>     Convergence has been achieved </b></div>
</div>
<div><br>
</div>
<div><i>i.e., not even a step was performed</i>. <b>My guess is that the convergence was achieved in the previous run, but the code did not have the time to realize it before stopping. At the restart, it immediately realized that convergence was already achieved
 and it stopped, but it apparently stored wrong data.</b></div>
<div>I thus think that one should check this part of the restart to understand why this can be the cause of a problem.</div>
<div><br>
</div>
<div>As a further hint that this may be the problem, I looked in the database of all our calculations for other phonon calculations with a similar behavior, i.e., the end of the self-consistent calculation without even a single step.</div>
<div>It turned out that there was another calculation with this property, and also that one had a similar behavior: wrong frequencies at the q-point for which the restart happened (see the resulting interpolated band plot 'band_plot_wrong.pdf': since one point
 got very negative values + very large values, the interpolation goes crazy).</div>
<div><br>
</div>
<div>I hope that this is of some help for solving the problem… I wait for comments!</div>
<div><br>
</div>
<div>Best,</div>
<div><br>
</div>
<div>Giovanni</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div></div>
</div>
<div><img src="cid:2860e64d-21ac-4d9b-b69a-9434b3d70f00@intranet.epfl.ch"> </div>
<div style="word-wrap:break-word">
<div></div>
</div>
<div style="word-wrap:break-word">
<div><br>
<div>
<div>-- </div>
<div>Giovanni Pizzi</div>
<div>Post-doctoral Research Scientist</div>
<div>EPFL STI IMX THEOS</div>
<div>MXC 319 (Bâtiment MXC)</div>
<div>Station 12</div>
<div>CH-1015 Lausanne (Switzerland)</div>
<div>Phone: +41 21 69 31159</div>
<br>
<br class="x_Apple-interchange-newline">
</div>
<br>
<div>
<div>On 21 Dec 2012, at 2:22 PM, Stefano de Gironcoli wrote:</div>
<br class="x_Apple-interchange-newline">
<blockquote type="cite">
<div>Dear Giovanni and Andrea,<br>
<br>
    ok.. i dont know what the problem could be but let´s see if it is <br>
possible to pin it down ...<br>
<br>
    when there is no symmetry the code should do only trivial summation <br>
and so if k points are equivalent by symmetry they should be equivalent <br>
contribution so it is strange...<br>
     one possibility is that there is a problem in recovering the <br>
calculation from interrupted run...<br>
     this should /might change if you repeat the calculation with <br>
different number of  processors or aon a different machine... have you <br>
done that ?<br>
    your cell is not the smallest possibly one.. i guess a calculation <br>
with just 5 atom per cell and a k point mesh doubled in each direction <br>
should be equivalent to the one you have been doing...<br>
    but should be such that maybe the entire calculation fit in one <br>
single run ....<br>
    have you tried ? is the result the same or it respect the expected <br>
symmetry ?<br>
<br>
stefano<br>
<br>
On 12/20/2012 05:29 PM, Giovanni Pizzi wrote:<br>
<blockquote type="cite">Dear Stefano,<br>
</blockquote>
<blockquote type="cite">thanks a lot for your reply.<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">As a follow up on our previous email (later below you can find our answers):<br>
</blockquote>
<blockquote type="cite">* the first of the two problems (i.e. the code stopping with Error in<br>
</blockquote>
<blockquote type="cite">routine set_irr_sym (1422): wrong representation) seems to have been<br>
</blockquote>
<blockquote type="cite">corrected in the most recent SVN, that doesn't stop anymore. Maybe<br>
</blockquote>
<blockquote type="cite">someone can confirm that modifications to the code in this direction<br>
</blockquote>
<blockquote type="cite">have been done.<br>
</blockquote>
<blockquote type="cite">* the problem of different phonon frequencies for the x, y, and z<br>
</blockquote>
<blockquote type="cite">directions remains. Just to be sure that it wasn't a problem with the<br>
</blockquote>
<blockquote type="cite">cluster (say I/O, communication, etc.) we have submitted again the<br>
</blockquote>
<blockquote type="cite">calculation for the 'tricky' q point (q #5), both with 5.0.1 and the svn<br>
</blockquote>
<blockquote type="cite">version. We will report back when the calculation finishes...<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">Below follow our answers.<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">On 12/19/2012 11:04 AM, Stefano de Gironcoli wrote:<br>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">Dear Giovanni, dear Andrea<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">     I'm looking into your calculations...<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">     in particular 01_vcrelax and 02_vcrelax aida.out<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">     inspecting the structure with xcrysdens it does not look to me<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">that the structure has cubic symmetry... or at least Ti atoms appear<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">not to be aligned in neighboring cells...<br>
</blockquote>
</blockquote>
<blockquote type="cite">Indeed. The Ti atoms are not all aligned in our system. Nonetheless, the<br>
</blockquote>
<blockquote type="cite">system still has cubic symmetry. To have a rough idea of why this is<br>
</blockquote>
<blockquote type="cite">happening, it is because 4 of the Ti atoms displace toward a given Ba<br>
</blockquote>
<blockquote type="cite">atom w.r.t. a perfect cubic perovskite structure, remaining however at<br>
</blockquote>
<blockquote type="cite">the edge of a tetrahedron (the other four Ti atoms displace in opposite<br>
</blockquote>
<blockquote type="cite">directions, forming tetrahedra around Ba atoms in neighboring cells).<br>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">     in the spglib code you use to recognize the symmetry is there a<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">threshold in the acceptance of the symmetry operations ?<br>
</blockquote>
</blockquote>
<blockquote type="cite">Yes, there is. The symmetry of our initial system (input of 01_) is<br>
</blockquote>
<blockquote type="cite">exactly cubic (I-43M, group 217) down to a precision of 10^-12.<br>
</blockquote>
<blockquote type="cite">After relaxation, the symmetry remains the same (cubic, group 217) with<br>
</blockquote>
<blockquote type="cite">a precision down to 10^-6; for tighter thresholds, the symmetry is<br>
</blockquote>
<blockquote type="cite">recognized as rhombohedral (R3M, group 160). This is because pw.x finds<br>
</blockquote>
<blockquote type="cite">only a subset of the symmetries of the cubic group, and only those are<br>
</blockquote>
<blockquote type="cite">exactly preserved during the vc-relax. Anyhow, also in the rhombohedral<br>
</blockquote>
<blockquote type="cite">symmetry the three axes x, y, z can be interchanged and thus we would<br>
</blockquote>
<blockquote type="cite">expect the same physical properties along x, y, z. (We have also checked<br>
</blockquote>
<blockquote type="cite">explicitly the coordinates of the output cell of calculation 02_, and<br>
</blockquote>
<blockquote type="cite">the system obeys the symmetry x<->y<->z exactly, for all digits printed<br>
</blockquote>
<blockquote type="cite">out in the output file).<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">     did you relaxed the structure after translating it ? if there is<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">some symmetry breaking that want to  develop now that you removed the<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">symmetry you should allow for it.<br>
</blockquote>
</blockquote>
<blockquote type="cite">No, we actually didn't (also because without symmetries the system will<br>
</blockquote>
<blockquote type="cite">relax to the rhombohedral phase, stable at T=0).<br>
</blockquote>
<blockquote type="cite">Anyway, we believe that this is not the main issue of the problem we are<br>
</blockquote>
<blockquote type="cite">facing: if the cubic phase is unstable, we may get negative phonon<br>
</blockquote>
<blockquote type="cite">frequencies, e.g. at Gamma, but this is not a problem.<br>
</blockquote>
<blockquote type="cite">However, in any case, even if QE doesn't recognize the symmetries, we<br>
</blockquote>
<blockquote type="cite">know that the system has cubic or at least rhombohedral symmetry [we<br>
</blockquote>
<blockquote type="cite">just shifted the system from one with cubic or rhombohedral<br>
</blockquote>
<blockquote type="cite">coordinates], and thus we expect that the phonon frequencies that we<br>
</blockquote>
<blockquote type="cite">calculate for a k point along k_x should have the same frequencies of<br>
</blockquote>
<blockquote type="cite">those calculated along k_y or k_z, but this is not happening.<br>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">     are you sure the system insulating... ? if you mistreat a metal as<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">an insulator results are unpredictable.<br>
</blockquote>
</blockquote>
<blockquote type="cite">We re-checked now and the system is indeed insulating (gap almost 2 eV).<br>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<blockquote type="cite">Best,<br>
</blockquote>
<blockquote type="cite">Andrea and Giovanni<br>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">stefano<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">Quoting Giovanni Pizzi <<a href="mailto:giovanni.pizzi@epfl.ch">giovanni.pizzi@epfl.ch</a>>:<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">Dear developers,<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">we are experiencing a problem with the phonon code. We think that<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">this may be a serious bug.<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">Here a short description of the problem; below, a more detailed<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">description follows. Attached, all relevant inputs and outputs of<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">the 5 calculations of interest.<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">Short description:<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">* We have a 40-atom cell with cubic cell (and cubic space group).<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">pw.x recognizes 6 symmetries (folder 01_... for the vc-relax, and<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">02_... for the restart from that vc-relax). However, then when ph.x<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">starts (folder 03_...), it crashes with "Error in routine<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">set_irr_sym (1422): wrong representation".<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">* As a workaround, we slightly translate the system (folder 04_...).<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">Then, pw.x just finds one symmetry (the identity), and subsequently<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">ph.x starts and computes the phonons. We ask for the phonons on a<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">2x2x2 q-mesh, and since no symmetries are found, all 8 qpoints are<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">evaluated (folder 05_...).<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">* Since the system has cubic symmetry (even if pw/ph don't detect<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">it), we expect that the frequencies found on equivalent q-points<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">should be the same. This should be the case for the following q<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">points (see folder 05_...):<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">        N         xq(1)         xq(2)         xq(3)<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">        2   0.000000000   0.000000000  -0.061601673<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">        3   0.000000000  -0.061601673   0.000000000<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">        5  -0.061601673   0.000000000   0.000000000<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">Instead, while the frequencies of qpoints 2 and 3 are similar within<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">1 cm^-1, the frequencies at qpoint 5 are quite off (there is a<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">negative frequency -928.641695 [cm-1], and also a new maximum-energy<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">frequency of 4496.358033 [cm-1], while q points 2 and 3 have<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">frequencies in the range 70-740 [cm-1].<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">Could anyone help us in finding where the bug lies?<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">Best,<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">Andrea Cepellotti and Giovanni Pizzi<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">THEOS (Theory and Simulation of Materials), EPFL, Switzerland<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">P.S.: longer description of what we did with some more details:<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">the attached zip has 5 folders, starting with an incremental number<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">01_, 02_, ...<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">* The first calculation (01_) is a vc-relax of the cell.<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">* The second calculation (02_) is a vc-relax, restarted from the<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">coordinates of 01_ (the volume changed significantly during the<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">vc-relax and we had to restart the calculation with the<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">newly-calculated G-vectors)<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">Both these cells have a cubic cell (defined with ibrav=0) and a<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">cubic space group: I-43m (217), checked using the 'spglib' code.<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">* we start a phonon calculation (03_) from the results of 02_: the<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">calculation crashes as described above.<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">* we take the relaxed coordinates of job 02_ and translate them by<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">the vector (0.01, 0.02, 0.03) angstrom. With these new coordinates,<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">we perform an scf calculation (job 04_).<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">Note that also this system is correctly recognized by the spglib<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">code to have the same cubic space group of before: I-43m (217)<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">* we perform a phonon calculation (job 05_) from the scf of job 04_.<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">Due to queue limitations on our supercomputer, the calculation was<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">run at steps of 23 hours (and stopped using the max_seconds flag)<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">and then restarted multiple times. The output file of the first run<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">is called 'aida.out', the subsequent restarts are called<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">'aida-recover-N.out' with N ranging from 1 to 12.<br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">_______________________________________________<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">Q-e-developers mailing list<br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><a href="mailto:Q-e-developers@qe-forge.org">Q-e-developers@qe-forge.org</a><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><a href="http://qe-forge.org/mailman/listinfo/q-e-developers">http://qe-forge.org/mailman/listinfo/q-e-developers</a><br>
</blockquote>
</blockquote>
<blockquote type="cite"><br>
</blockquote>
<br>
_______________________________________________<br>
Q-e-developers mailing list<br>
<a href="mailto:Q-e-developers@qe-forge.org">Q-e-developers@qe-forge.org</a><br>
http://qe-forge.org/mailman/listinfo/q-e-developers<br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</body>
</html>