eljost
commented
3 weeks ago Dear Sebastian,
thanks for the report.
When I run the example with the current dev branch the optimization converges. Nonetheless, the "lack of progress" around cycles 26 to 47 is also apparent.
I'll look into it.
Describe the bug If optimizations are run within redundant coordinates and the molecular structure undergoes major changes, it is sometimes observed, that after good convergence over many cycles (therefore the problem is particularly prominent if tight convergence thresholds are applied, otherwise the calculations are often already declared to be converged), all of a sudden (a) the geometry optimization stops, (b) the geometry optimization generates no further output but pysis continues to consume CPU time, or (c) the molecular structure is strongly damaged, causing crashes or long compute times of the actual calculators. This behavior is sometimes reproducible, sometimes not. I would personally expect, that the strong geometry changes make the redundant coordinates linearly dependent so that structural updates fail.
To Reproduce Attached is a case where (c) took place. The starting structure is admittedly a little weird (one short H-H distannce) form of n-decane, but on the other hand one of the examples that turned out to be well reproducible. Attached is the corresponding input, the call was “pysis input.yaml > pysis.out”. Furthermore attached is the obtained output and the corresponding trajectory for comparison.
Expected behavior I would think that if upon these major changes the redundant coordinates are newly constructed (and maybe historic coordinate update information is discarded if this takes place) this behavior is avoided. Also going back one structure in the trajectory if an update obviously delivers nonsense could help to avoid/repair the observed case.
OS and Python:
Pysisyphus version 0.7.6.post2 pysis.txt input_xyz.txt input_yaml.txt optimization_trj.txt