<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Dear Jonathan Backman,</p>
    <p>I suggest you to try and set diago_david_ndim = 2 instead of the
      default value of diago_david_ndim = 4 if you are using Davidson
      diagonalization - it helped me to resolve a similar issue in the
      past. The other thing that helped me was changing a pseudo
      potenial to a much hard norm-conserving pseudo that contained more
      semi-core states, however, for performance reason I edned up using
      diago_david_ndim =2 option.</p>
    <p>Best regards,<br>
    </p>
    <div class="moz-cite-prefix">On 19/06/2019 12:47, Jonathan Backman
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:4b7fa96d-eb37-e9da-1a1f-0a01dcb2fb19@iis.ee.ethz.ch">Dear
      Quantum Espresso community,
      <br>
      <br>
      I am trying to perform a relax calculation on two different
      Ni-MoS2 contacts. One top contact (Ni over single layer MoS2) and
      one edge contact (MoS2 connected to the side of Ni), see attached
      input file. In both cases I get the error "problems computing
      cholesky". It has previously been suggested that this can happen
      in the case of "bad" atom positions, but I do not think this is
      the case for me, especially since it occurs in both my contacts.
      The problem also remains when changing the pseudo potentials.
      <br>
      <br>
      It has also been suggested that the error can be caused by a
      parallelization issue. For the edge contact I am running on 792
      processor cores (distributed over 33 nodes) divided over 11 pools
      (since I have 11 kpoints) with 72 processors per pool. With
      current ecutwfc the FFT dimensions are ( 360, 384,  72). To my
      understanding should give a effective parallelization, sine number
      of processors/pool is smaller or equal to FFR_3 and is a divisor
      of it. I have also tried with 264 processors, 24 processors/pool,
      but the problem still remains.
      <br>
      <br>
      The calculation is able to perform 2-3 bfgs steps before showing
      the error at the beginning of the next scf cycle. If I then take
      the last atom positions and perform  a new relaxation calculation
      it can once again go through 2-3 bfgs steps before error. Using
      this method I can continue restarting it, but it is not very
      effective. If I instead restart the calculation using the last
      saved charge density it shows the error immediately in the first
      scf iteration.
      <br>
      <br>
      I would be happy for any suggestions on how to solve this problem.
      <br>
      Please ask if you want more information.
      <br>
      <br>
      <br>
      Best regards,
      <br>
      Jonathan Backman, PhD student
      <br>
      Nano-TCAD Group, ETHZ Switzerland
      <br>
      <a class="moz-txt-link-abbreviated" href="mailto:jbackman@iis.ee.ethz.ch">jbackman@iis.ee.ethz.ch</a>
      <br>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
Quantum ESPRESSO is supported by MaX (<a class="moz-txt-link-abbreviated" href="http://www.max-centre.eu/quantum-espresso">www.max-centre.eu/quantum-espresso</a>)
users mailing list <a class="moz-txt-link-abbreviated" href="mailto:users@lists.quantum-espresso.org">users@lists.quantum-espresso.org</a>
<a class="moz-txt-link-freetext" href="https://lists.quantum-espresso.org/mailman/listinfo/users">https://lists.quantum-espresso.org/mailman/listinfo/users</a></pre>
    </blockquote>
    <pre class="moz-signature" cols="72">-- 
Oleksandr Motornyi
PhD

Laboratoire de Solides Irradies
Ecole Polytechnique (Palaiseau, France)</pre>
  </body>
</html>