NaN results in H2 geometry optimisation #621
Comments
joegilkes
added
the
unconfirmed
|
Cannot reproduce this behavior with |
|
Strange, my initial result was with my own compilation of I've had multiple occurrences of this issue on my version now. I'll try running my code with the precompiled 6.4.1 binary and see if the issue occurs with that. |
|
This is still occurring randomly within the precompiled release of Instead of looping through all available iterations in the final singlepoint calculation, This calculation is being run on the following geometry with the line xtbin.xyz: |
|
I've also observed this error with slightly different behaviour, where the calculation fully freezes at the same point in the xTB output (iteration 17 of the final singlepoint calculation) and has to be manually terminated, resulting in the following: |
|
Is this still an issue with the latest version of xTB? If so, we may need more information on the hardware you are running on to see if we can reproduce this error. |
|
Just tested with both Conda xTB 6.5.0 and 6.5.1, and with the standalone 6.5.1 release from GitHub. The issue still persists with both Conda versions, although it required new H2 geometries to trigger the issue as the ones I had from when I last tested this now optimise completely fine. Trying the same new geometry with the standalone version runs this optimisation completely fine, but since the geometries that trigger this seem to be fairly random, it could be that the bug would still occur given a different geometry. I'm going to write up a quick Python script to generate new geometries and keep running xTB to try and replicate the conditions that the geometries are in as closely as possible without having to run the whole project that this is occurring in. I'll update with results soon. |
|
Also worth mentioning that Conda xTB 6.5.1 is also sending this to |
|
After generating thousands of H2 geometry files which match the erroring ones as closely as possible (down to exact whitespace placement and significant figures in the xyz file, and the initial H-H bond length used in the latest erroring geometry), I haven't been able to reproduce this bug once with the Python script (running on the same hardware as before). At this point, I'm at a complete loss for what causes this in the first place, since I don't see how it can be related to the geometry file anymore. Script I'm using to attempt to find faulty geometries: import numpy as np
import random
import subprocess
import os
# Desired bond length (Ang)
bl = 0.7766010889417894
if not os.path.exists('calc'):
os.mkdir('calc')
rmfiles = ['.xtboptok', 'charges', 'wbo', 'xtb.out', 'xtbin.xyz', 'xtbopt.log', 'xtbopt.xyz', 'xtbrestart', 'xtbtopo.mol']
os.chdir('calc')
loop = True
counter = 0
while loop:
counter += 1
for rmfile in rmfiles:
if os.path.isfile(rmfile):
os.remove(rmfile)
p1 = np.zeros(3)
p2 = np.zeros(3)
for i in range(3):
p1[i] = random.uniform(-15.0, 15.0)
p2[i] = random.uniform(-15.0, 15.0)
uvec = (p2 - p1)/np.linalg.norm(p2 - p1)
disp = uvec * bl
p2 = p1 + disp
with open('xtbin.xyz', 'w') as f:
f.write(' 2\n')
f.write(' 0.000000000000000E+000\n')
f.write(f'H {p1[0]:11.8} {p1[1]:11.8} {p1[2]:11.8}\n')
f.write(f'H {p2[0]:11.8} {p2[1]:11.8} {p2[2]:11.8}\n')
with open('xtb.out', 'w') as f:
proc = subprocess.run(['xtb' ,'xtbin.xyz', '--opt'], stdout=f)
with open('xtbopt.xyz', 'r') as f:
lines = f.readlines()
cline = lines[1].split()
if cline[1] == 'NaN':
print('Energy: NaN')
print(f'Found after {counter} trials.')
loop = False
else:
print(f'Energy: {cline[1]}') |
|
Turns out I was being too impatient - the above script actually does allow me to reproduce the bug on completely different hardware! It does take quite a few trials of randomised H2 xyzs to find faulty geometries (averaged 2900 trials over 10 runs for me, so usually 2-3 minutes on my laptop), but it manages to find a faulty H2 geometry every time. To better clarify what the script is doing, it's taking the H-H bond length from the latest faulty H2 geometry that I generated in my actual workflow, then iteratively creating random H2 xyzs which share this bond length, writing them out in the exact format that my Fortran code in my workflow uses, running xTB and checking the resulting optimised xyz for a NaN energy. If it finds it, the script stops iterating and displays the number of trials, leaving all the xTB running/log files in the Since I can get this to happen on other hardware, hopefully it should also be reproducible on your end now. |
|
Seems like an issue with the history of the wavefunction, which makes it very hard to reproduce. Try to take the final structure and run |
|
Thanks for confirming. Switching to LBFGS seems to mitigate this like you said. Are there any performance drawbacks to using LBFGS with xTB or does it perform just as well as the default? |
|
The RF based optimizer is the default for historical reasons. My LBFGS implementation should be competitive and is already the default for all systems larger than 500 atoms, so I am confident it can be a robust default. Changing defaults is always something that should be well though through, but this is up to the project maintainers to decide on. |
|
Sorry to report that this issue does still appear to be occurring with LBFGS as well, albeit much less frequently so it's even harder to diagnose. |
|
If I run an opt on H2 with ALPB, I see something very similar with XTB v6.5.1 and v6.7.0. The initial SCC will run fine, but in the first optimization cycle it shows almost immediate problems, with NaN for the energy until it runs out of iterations. See attached for v6.7.0 output |
|
@joegilkes, please, have a look on #1168. It should fix your problem For 2000 iterations of your script, I did not found anything. |
Describe the bug
I'm writing some code that's doing automated exploration of chemical reaction space, using GFN2-xTB to optimise individual product molecules. On occasion, this involves running geometry optimisations on H2. Usually this is fine, but on maybe 1% of these occasions, xTB starts throwing NaN values all throughout it's output. I've not observed this with any other molecules running with the same settings, only H2, and the vast majority of the time the calculation runs fine.
The issue appears to stem from the exact geometry used, as a fresh H2 geometry with a bond length of 0.7 Ang will work normally while a specific geometry that has failed before will continue to fail on reruns. Furthermore, despite outputting mostly NaNs, the faulty calculation believes it has run successfully, such that it doesn't trigger any errors in my code until it's too late.
To Reproduce
Steps to reproduce the behaviour:
xtbin.xyz(doesn't happen with inputh2.xyz)xtb --iterations 1000 --opt normal --grad xtbin.xyzInputs
Sorry for not uploading, Github won't take xyzs.
xtbin.xyz:h2.xyz:Output
See xtb.log past the Final Singlepoint stage.
Expected behaviour
Calculation is expected to run as it would when the same command is run with
h2.xyz(rough geometry created by hand) instead ofxtbin.xyz(geometry created by code).The text was updated successfully, but these errors were encountered: