Restart from the optimized geometry

[ma455...@gmail.com]

Hi,

I'm a user of cp2k v8.2. I found restarting from an optimized geometry will result in a different converge energy and geometry. 

The optimized.inp, optimized.restart, and optimized.out are the calculations that full converged with four convergence criteria reaching the setting threshold (i.e., 4 YES for RMS gradient and RMS step size).

When I restart the calculation with the optimized structure using exactly same input file (without reading from the previous wavefunction), I would still expect the same converged energy and geometry. However, the calculation did not reach converged criteria until running another 77 geometry optimization cycles and the converged energy is not similar either (-5113.2003066256 vs. -5113.1945296822).

I'm confused about this because should I trust the optimized geometry from one calculation? If the geometry is fully optimized, why restarting from this geometry results in additional 77 geometry optimization cycles?

Any suggestions would be very appreciated! Thanks!

Regards,

Hongyang

[Krack Matthias (PSI)]

The GEO_OPT run converged to some state and atomic configuration. If you restart that last atomic configuration from scratch using an atomic guess, you may converge to a different state, and this becomes even more likely when you employ a large U ramping. The large difference between the selected spin and the actual integrated spin indicates already that you did not converge to the ground state most likely.

 

Matthias

 

--
You received this message because you are subscribed to the Google Groups "cp2k" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cp2k+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cp2k/115a2c2e-a76a-44cb-8f17-4a706fd97915n%40googlegroups.com.

[ma455...@gmail.com]

Dear Matthias,

Thanks for the response.

I'm wondering could you please provide some suggestions on imporoving this issue?
Additionally, if I understand it correctly, the keyword "MULTIPLICITY" works same as spinlock that can fix the overall spin moment in the system (same as NUPDOWN in VASP), is this correct? However, for some cases, with the geometry optimization proceeding, the spin moment inside the system may change spontaneously. I'm wondering is there any way to allow the spin moment (MULTIPICITY) optimizing spontaneously with the geomtry optimization process? I tried the keyword "RELAX_MULTIPICITY" but it seems not working in this way. Could you please provide some suggestions on improving the accuracy of the spin moment calculation?

Regards,

Hongyang

[Krack Matthias (PSI)]

Hi Hongyang

 

yes, in your setup the multiplicity is fixed. Currently, using OT, you have to select an integer number of spin-up and spin-down electrons in advance. You can only try to start OT runs with different initial guesses for the multiplicity. With diagonalization, you can try RELAX_MULTIPLICITY with a small value like 0.01 which may converge in some cases automatically to the ground state or at least indicate the energetically preferred multiplicities. Unfortunately, 4f/5f electron systems like your Ce system show often metastable states with DFT+U (e.g. check this work) as an additional problem which disables an automatic convergence to the right electronic ground state by contrast to d electron systems. So, you have also to check different f orbital occupation patterns in addition to the overall multiplicity of the system.

 

Matthias

 

To view this discussion on the web visit https://groups.google.com/d/msgid/cp2k/f2dfd941-9625-4f9c-8286-55300d63ac8en%40googlegroups.com.

[ma455...@gmail.com]

Dear Matthias,

Thank you very much for these information! I will give it a try with DIAGONALISATION and RELAX_MULTIPLICTY.

Another problem is that in the geometry optimization process the energy does not decrease. The converged energy stops decreasing for almost 100 cycles (from cycle 116 to cycle 200) as shown in the attached summarized ssv file (the output file is too large to attach). I'm wondering what might be the reason causing this phenomenon and how could we improve this issue?

Regards,

Hongyang

[Krack Matthias (PSI)]

The optimizer might get confused when the SCF runs converge to different states, i.e. jumps between PESs.

 

Matthias

 

Von: cp...@googlegroups.com <cp...@googlegroups.com> Im Auftrag von ma455...@gmail.com

Gesendet: Donnerstag, 29. Juli 2021 14:21
An: cp2k <cp...@googlegroups.com>

--

You received this message because you are subscribed to the Google Groups "cp2k" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cp2k+uns...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/cp2k/63236752-319e-46a9-abe7-41b5835df858n%40googlegroups.com.