Closed ekwan closed 4 years ago
Update: setting XTBPATH
to the Anaconda location seems to work, but I'm still getting the precision errors.
$ unset XTBPATH
$ xtb --gfn 2 h2.xyz | grep TOTAL
| TOTAL ENERGY -5.176184150977 Eh |
normal termination of xtb
Note: The following floating-point exceptions are signalling: IEEE_UNDERFLOW_FLAG IEEE_DENORMAL
$ xtb --gfn 0 h2.xyz | grep TOTAL
| TOTAL ENERGY -5.297026667160 Eh |
normal termination of xtb
Note: The following floating-point exceptions are signalling: IEEE_INVALID_FLAG IEEE_DENORMAL
$ export XTBPATH=/Users/ekwan/anaconda2/envs/presto/share/xtb
$ xtb --gfn 2 h2.xyz | grep TOTAL
| TOTAL ENERGY -0.903796715990 Eh |
normal termination of xtb
Note: The following floating-point exceptions are signalling: IEEE_INVALID_FLAG IEEE_UNDERFLOW_FLAG IEEE_DENORMAL
$ xtb --gfn 0 h2.xyz | grep TOTAL
| TOTAL ENERGY -1.008391404901 Eh |
normal termination of xtb
Note: The following floating-point exceptions are signalling: IEEE_INVALID_FLAG IEEE_DENORMAL
I'm missing some crucial information to resolve this, but let me guess: /Users/ekwan/software/xtb
contains a clone of the GH repository checked out from the current master (which is almost at version 6.3) while you run calculations with the 6.2.3 binary from conda-forge.
This constellation is not going to work, since the current master changes the format of the parameter files, it can detect parameter files with old format and reject those, but the conda-forge build does not know about the new format and will produce garbage. Note that the parameters for GFN1-xTB and GFN2-xTB are compiled into the source code and can be loaded if the XTBPATH
does not contain a parameter file, therefore you will get correct results that way.
Regarding the floating point exceptions, probably we should do something about this, but since they did not cause any major problems so far, this is low-priority.
That's right! I've set XTBHOME to the conda location. Is that the correct solution? Should this be done automatically by conda during setup?
I won't worry about the fp problems for now, thanks for clarifying. I really appreciate your rapid responses!
Thanks for tagging me as "invalid"! 🤣 That's very GATTACA of you! Thanks again.
I have to keep overview over tasks and this seems to be a user error.
For conda-forge the parameters should be in /Users/ekwan/anaconda2/share/xtb
. Not sure if I can force conda to export environment variables as well, if so, this should be an issue for the xtb-feedstock repository.
I fixed most of this issues in ea97c6db42c463b25bd9bda237ee79a332c4f3a3 by avoiding name collisions between new and old parameter files, xtb
should now savely fall back to internal parameter files, which is suitable for all methods except for GFN0-xTB. But since we consider GFN0-xTB experimental, this is not going to change and will require manual setup of the XTBPATH
for now.
Thanks!
Hi Everyone,
Since the Python API for xtb is still buggy, I have been running xtb from the command line. Unfortunately, I am experiencing some unexpected behavior with XTBPATH and the configuration files. Here's a very simple input xyz:
Here's my xtb version:
xtb version 6.2.3 (conda-forge)
. Here's my environment:Now, watch this:
As you can see, it printed out an energy, but I got all kinds of errors: configuration file errors and some kind of floating point error. Now, suppose I set
XTBPATH
to some nonsense:This time it runs! Note the energy is totally different:
OK, there are still underflow errors, but fine. But now GFN0 is broken:
I would really appreciate some help.
Thanks, -Eugene