Infinite repeating SCF during cell opt

[lionelalexandre]

Dear All,

Attached is a basic example of cell optimisation using Conquest.
This example was working properly using the develop branch before
last commits (I don't know when). It looks like the SCF is restarting
infinitely. I found that by increasing SCF tol. to 1e-8 things
get better but I feel that there might be something wrong.
Could you have a look.

Best regards,
Lionel
cq_example_rocksalt_optcell_cq.tar.zip

[tsuyoshi38]

With atommove.optcellmethod 3, CONQUEST tried to optimise internal coordinates and cell parameters simultaneously, I think. The system has a high symmetry and the forces for atoms are initially 0, but in the coordinate file, the atomic positions are expected to move. ( I mean 'T T T'.) So, this is a very tough test, I am afraid. It might be possible to get converged even in this case, but do you do it intentionally ?

[davidbowler]

I've spent a little time analysing this. If we relax with AtomMove.OptCellMethod 1 then it converges quickly so long as the SCF tolerance is tight enough (I note that your stress tolerance is 1e-3 Gpa which is very low!).

But using AtomMove.OptCellMethod 3 does seem to give problematic results. The first line minimisation is excellent but after that things go wrong: I think that there must be an error in the search direction. I'll check this carefully.

[prconlin]

I've encountered a similar issue, using AtomMove.OptCellMethod 2. It's a simple system (Ge unit cell) and the issue is reproducible on my machine. Input files are attached.

I've confirmed that it converges as expected if AtomMove.TypeOfRun is set to static, but using cg relaxation the optimizer loops endlessly.

Ge_test.tar.gz

[davidbowler]

Can you please let us know what version of the code you were using? The line in the output starting "Version comment" is all we need.

[prconlin]

Version comment: Git Branch: master; tag, hash: v1.1

[davidbowler]

Your SCF tolerance is rather low for this kind of simulation. I ran the calculation with a 2x2x2 k-mesh for the sake of speed, which converged, and found warnings in the Conquest_warnings file (and written in the Conquest_out file) that the change in energy from SCF is similar to the change in energy from cell optimisation. That's almost certainly the cause of the infinite loop: but we should have something to catch the loop.

[prconlin]

Okay, I've done some iterative testing with this system and found interesting results.

In the following tables I record, among other things, whether or not any warnings arose. I only ever encountered one warning: "Electronic structure dE is similar to atom movement dE", so the warning column is a simple Y/N.

Adjusting the SCF tolerance with all else equal (4x4x4 kpoint grid and cutoff of 60):

<style> </style>

Tolerance	Conv?	Time (s)	Iterations	Enthalpy (eV)	Lattice (A)	Warnings?
1.0E-05	Y	132.87	1	-19443.3	6.062	Y
1.0E-06	Y	106.302	3	-19443.3	6.061	N
1.0E-07	Y	124.083	1	-19443.3	6.061	N
1.0E-08	Y	149.803	1	-19443.3	6.061	N

Increasing the tolerance disappeared the warnings, but otherwise did not change the outcome of the relaxation.

Adjusting the grid cutoff with all else equal (4x4x4 kpoint grid and SCF tol of 1E-6):

<style> </style>

Cutoff	Conv?	Time (s)	Iterations	Enthalpy (eV)	Lattice (A)	Warnings?
50	Y	78.307	2	-19446.1	6.239	Y
60	Y	121.454	1	-19443.3	6.061	N
70	Y	106.713	3	-19443.3	6.061	N
80	Y	96.932	2	-19441.5	5.775	Y

This parameter seems to have the most significant impact on accuracy, but there is no clear pattern to whether or not I get the dE warning. All tests converged regardless.

Adjusting the kpoint density with all else equal (cutoff of 60 and SCF tol of 1E-6):

<style> </style>

KPOINTS	Conv?	Time (s)	Iterations	Enthalpy (eV)	Lattice (A)	Warnings?
1x1x1	Y	42.019	1	-19438.0	7.213	Y
2x2x2	Y	41.846	1	-19442.7	6.150	Y
4x4x4	Y	106.371	3	-19443.3	6.061	N
8x8x8	N

This is the only instance where a test failed to converge, maybe indicating some isolated issue with the 8x8x8 grid spacing? I've tried adjusting a few parameters to see if I can get convergence in the 8x8x8 case. Increasing the grid cutoff does not help, nor does increasing the SCF tolerance.

[davidbowler]

Thanks for all this data! The warning will generally only be triggered when the change in cell size is small, as this will lead to small total energy changes. If the change in energy from the last step of the SCF cycle is comparable to the change in energy from the cell update then the minimisation is likely to fail (the SCF change will be like noise).

My guess is that this is somewhat random: it's just that with the 8x8x8 mesh the stress after the second or third iteration is large enough that the optimisation doesn't stop, but small enough that the SCF noise affects it.

We should maybe make the default maximum number of iterations different for cell optimisation and ionic optimisation; I will think about whether there is a way to detect this kind of noisy problem and abort or warn further.