Initial geometry optimization error

[tfhughes]

Please see the attached propane.log Crest stdout from a Linux job:

Initial geometry optimization failed! Please check your input.

The same job with the same input runs fine on Mac. Both Linux and Mac compiled by my team. I see the same behavior for a water molecule but there is another example, Hf metal complex, propane.tar.gz we have that runs fine on both OSs. Any idea what is happening here?

[tfhughes]

based on my tests this seems like it is related to the number of atoms in the input xyz

[pprcht]

Unfortunately I can't reproduce it (using your provided toml), neither on my own system, nor on our cluster.

Could you try the simpler crest propane.xyz --opt to see if that works at least?

Also, could you send me the last bit of stdout from the crest --dry command, I'd like to see what settings were used in your build?

[tfhughes]

Thanks for the reply, 'crest propane.xyz --opt' does work, but when I do 'crest propane.xyz' to do a csearch it fails with the same error as above. Very strange. Attaching dry Crest output. crest_dry.txt

[tfhughes]

So for 'crest propane.xyz --opt' I should be more specific. The job doesn't throw that error and runs to the 'Crest terminated normally.' messaged at the end but the actual optimization I guess fails:

   *** GEOMETRY RELAXATION FAILED ***

 geometry optimization FAILED!

--------------------------------------------------------------------------------
> Final molecular gradient ( Eh/a0 ):
             ∂E/∂x             ∂E/∂y             ∂E/∂z
       -0.00680132        0.00680132        0.00149369
       -0.01342318       -0.00973889       -0.00968125
        0.00973889        0.01342318       -0.00968125
        0.00907807       -0.00907807        0.01386877
       -0.00000371        0.00000371       -0.00587463
        0.01030868        0.01030777        0.00693644
       -0.01030777       -0.01030868        0.00693644
        0.00680818       -0.00680818        0.00149511
       -0.00908125        0.00908125        0.01387146
        0.01342479        0.00974136       -0.00968238
       -0.00974136       -0.01342479       -0.00968238
> Gradient norm:        0.05417775 Eh/a0

========================================
 TOTAL ENERGY       -10.4958803653 Eh
 GRADIENT NORM        0.0541777462 Eh/a0
========================================
 WARNING: geometry optimization FAILED!

 -----------------
 Wall Time Summary
 -----------------
 CREST runtime (total)               0 d,  0 h,  0 min,  0.258 sec
 ------------------------------------------------------------------
 Geometry optimization      ...        0 min,  0.028 sec ( 10.873%)
 I/O and setup              ...        0 min,  0.230 sec ( 89.127%)
 ------------------------------------------------------------------
 * wall-time:     0 d,  0 h,  0 min,  0.258 sec
 *  cpu-time:     0 d,  0 h,  0 min,  0.035 sec
 * ratio c/w:     0.137 speedup
 ------------------------------------------------------------------
 * Total number of energy+grad calls: 2

 CREST terminated normally.```

[pprcht]

Right, the output suggests that energies and gradients are correctly calculated but somehow there is a breakdown in the optimization routine. That is really odd.

My main suspicion right now is the build. The --dry output tells me that the Fortran compiler is ifort, while the C compiler is gcc. Its not a good idea to have different vendors for the two compilers, it certainly caused problems in the past. Intels icx should work if you want to stay with the meson build system.

[pprcht]

Hi, I have an update on this.

It turns out this was caused by an uninitialized boolean in the wrapper routine for LAPACK's sspevx routine, which got set to true for the gcc build, and false for the ifort build.

Since this specific routine is only called for small molecules (< 50 DOF) if not requested explicitly and might still return false (which we want here) for the boolean, depending what was in memory at runtime, the error reproduction was a bit weird. However, it is fixed now and the correct code will be merged into the main branch with the next PR (most likely tomorrow).

[tfhughes]

Great, thank you!