Using the new version with a wrapper around xtb program.

[goxeq]

I am using a version of crest, with a custom wrapper around xtb program in order to refine energies at DFT level. That is: when my wrapper detects that xtb was called with "--opt" keyword, it runs the xtb program and for the final structure it calculates a DFT single point energy.

However, in order to not do redundant calculation, I save all optimization results and the DFT energies in sqlite database. Thus, after the initial xtb optimization, I compare the optimized structure (based on rotation constants) and resulting GFN2 energy to those already stored in the sqlite database and only do the DFT single point if I haven't done it already.

Would something like this be feasible to be implemented with the crest 3.0? With the new [[calculation.level]] method generic, as I read the documentation, this "hack" will no longer be possible as the generic method is only supposed to calculate gradients and not handle the whole optimization.

Unfortunately, I was not able to test behavior of the new version yet, because it segfaulted even with a simple input like this (input was just crest input.xyz, see input and "output" below).

20
butad 0 1
C     0.40587200000000  -0.69230700000000  -1.21463700000000
C     0.90743500000000   0.56830000000000  -1.86964900000000
H     1.83773300000000   0.35757800000000  -2.41345500000000
C     1.00013600000000  -1.13886300000000  -0.10559600000000
C     2.16302100000000  -0.37520500000000   0.47280900000000
H     3.06376300000000  -0.56411700000000  -0.12600300000000
H     0.66221300000000  -2.04468300000000   0.38883500000000
C     1.88485200000000   1.14210200000000   0.46558800000000
H     2.81965400000000   1.67671500000000   0.66115300000000
C     1.19640500000000   1.65879600000000  -0.81765300000000
H     1.77431900000000   2.46144300000000  -1.28639300000000
C    -0.10824300000000   2.28870900000000  -0.33534300000000
C     0.92929700000000   1.51105400000000   1.59808800000000
N    -0.14555800000000   2.18493800000000   1.04448300000000
O    -0.97169000000000   2.79473600000000  -1.01498700000000
O     1.06280300000000   1.26989500000000   2.77602800000000
H    -0.43341400000000  -1.22138700000000  -1.65603900000000
H     0.19334400000000   0.96020500000000  -2.59785200000000
H    -0.92332800000000   2.52006900000000   1.59670600000000
H     2.38728100000000  -0.68886600000000   1.49515700000000

------------------------------------------------
 Generating MTD length from a flexibility measure
 ------------------------------------------------
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source             
crest              00000000026256D0  Unknown               Unknown  Unknown
crest              00000000023EB801  Unknown               Unknown  Unknown
crest              00000000004ACA0D  crest_xtbsp_              231  singlepoint.f90
crest              000000000065FD64  md_length_setup_           55  choose_settings.f90
crest              0000000000506224  crest_search_imtd          77  search_conformers.f90
crest              0000000000404278  MAIN__                    238  crest_main.f90
crest              000000000040334D  Unknown               Unknown  Unknown
crest              00000000026279A0  Unknown               Unknown  Unknown
crest              000000000040322E  Unknown               Unknown  Unknown

[pprcht]

By "something like this" you mean do an xtb optimization and then a DFT singlpoint on top? If that is what you mean, yes, that is already prepared and for some runtypes already available with the new input format. I need to write the new documentation still...

The input you posted runs for me without issues, may I ask what build did you use for the binary? --dry should tell you.

[goxeq]

Thank you for clarification. I will try to change my code to use the new version after I figure out why it does not work for me yet.

Regarding the segfault: I took the latest latest continuous release. The complete output file is below. By the way, the calculation proceeds normally with the -legacy option specified.

       CREST version    : 3.0pre
  timestamp        : Thu Feb  1 09:41:09 UTC 2024
  commit           : 4f4cd00
  compiled by      : 'runner@fv-az1431-468'
  Fortran compiler : intel 2021.7.1
  C compiler       : intel 2021.7.1
  build system     : meson 1.2.0

crest_segfault.txt

[pprcht]

Okay, I will cross-check the continuous release with my local build.

The core difference between the >3.0 versions and older ones (or the --legacy option for that fact) is that the calculation backend replaces xtb with internal tblite calculators. A whole bunch of I/O is avoided.

[pprcht]

I believe the segfault might have been an issue of the Intel compiler version used in the GitHub workflow build, and I was able to reproduce the error with the continuous release binary. I updated it to 2023.1.0 now, which seems to fix the issue.

[goxeq]

The new continuous release build seems to work now for the Diels-Alder adduct. It still does not work for a simple thing like H2 molecule (coordinates below; the --legacy version does work). Should I create separate issue out of that?

2
hydrogen
H 0. 0. 0.
H 0. 0. 0.77

[pprcht]

Nah it's fine no separate issue needed, I'll take a look.

[pprcht]

So, does a simple runtype of CREST 3.0 work for you? I.e. running crest input.xyz --sp or crest input.xyz --opt for the hydrogen molecule? For me it does with the continuous release. Running conformational sampling for diatomics is a bit pointless, and the metadynamics might also rip such molecules apart. Sometimes these crash, but I don't really see a point in trying to circumvent it if the energy and gradient evaluation works fine otherwise.

[goxeq]

Yes, that works. The conformational sampling for diatomics is indeed pointless. But typically I would use crest as part of a pipeline and it is convenient to be able to handle all species uniformly. Feel free to close this issue.