grimme-lab / xtb

Semiempirical Extended Tight-Binding Program Package

Semiempirical Extended Tight-Binding Program Package

This is the offical repository of the xtb program package developed by the Grimme group in Bonn.

Installation

Statically linked binaries (Intel Compiler) can be found at the latest release page, a version for Linux (Intel 18.0.2, GLIBC 2.19) and Windows (Intel 2022) is provided. The xtb program and library are packaged on conda-forge for Linux (x86_64, aarch64, ppc64le) and MacOS (x86_64, arm64). For homebrew users a custom tap is available at grimme-lab/homebrew-qc providing prebuilt MacOS/x86_64 binaries, for MacOS/arm64 binaries will be compiled on installation automatically.

Bleeding edge releases (Linux only) of the latest source from this repository are available on the continuous release tag.

This projects supports two build systems, meson and CMake. A short guide on the usage of each is given here, follow the linked instructions for a more detailed information (meson guide, CMake guide).

Compilers:

1. ifort(<=2021.10.0), icc(<=2021.10.0)
2. gfortran(<=13.2.0), gcc(<=13.2.0)

Meson

Using meson as build system requires you to install a fairly new version like 0.62 or newer. To use the default backend of meson you have to install ninja version 1.7 or newer.

export FC=ifort CC=icc
meson setup build --buildtype release --optimization 2 -Dfortran_link_args="-qopenmp"
ninja -C build test

Make sure the testsuite is running without errors.

To install the xtb binaries to /usr/local use (might require sudo)

ninja -C build install

For more information on the build with meson see the instructions here.

CMake

The CMake build system requires both make and CMake to be installed, the latter has to be version 3.9 or newer.

Building xtb with CMake works with the following chain of commands:

cmake -B build -DCMAKE_BUILD_TYPE=Release
make -C build
make -C build test

To install the xtb binaries to /usr/local use (might require sudo)

make -C build install

For more detailed information on the build with CMake see the instructions here.

Conda

Installing xtb from the conda-forge channel can be achieved by adding conda-forge to your channels with:

conda config --add channels conda-forge

Once the conda-forge channel has been enabled, xtb can be installed with:

conda install xtb

It is possible to list all of the versions of xtb available on your platform with:

conda search xtb --channel conda-forge

Documentation

The xtb documentation is hosted at read-the-docs.

Contributing

Please read our contributing guidelines before contributing to this project.

Contributors

We are developing this program to make our research possible. Many of the features that xtb has today have been added because there was a dire need for them and we had many contributors who made these features reality:

• P. Atkinson (@patrickatkinson)
• C. Bannwarth (@cbannwarth)
• F. Bohle (@fabothch)
• G. Brandenburg (@gbrandenburg)
• E. Caldeweyher (@f3rmion)
• M. Checinski
• S. Dohm (@thch-dohm)
• S. Ehlert (@awvwgk)
• S. Ehrlich
• I. Gerasimov (@FulgurIgor)
• S. Grimme (@stefangrimme)
• C. Hölzer (@hoelzerC)
• A. Katbashev (@Albkat)
• J. Koopman (@JayTheDog)
• C. Lavinge (@clavigne)
• S. Lehtola (@susilehtola)
• F. März
• M. Müller (@marcelmbn)
• F. Musil (@felixmusil)
• H. Neugebauer (@haneug)
• J. Pisarek
• C. Plett (@cplett)
• P. Pracht (@pprcht)
• F. Pultar (@pultar)
• J. Seibert (@liljay42)
• P. Shushkov
• S. Spicher (@sespic)
• M. Stahn (@MtoLStoN)
• M. Steiner (@steinmig)
• T. Strunk (@timostrunk)
• J. Stückrath (@jbstueckrath)
• T. Rose (@Thomas3R)
• J. Unsleber (@nabbelbabbel)

Contributors are listed in alphabetical order. Some contributions predate the GitHub release of this project and are not visible in the repository commit history. For the contributor data from the commit history since then look here.

Citations

General Reference to xtb and the implemented GFN methods:

• C. Bannwarth, E. Caldeweyher, S. Ehlert, A. Hansen, P. Pracht, J. Seibert, S. Spicher, S. Grimme WIREs Comput. Mol. Sci., 2020, 11, e01493. DOI: 10.1002/wcms.1493

for GFN-xTB:

• S. Grimme, C. Bannwarth, P. Shushkov, J. Chem. Theory Comput., 2017, 13, 1989-2009. DOI: 10.1021/acs.jctc.7b00118
• C. Bannwarth, S. Ehlert and S. Grimme., J. Chem. Theory Comput., 2019, 15, 1652-1671. DOI: 10.1021/acs.jctc.8b01176
• P. Pracht, E. Caldeweyher, S. Ehlert, S. Grimme, ChemRxiv, 2019, preprint. DOI: 10.26434/chemrxiv.8326202.v1

for GFN-FF:

• S. Spicher and S. Grimme, Angew. Chem. Int. Ed., 2020, 59, 15665–15673 DOI: 10.1002/anie.202004239

for GBSA and ALPB implicit solvation:

• S. Ehlert, M. Stahn, S. Spicher, S. Grimme, J. Chem. Theory Comput., 2021, 17, 4250-4261 DOI: 10.1021/acs.jctc.1c00471

for ddCOSMO and CPCM-X implicit solvation:

• M.Stahn, S. Ehlert, S. Grimme, J. Phys. Chem. A, 2023, XX, XXX-XXX DOI: 10.1021/acs.jpca.3c04382

for DFT-D4:

• E. Caldeweyher, C. Bannwarth and S. Grimme, J. Chem. Phys., 2017, 147, 034112. DOI: 10.1063/1.4993215
• E. Caldeweyher, S. Ehlert, A. Hansen, H. Neugebauer, S. Spicher, C. Bannwarth and S. Grimme, J. Chem. Phys., 2019, 150, 154122. DOI: 10.1063/1.5090222
• E. Caldeweyher, J.-M. Mewes, S. Ehlert and S. Grimme, Phys. Chem. Chem. Phys., 2020, 22, 8499-8512. DOI: 10.1039/D0CP00502A

for sTDA-xTB:

• S. Grimme and C. Bannwarth, J. Chem. Phys., 2016, 145, 054103. DOI: 10.1063/1.4959605

in the mass-spec context:

• V. Asgeirsson, C. Bauer and S. Grimme, Chem. Sci., 2017, 8, 4879. DOI: 10.1039/c7sc00601b
• J. Koopman and S. Grimme, ACS Omega, 2019, 4, 12, 15120-15133. DOI: 10.1021/acsomega.9b02011
• J. Koopman and S. Grimme, J. Am. Soc. Mass Spectrom., 2021, 32, 7, 1735-1751. DOI: 10.1021/jasms.1c00098

for metadynamics refer to:

• S. Grimme, J. Chem. Theory Comput., 2019, 155, 2847-2862. DOI: 10.1021/acs.jctc.9b00143

for SPH calculations refer to:

• S. Spicher and S. Grimme, J. Chem. Theory Comput., 2021, 17, 1701–1714. DOI: 10.1021/acs.jctc.0c01306

for ONIOM refer to:

• C. Plett, A. Katbashev, S. Ehlert, S. Grimme, M. Bursch, Phys. Chem. Chem. Phys., 2023, 25, 17860-17868. DOI: 10.1039/D3CP02178E

All references are available in bibtex format.

License

xtb is free software: you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

xtb is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose. See the GNU Lesser General Public License for more details.

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in xtb by you, as defined in the GNU Lesser General Public license, shall be licensed as above, without any additional terms or conditions.

xtb's Issues

Update binary

Would it be possible to build a new xTB binary as a result of the bugfix in 7ff4d96? This is a pretty important bugfix, and unfortunately I am having some trouble compiling xTB from source (trying to sort this out).

XTB and CREST handling of deuterium and D2O

Hello,
just an inquiry, not sure if this could be a feature.

Deuterium labeling is used quite often in mass spectrometry and nuclear magnetic resonance (NMR) for compound identification of small molecules and proteins/peptides. The same goes for modelling of hydrogen-deuterium exchange experiments using molecular dynamics. Here routines like CREST and XTB could be really useful. I am wondering if XTB actually would be able handle D and D2O, or if it is not possible (ever).

The element symbol could be D and then radius and expectation values, electronegativities and van-der-Waals radii as well as the GFN parameters can be added? That's my simplified view.

Currently it can not handle it:

#ERROR! Unknown element symbol: 'D'
abnormal termination of xtb

Thank you
Tobias

2D PBC

Is your feature request related to a problem? Please describe.
Calculations of periodic surfaces require either 2D PBC or some correction scheme to eliminate Coulombic and dispersion interaction between surfaces (e.g. truncation of Coulomb interactions as in https://journals.aps.org/prb/abstract/10.1103/PhysRevB.96.075448 ).

Describe the solution you'd like
It would be great to have true 2D PBC in xtb.

Describe alternatives you've considered
Cluster calculations aren't always the solution, and 3D PBC is out of the question due to interaction with the image of the surface.

Compile with Intel compiler suite 19

Just tried to compile xtb according to the instructions on the main page using cmake with
ifort Version **19.1.**0.166 Build 20191121 on Ubuntu 19.04.

The compile unfortunately fails in the dftd4 module due to undeclared variable tx,ty,tz in the parallel openmp sections:

xtb/dftd4.f90(2433): error #6752: Since the OpenMP* DEFAULT(NONE) clause applies, the PRIVATE, SHARED, REDUCTION, FIRSTPRIVATE, or LASTPRIVATE attribute must be explicitly specified for every variable. [TX]
do concurrent(tx = -rep(1):rep(1), &

So it seems that Intel 19 is somewhat more restrictive with respect to OpenMP declarations?

undefined reference to `tbdef_molecule_mp_write_'

I am trying to build xtb under linux and get the same undefined references, trying both cmake as well as meson/ninja.
icc as well as ifort are 18.0.1 20171018
compile goes without errors. Linking fails with (partial output from ninja -v -C build_intel test):

[93/96] icc  -o libxtb.so.6.2.2  -Wl,--as-needed -Wl,--no-undefined -shared -fPIC -Wl,--start-group -Wl,-soname,libxtb.so.6 -Wl,--whole-archive libxtb.a -Wl,--no-whole-archive -static -qopenmp -fopenmp -lmkl_rt -pthread -lifcore -limf -Wl,--end-group
FAILED: libxtb.so.6.2.2
icc  -o libxtb.so.6.2.2  -Wl,--as-needed -Wl,--no-undefined -shared -fPIC -Wl,--start-group -Wl,-soname,libxtb.so.6 -Wl,--whole-archive libxtb.a -Wl,--no-whole-archive -static -qopenmp -fopenmp -lmkl_rt -pthread -lifcore -limf -Wl,--end-group
libxtb.a(xtb_optimizer.f90.o): In function `optimizer_mp_relax_.V':
optimizer.f90:(.text+0xa0b5): undefined reference to `tbdef_molecule_mp_write_'

and a few more lines where it complains that tbdef_molecule_mp_write_ and tbdef_molecule_mp_read_ are missing.

Thanks for any help,
Gert

C/C++ Interface Oddities

Using the C/C++ interface a few odd things have shown, I'd say some of them are bugs.
(If they should be split into separate Issues I don't mind doing that but for now I will gather them here.)

First of all, the interface seem to be working fine overall.
As a C++ user I have to say: thanks for them!

The issues encountered are:

1. GFN2_calculation Bond Orders

Using

extern int
GFN2_calculation(const int* natoms, const int* attyp, const double* charge, 
const double* coord, const SCC_options* opt, const char* output, 
double* energy, double* grad, double* dipole,  double* q, double* dipm, 
double* qp, double* wbo);

The wbo array is only filled if the SCC_options opt.prlevel is >=2.
The expected behavior would be that the field is always populated, I think.

2. GFN1_calculation Bond Orders

Using

extern int
GFN1_calculation(const int* natoms, const int* attyp, const double* charge, 
const int* uhf, const double* coord, const SCC_options* opt, const char* output, 
double* energy, double* grad, double* dipole, double* q, double* wbo);

The wbo array seems to be empty (zeroes) at any given time.
However, using the executable the wbo file is created, hence I assume it should also work using the interface.
Again the expected behavior would be that the field is always populated, I think.

3. Parallel Execution of Calculations

3. Working in parallel it is not possible to have a single program run multiple calls to
   GFN1_calculation etc. at the same time. The calls do not seem to be threadsafe.
   The errors range from thrown exceptions (the timings seem to have some static type members that throw reasonable exceptions) to wild segfaults.
   Here, it would be good to note that these calls are not threadsafe and/or actually stop multiple calls vial locks before they go haywire.

For Reproducibility

Commit: bbcf06e
Compiler: gcc-8.3
[Disclaimer: The code was build using CMake instead of the given toolchain]

Can we bring back atomization energies in the output?

Is your feature request related to a problem? Please describe.
Older (before GitHub) versions of XTB would produce the atomization energy as part of the GFN1 output - in conjunction with the total SCF energy.

For many things (e.g., machine learning), the atomization energy is a more useful quantity than the total SCF energy. While workflows can calculate the atomization energy from the total SCF, it needs to be adjusted any time a molecule with different elements is presented (e.g. someone hands you something with Se or I, etc.)

Describe the solution you'd like
Ideally, I'd like the atomization energies to be automatically added to the output - or failing that, as an optional property.

Describe alternatives you've considered
It's obviously possible to manually calculate this, but workflows are much easier if it's done automatically.

If possible state how you can assist in providing data or code to to implement the feature
I'm happy to provide the atom self-energies, but I'd think you already have them as part of the various parameterizations.

opposite sign of Mulliken charges GFN1 and GFN2

Describe the bug
Using GFN1 and GFN2 yields to different mulliken charge (opposite sign).

To Reproduce
Steps to reproduce the behavior:

1. happens with input (include input files)

I included a pictures with the calculated charges for anthracene, using the same xtb version having just the changed the gfn version

2. start xtb with (all the options here)

xtb version 6.2.2 (b9950dc) compiled by '@Linux' on 03/03/2020

3. run xtb with your options and the --verbose flag
   xtb --opt normal ant.xyz --gfn 1
   xtb --opt normal ant.xyz --gfn 2

using: xtb --opt normal ant.xyz --gfn 1 --input input.inp

gives also wrong charges at the output, however, it creates the xtbout.json having the charges with a flipped sign.

input.inp contains:
$chrg 0
$spin 0
$write
json=true
$end

4. output showing the error

http://nanomatch.com/nanomatch-files/bugreports/xtbmulliken/stats.jpg

http://nanomatch.com/nanomatch-files/bugreports/xtbmulliken/pm.png

Expected behaviour
Both signs in GFN1 and GFN2 should be the same.

I am interested in the CM5 charges and not quite sure about their values right now. Are they calculated before or after the sign changes.

Compilation problems

Hey,

it is great, that you put xTB now on GitHub!

I have some problems to compile it on Ubuntu 18.04, intel 19, meson nin0.51.2 and ninja 1.9.0.

• find_library() does not find the MKL-libraries. I had to fix it by adding the library path of those libraries via the dirs keyword argument (as an ugly hack).

• As find_library() picked up the shared libraries instead of the static ones, the linking efforts with the manually specified -static option failed. I, therefore, also removed those options from the build file.

• However, although everything compiled, the linking of xtb_test failed, due to

cc  -o xtb_test 'xtb_test@exe/TESTSUITE_tests_peeq.f90.o' 'xtb_test@exe/TESTSUITE_assertion.f90.o' 'xtb_test@exe/TESTSUITE_tbdef_molecule.f90.o' 'xtb_test@exe/TESTSUITE_geometry_reader.f90.o' 'xtb_test@exe/TESTSUITE_eeq_model.f90.o' 'xtb_test@exe/TESTSUITE_pbc_tools.f90.o' 'xtb_test@exe/TESTSUITE_dftd4.f90.o' 'xtb_test@exe/TESTSUITE_gfn2.f90.o' 'xtb_test@exe/TESTSUITE_gfn1.f90.o' 'xtb_test@exe/TESTSUITE_gfn0.f90.o' 'xtb_test@exe/TESTSUITE_peeq.f90.o' -Wl,--no-undefined -Wl,--as-needed -Wl,--start-group libxtb.a /opt/repo/intel/2018/compilers_and_libraries_2018.3.222/linux/mkl/lib/intel64/libmkl_intel_lp64.so /opt/repo/intel/2018/compilers_and_libraries_2018.3.222/linux/mkl/lib/intel64/libmkl_intel_thread.so /opt/repo/intel/2018/compilers_and_libraries_2018.3.222/linux/mkl/lib/intel64/libmkl_core.so /opt/repo/intel/2018/compilers_and_libraries_2018.3.222/linux/compiler/lib/intel64/libiomp5.so -lpthread -lm -ldl -pthread '-Wl,-rpath,$ORIGIN/:/opt/repo/intel/2018/compilers_and_libraries_2018.3.222/linux/mkl/lib/intel64:/opt/repo/intel/2018/compilers_and_libraries_2018.3.222/linux/compiler/lib/intel64' -Wl,-rpath-link,/mnt/local/aradi/volatile/xtb/build_intel/ -Wl,-rpath-link,/opt/repo/intel/2018/compilers_and_libraries_2018.3.222/linux/mkl/lib/intel64 -Wl,-rpath-link,/opt/repo/intel/2018/compilers_and_libraries_2018.3.222/linux/compiler/lib/intel64 -lifcore -limf -Wl,--end-group
/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o: In function `_start':
(.text+0x20): undefined reference to `main'

Any advices, how I get the things compiled? I am not a great expert with Meson, so the issues may be trivial.

Thanks in advance.

Initial velocities in MD/MTD

Is your feature request related to a problem? Please describe.
When trying to model bimolecular reactions using MTD, there is no way to force selected molecules to collide.

Describe the solution you'd like
Set initial velocities for atom groups. For example, let's imagine we have molecules A and B. If I want molecule A to collide with molecule B, I initialize the velocities of A to be proportional to the vector (B_center_of_mass - A_center_of_mass). Of course, this initial velocity would have to be added to the random "thermal" initial velocity.

Describe alternatives you've considered
Reaction path functionality solves this problem for simple cases, but I'd like a more general one.
Can this be done with ASE? Or by hand-modifying the mdrestart file?

Cannot compile xtb: what if there is no static pthread?

Describe the bug
It is impossible to compile xtb on our supercomputer. Indeed, it is a redhat derivatives, thus there is no static -pthread, -lm and -ldl. This is a bug in the sense that this fact known for a long time, and, anyway, compiling a program with a static pthread is not a good idea (thus, our system administrator refuses to provide static version of those libraries).

For the record, here is the actual (end of) input:

[278/280] Linking target xtb_test.
FAILED: xtb_test 
icc  -o xtb_test 'xtb_test@exe/TESTSUITE_tests_peeq.f90.o' 'xtb_test@exe/TESTSUITE_assertion.f90.o' 'xtb_test@exe/TESTSUITE_tbdef_molecule.f90.o' 'xtb_test@exe/TESTSUITE_tbdef_wsc.f90.o' 'xtb_test@exe/TESTSUITE_geometry_reader.f90.o' 'xtb_test@exe/TESTSUITE_eeq_model.f90.o' 'xtb_test@exe/TESTSUITE_pbc_tools.f90.o' 'xtb_test@exe/TESTSUITE_dftd4.f90.o' 'xtb_test@exe/TESTSUITE_gfn2.f90.o' 'xtb_test@exe/TESTSUITE_gfn1.f90.o' 'xtb_test@exe/TESTSUITE_gfn0.f90.o' 'xtb_test@exe/TESTSUITE_peeq.f90.o' 'xtb_test@exe/TESTSUITE_symmetry.f90.o' 'xtb_test@exe/TESTSUITE_thermo.f90.o' 'xtb_test@exe/TESTSUITE_tbdef_atomlist.f90.o' -Wl,--no-undefined -Wl,--as-needed -static -Wl,--start-group libxtb.a -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5 -lpthread -lm -ldl -pthread '-Wl,-rpath,$ORIGIN/' -Wl,-rpath-link,/home/pbeaujea/xtb/build_intel/ -lifcore -limf -Wl,--end-group
ld: cannot find -lpthread
ld: cannot find -lm
ld: cannot find -ldl
[279/280] Linking target xtb.
FAILED: xtb 
icc  -o xtb 'xtb@exe/xtb_program_main.f90.o' -Wl,--no-undefined -Wl,--as-needed -static -Wl,--start-group libxtb.a -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5 -lpthread -lm -ldl -pthread '-Wl,-rpath,$ORIGIN/' -Wl,-rpath-link,/home/pbeaujea/xtb/build_intel/ -lifcore -limf -Wl,--end-group
ld: cannot find -lpthread
ld: cannot find -lm
ld: cannot find -ldl
ninja: build stopped: subcommand failed.

To Reproduce
Steps to reproduce the behaviour: try to compile xtb on a Redhat system with no static pthread.

Expected behaviour
xtb should compile correctly

Additional context

I did try to make some modification in the meson.build, but I'm not an expert in both meson and intel. According to some sources, one of the solution should be to use -static-intel instead of -static (lines 45 and 46), but then I end up with the following problems:

FAILED: xtb_test 
icc  -o xtb_test 'xtb_test@exe/TESTSUITE_tests_peeq.f90.o' 'xtb_test@exe/TESTSUITE_assertion.f90.o' 'xtb_test@exe/TESTSUITE_tbdef_molecule.f90.o' 'xtb_test@exe/TESTSUITE_tbdef_wsc.f90.o' 'xtb_test@exe/TESTSUITE_geometry_reader.f90.o' 'xtb_test@exe/TESTSUITE_eeq_model.f90.o' 'xtb_test@exe/TESTSUITE_pbc_tools.f90.o' 'xtb_test@exe/TESTSUITE_dftd4.f90.o' 'xtb_test@exe/TESTSUITE_gfn2.f90.o' 'xtb_test@exe/TESTSUITE_gfn1.f90.o' 'xtb_test@exe/TESTSUITE_gfn0.f90.o' 'xtb_test@exe/TESTSUITE_peeq.f90.o' 'xtb_test@exe/TESTSUITE_symmetry.f90.o' 'xtb_test@exe/TESTSUITE_thermo.f90.o' 'xtb_test@exe/TESTSUITE_tbdef_atomlist.f90.o' -Wl,--no-undefined -Wl,--as-needed -static-intel -Wl,--start-group libxtb.a -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5 -lpthread -lm -ldl -pthread '-Wl,-rpath,$ORIGIN/' -Wl,-rpath-link,/home/pbeaujea/xtb/build_intel/ -lifcore -limf -Wl,--end-group
icc: warning #10237: -lcilkrts linked in dynamically, static library not available
/lib/../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
[279/280] Linking target xtb.
FAILED: xtb 
icc  -o xtb 'xtb@exe/xtb_program_main.f90.o' -Wl,--no-undefined -Wl,--as-needed -static-intel -Wl,--start-group libxtb.a -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5 -lpthread -lm -ldl -pthread '-Wl,-rpath,$ORIGIN/' -Wl,-rpath-link,/home/pbeaujea/xtb/build_intel/ -lifcore -limf -Wl,--end-group
icc: warning #10237: -lcilkrts linked in dynamically, static library not available
/lib/../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
ninja: build stopped: subcommand failed.

Again, few sources mentions the -nostartfiles. After that was added to meson.build, the compilation succeeded (in a sense), but intel was actually not abbe to find the proper entry point of the program:

[278/280] Linking target xtb_test.
icc: warning #10237: -lcilkrts linked in dynamically, static library not available
ld: warning: cannot find entry symbol _start; defaulting to 0000000000408d80
[279/280] Linking target xtb.
icc: warning #10237: -lcilkrts linked in dynamically, static library not available
ld: warning: cannot find entry symbol _start; defaulting to 0000000000409380

... So all the tests fail.

.param_gbsa.solvent file location

Hi,
I wonder where the .param_gbsa.solvent file is located, which is referenced here,
or is that something the user has to provide to activate the correct solvent?

$gbsa
~~~~~
*solvent*='string'::
    solvent for the generalized born (GB) model with solvent accessable
    surface area (SASA), requires `.param_gbsa.solvent` in `XTBPATH`.
    Does not activate GBSA (use commandline).

https://github.com/grimme-lab/xtb/blob/master/man/man7/xcontrol.7.txt

Thank you
Tobias

Run xtb on a single core

I am performing crystal structure search using xtb. I need to run many xtb jobs on single cores. However, xtb always uses too many resources and then will be killed by the LSF job scheduler. So how to force xtb running on a single core? Or recompile the code?

xtb cycles option ignored

Describe the bug
The xtb cycles option is "ignored" and xtb performs more cycles than defined in command line.
Not sure if that is intended behavior or a bug.

To Reproduce
Steps to reproduce the behaviour:

xtb olestra.xyz --opt extreme --cycles 30

          :                      SETUP                      :
          :.................................................:
          :   optimization level           extreme          :
          :   max. optcycles                    30          :
          :   ANC micro-cycles                  20          :
          :   degrees of freedom              1353          :
          :.................................................:

Output below. Basically olestra can not be optimized in 30 cycles, but that should not matter.
Instead of stopping after 30 cycles it actually does 42.

........................................................................
.............................. CYCLE   42 ..............................
........................................................................
   1   -560.7620321 -0.560762E+03  0.584E-02    2.87       0.0  T
   2   -560.7620614 -0.293103E-04  0.357E-02    2.88       1.0  T
   3   -560.7620632 -0.175810E-05  0.556E-03    2.88       1.0  T
   4   -560.7620694 -0.623996E-05  0.209E-03    2.88       2.2  T
   5   -560.7620698 -0.421002E-06  0.124E-03    2.88       3.8  T
   6   -560.7620700 -0.156024E-06  0.624E-04    2.88       7.5  T
   7   -560.7620701 -0.624843E-07  0.120E-04    2.88      39.2  T
   8   -560.7620701 -0.172508E-08  0.524E-05    2.88      89.6  T
   9   -560.7620701 -0.174737E-09  0.187E-05    2.88     251.0  T
  10   -560.7620701 -0.139835E-10  0.829E-06    2.88     566.9  T
     SCC iter.                  ...        0 min,  0.876 sec
     gradient                   ...        0 min,  0.269 sec
 * total energy  :  -553.2849370 Eh     change       -0.8539492E-03 Eh
   gradient norm :     0.0173558 Eh/a   predicted    -0.8529058E-03 (  -0.12%)
   displ. norm   :     0.8264649 a      lambda       -0.1131647E-02
   maximum displ.:     0.3123654 a      in ANC's #30, #22, #28, ...

   *** FAILED TO CONVERGE GEOMETRY OPTIMIZATION IN 42 ITERATIONS ***

Please provide all input and output file such that we confirm your report.

Expected behaviour
If the user defines 30 cycles it should only run 30 cycles and not 42?

Additional context
Olestra xyz
olestra.zip

Prevent Cold Fusion

Is your feature request related to a problem? Please describe.
Currently one could be tempted to do cold fusion experiments with xtb by placing two atoms at the very same coordinate in space. Since this is a quantum chemistry program, xtb will fail to describe this interesting state of matter correctly, probably in some LAPACK call, which can't handle NaN values introduced by divide-by-zero exceptions.

Describe the solution you'd like
An input check with a warning for very short distances, that turns into an error for --strict runs would solve the problem.

Describe alternatives you've considered
It's always garbage in garbage out, we can try to prevent it by adding a layer of warnings and errors.

Additional context
Happened in #27.

Related input:

$coord
   0.0  0.0  0.0  S
   0.0  0.0  0.0  Ar
   0.0  0.0  0.0  Ca
   0.0  0.0  0.0  Sm
$end

Importing `interface.py` requires ASE anyway

Describe the bug
I'm trying to achieve an interface between gaussian and xtb in order to perform xtb:QM onium calculations. Until recently (since it wasn't possible for me to compile xtb in the past), I was using a custom interface inspired by the previous python file (which does not work with the current version, for this reason), but I would prefer to rely on your implementation of the interface.py file.

I don't really want to have ASE as a dependence for that, since I only need to perform a bridge between the two codes. Not that ASE is a heavy dependence, but it would be weird to require it.

To Reproduce
Steps to reproduce the behaviour:

1. I add the python directory to PYTHONPATH
2. In the python code, I use from xtb import interface

The result is, obviously,

Traceback (most recent call last):
  File "/home/pbeaujea/g2xtb_interface/interface.py", line 11, in <module>
    from xtb import interface as xtb_interface
  File "/home/pbeaujea/.install_stda/xtb/python/xtb/__init__.py", line 20, in <module>
    from xtb.calculators import GFN1, GFN2, GFN0
  File "/home/pbeaujea/.install_stda/xtb/python/xtb/calculators.py", line 24, in <module>
    from ase.calculators.calculator import Calculator, all_changes
ImportError: No module named 'ase'

... Since __init__.py is always imported.

Expected behaviour

I get why you included calculators in __init__.py , but in my case, it is problematic: I could always copy/paste interface.py from your repo to mine, but that would not be very elegant (and its probably not the best way due to licencing stuffs).

Check and report changes in topology after geometry optimizations

Is your feature request related to a problem?

In case a molfile or sdfile is provided we know the topology of the molecular structure, which could change in a geometry optimization, molecular dynamic or even single point calculations. A change in the topology means either the calculation has yield a spurious result or the input topology was wrong, reporting this at least as warning would help users relying on the connection table found in molfiles or sdfiles to identify errors.

Describe the solution you'd like

After the calculation a complete topology information from the tight-binding wavefunction is available in form of Wiberg bond orders, this could be used to check, update or amend the topology provided from the input.

Describe alternatives you've considered

The file wbo is written and contains the Wiberg bond orders, it can always be used to amend a topology in a molfile or sdfile from the caller side.

Additional context

Suggested in #26 to aid usability of xtb for chemoinformatics.
This requires #30 to be merged.

gradient from --grad run is written two times to gradient file

Describe the bug
When doing a --grad run with the 6.3.0 preview the gradient is written two times to the gradient file. Overall no big deal but probably not intended?!

To Reproduce
xtb [any .xyz file] --grad

Expected behaviour
The gradient entry should only appear once.

Ways to gracefully end crest

Is your feature request related to a problem? Please describe.
Currently crest can not be cancelled via Ctrl-C, but keeps running and skipping until a ungraceful end.

Describe the solution you'd like
If I press Ctrl-C twice or thrice it should end.

Describe alternatives you've considered
pkill ?

If possible state how you can assist in providing data or code to to implement the feature
Insert one additional sigint process, so it can stop the code. If there is substantial overhead or delay due to that, ignore request.

Additional context
Observe multiple Ctrl-C pressed, throughout the run, until the process is finally cancelled.
Usually one or two should suffice.

 Starting optimization of generated structures
 344 jobs to do.
 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22^C 23 24 25 26 27 28 29 30 31 32 33 34 35  
 36 37^C 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53^C 54 55 56 57 58 59 60 61 62 63 64 65  
 66 67 68 69^C 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85^C 86 87 88 89 90 91 92 93 94 95  
 96 97 98 99 100 101^C 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117^C 118   119 120 121 122 123 124 125 126 127 128 129 130 131 132^C 133 134 135 136 137 138 139 140  
 141 142 143 144 145 146 147 148^C 149 150 151 152 153 154 155 156 157 158 159 160 161 162  
 163 164^C 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180^C 181 182 183 184   
 185 186 187 188 189 190 191 192 193 194 195 196^C 197 198 199 200 201 202 203 204 205 206  
 207 208 209 210 211 212^C 213 214 215 216 217 218 219^C 220 221 222 223 224 225 226 227 228   229 230 231 232 233 234 235^C 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250  
 ... 344
 done.
 Now appending opt.xyz file with new structures
 running RMSDs... done.
 E lowest :   -21.45628
 15 structures remain within     6.00 kcal/mol window
^C
 ...............................................
 A new lower conformer was found!
 Improved by    0.00130 Eh or    0.81477kcal/mol
 ...............................................

========================================
            MTD Iteration  2
========================================

     ========================================
     |         Meta-MD (MTD) Sampling       |
     ========================================

^Cforrtl: error (69): process interrupted (SIGINT)
Image              PC                Routine            Line        Source
crest              0000000001758810  Unknown               Unknown  Unknown
crest              0000000001918F10  Unknown               Unknown  Unknown
crest              00000000019812F2  Unknown               Unknown  Unknown
crest              00000000017C70E8  Unknown               Unknown  Unknown
crest              000000000175BDB0  Unknown               Unknown  Unknown
crest              000000000040ED46  Unknown               Unknown  Unknown
crest              00000000004D8737  Unknown               Unknown  Unknown

Add warning and option for adding explicit hydrogens

Is your feature request related to a problem? Please describe.

Many semiempirical tools warn if explicit hydrogen atoms are missing and add them automatically if needed (Ampac, Spartan, Gaussian etc). Currently xtb calculates any molecule with and without explicit hydrogens added. This is true for coord (tmol) and mol/sdf input. While we can expect that the user takes care of it, it would be a friendly and helpful feature nevertheless. Plus new users who are not aware of the fact, may just end up with false results.

See also case (mod/sdf reader) : #26

(R3) Input check, add information if explicit hydrogens are required in the mol/sdf file (xtb does not care about molecules to be chemically valid, they currently can have hydrogens attached or not, xtb will perform an optimization either way) give potential warning if hydrogens are missing.

Same as for 1., we need hydrogen atoms for the calculation, unless we preprocess the structure explicitly such input is not suitable for GFN-xTB calculations.

Example 1 (xtb benzene no hydrogen):
Still gives Energy and HOMO-LUMO, even with hydrogens missing.

$ cat benzene-nohydrogen.tmol
$coord
   -3.75412991991227      4.38529844566012      0.00000000000000      c
   -5.10433923622019      3.60559744648777      0.00000000000000      c
   -5.10433923622019      2.04657339336806      0.00000000000000      c
   -3.75412991991227      1.26706136680820      0.00000000000000      c
   -2.40392060360435      2.04657339336806      0.00000000000000      c
   -2.40392060360435      3.60559744648777      0.00000000000000      c
$end

xtb benzene-nohydrogen.tmol --opt extreme

number of atoms            :                     6
number of electrons        :                    24
charge                     :                     0
spin                       :                   0.0

optimized geometry written to: xtbopt.coord
           -------------------------------------------------
          | TOTAL ENERGY              -12.407726270224 Eh   |
          | GRADIENT NORM               0.000025716823 Eh/α |
          | HOMO-LUMO GAP               0.509781249335 eV   |
           -------------------------------------------------
------------------------------------------------------------------------
 * finished run on 2019/10/21 at 15:23:29.476
------------------------------------------------------------------------
 total:
 * wall-time:     0 d,  0 h,  0 min,  0.206 sec
 *  cpu-time:     0 d,  0 h,  0 min, 14.602 sec
 * ratio c/w:    70.826 speedup
 SCF:
 * wall-time:     0 d,  0 h,  0 min,  0.011 sec
 *  cpu-time:     0 d,  0 h,  0 min,  0.806 sec
 * ratio c/w:    73.660 speedup
 ANC optimizer:
 * wall-time:     0 d,  0 h,  0 min,  0.111 sec
 *  cpu-time:     0 d,  0 h,  0 min,  9.104 sec
 * ratio c/w:    82.373 speedup

normal termination of xtb

Example 2 (xtb benzene with explicit hydrogen):
Gives Energy and HOMO-LUMO, with explicit hydrogens added.

$ cat benzene-withhydrogen.tmol
$coord
   -3.75412991991227      4.38529844566012      0.00000000000000      c
   -5.10433923622019      3.60559744648777      0.00000000000000      c
   -5.10433923622019      2.04657339336806      0.00000000000000      c
   -3.75412991991227      1.26706136680820      0.00000000000000      c
   -2.40392060360435      2.04657339336806      0.00000000000000      c
   -2.40392060360435      3.60559744648777      0.00000000000000      c
   -3.75412991991227      6.33549580665351      0.00000000000000      h
   -6.79330228572693      4.58062235090121      0.00000000000000      h
   -6.79325111200677      1.07145984990115      0.00000000000000      h
   -3.75412991991227     -0.68313599418518      0.00000000000000      h
   -0.71500872781776      1.07145984990115      0.00000000000000      h
   -0.71495755409760      4.58062235090121      0.00000000000000      h
$end

xtb benzene-withhydrogen.tmol --opt extreme

number of atoms            :                    12
number of electrons        :                    30
charge                     :                     0
spin                       :                   0.0


optimized geometry written to: xtbopt.coord

           -------------------------------------------------
          | TOTAL ENERGY              -15.879640657257 Eh   |
          | GRADIENT NORM               0.000026294465 Eh/α |
          | HOMO-LUMO GAP               4.934269154112 eV   |
           -------------------------------------------------
------------------------------------------------------------------------
 * finished run on 2019/10/21 at 15:26:31.895
------------------------------------------------------------------------
 total:
 * wall-time:     0 d,  0 h,  0 min,  0.161 sec
 *  cpu-time:     0 d,  0 h,  0 min, 11.539 sec
 * ratio c/w:    71.603 speedup
 SCF:
 * wall-time:     0 d,  0 h,  0 min,  0.015 sec
 *  cpu-time:     0 d,  0 h,  0 min,  1.118 sec
 * ratio c/w:    76.941 speedup
 ANC optimizer:
 * wall-time:     0 d,  0 h,  0 min,  0.106 sec
 *  cpu-time:     0 d,  0 h,  0 min,  8.564 sec
 * ratio c/w:    81.042 speedup

normal termination of xtb

Describe the solution you'd like
A simple warning that the solution is not correct in case of explicit hydrogens missing, plus a command line switch to automatically add missing hydrogens.

Describe alternatives you've considered
Use obabel and molconvert to add explicit hydrogens.

If possible state how you can assist in providing data or code to to implement the feature
I can test molecules, including charged and radical entities.

Additional context

• openbabel add explicit hydrogens (from help file)
  PROMPT> babel -isdf 'mymols.sdf' -osmi 'outputfile.smi' -h
• molconvert add explicit hydrogens (+H after target format)
  molconvert sdf:+H "CCC"

Dynamic neighbour list for xtb?

Is your feature request related to a problem? Please describe.
dftb+ implements a convenient dynamic neighbour list with iterator. Based on the underlying lattice point generator the systems periodicity is automatically included in all energy expressions defined in real space. This would unify the way we handle real space cutoffs through the code base and allow for much less overhead when implementing periodic boundary conditions for new methods.

Describe the solution you'd like
An adaption of the dynamic neighbour list from dftb+ for xtb that can be included in all real space energy expressions used all over the code base. Also we would be able to reuse tested code instead of reinventing the wheel.

Describe alternatives you've considered
Right now we are implementing PBC by having at least two sets (three sets for Hamiltonian related contributions) of routines that either handle molecular or 3D periodic systems. This approach is somewhat error prone if the two versions are not modified consistently.

If possible state how you can assist in providing data or code to to implement the feature
Probably going to implement it myself :).

Additional context
The dftb+ implementation is available as LGPL3 and therefore compatible with the license of xtb.
Might be incompatible with the WSC approach for the electrostatics we currently have.

Compiling xtb with GCC?

Hi, I'm wondering why you say you cannot build xtb with gcc and there's no plans to support it in the future. Standards compliant code should compile straight away with any compiler. Any issues in the code should be pretty easy to solve...

Obtaining crest binary

Dear xtb developers,
what is the intended way to obtain the crest binary? It isn't on github yet, or is it?

With best regards,
Johannes

Missing libxtb.so in the xtbwrapper.py routine

Hi,
thank you for open-sourcing this project.

I tried to use the xtbwrapper.py and got an error because of a missing file "libxtb.so".

I used a conda enviroment with python 3.7 and the "setup.py install" to get xtb. The packages ase/numpy/ctypes were already installed and updated.

Then I used the following python code from the provided example:

from ase.io import read
from xtb import GFN2

mol = read('coord')
mol.set_calculator(GFN2())
energy = mol.get_potential_energy()
forces = mol.get_forces()

The error occurs after mol.set_calculator(GFN2()) is called.

The error:
"OSError: libxtb.so: cannot open shared object file: No such file or directory"

Is the libxtb.so something i have to create manually?

Best regards
Benedict

GFN1 and GFN2 ASE calculators silently ignore PBCs

Describe the bug
When using the GFN1 or GFN2 ASE calculators with ase.Atoms objects for which unit cell dimensions and periodic boundary conditions have been set (i.e., ase.Atoms.get_pbc() == [True, True, True]), they will silently ignore both and perform calculations for a single unit cell in vacuum instead.

To Reproduce
Minimal Python example:

import ase
from xtb import GFN0, GFN1, GFN2

atoms = ase.Atoms("O2")
atoms.positions[1] = [1.208, 0.0, 0.0]
atoms.set_pbc([True, True, True])

for calculator_class in [GFN0, GFN1, GFN2]:
  calculator = calculator_class()
  atoms.set_calculator(calculator)
  energies = []
  for a in range(5, 0, -1):
    atoms.set_cell([a, a, a])
    energies.append(atoms.get_potential_energy())
  print("{}: {}".format(calculator_class.__name__, energies))

Output (potential energies for varying cell dimensions, showing that they are silently ignored by GFN1 and GFN2):

GFN0: [-173.9907207598784, -174.02127400265496, -173.92621829288012, -156.64899691977354, 1349.6262678833502]
GFN1: [-248.17735365985476, -248.17735365985476, -248.17735365985476, -248.17735365985476, -248.17735365985476]
GFN2: [-215.15354883255708, -215.15354883255657, -215.15354883255674, -215.1535488325574, -215.15354883255705]

Expected behaviour
As only GFN0 is able to handle periodic systems, the GFN1 and GFN2 calculators should raise exceptions when trying to perform calculations for a ase.Atoms objects with periodic boundary conditions. I'd say this is what any user would reasonably expect.

Additional context
You already have code to this end in scripts/xtb_opt.py, I just think it would be better if this was part of the calculators themselves.

This was all tested on XTB release 6.2.1.

xtb as a MTD driver for Turbomole/Orca

Is your feature request related to a problem? Please describe.
xtb's metadynamics implementation is unique, and it would be great to be able to use it with other methods than dftb

Describe the solution you'd like
I can see that (at least in some situations) xtb can be used as a driver for Turbomole or Orca. However, attempts to run MTD with Turbomole (xtb --tm) lead to a catastrophe: although Turbomole control files are created correctly and ridft/rdgrad are called, the geometry seems to wander off uncontrollably. Any chance this could be made to work? Alternatively, would it be possible to (re)implement xtb’s RMSD-based MTD in ASE?

C-API Error handling

Preface:

From what I understand there is no way to generate Fortran(-only) code that throws exceptions that can be caught using the C-API.
For this reason I expected the status int that is the return value of all C-API functions to be this exception handle.

Problem:

Using the C-API, running a lot of jobs in an automated fashion I now noticed that for most errors, the Fortran code runs into stop calls.
These are really bad for the C-API as they can not be caught.
Moreover it is also not possible to fork these executions into external threads.
As far as I understand the stop directive has managed to kill calling Python interpreters and more, it seems to be quite effective at stopping, well, everything.

This issue is a major roadblock for automated usage of the code using the API instead of text parsing.
Errors (bad input, wonky coordinates etc) are to be expected in bigger tool chains, and killing an entire tool chain every time it encounters errors is not really a good option.

Possible Solutions:

From what I understand, there are two main options that would resolve this problem:

1. It is possible to add some C code similar to signal.h that adds exceptions to the Fortran code.
2. Any and all functions can only return a bad status int never kill the process and the upmost calling function gets to decide how that error is handled. In the executable this function (main) would kill the process, in the API it would return empty data and a bad status.

Crest should test if input file provided exists

Is your feature request related to a problem? Please describe.
I am attempting to include crest in an automated workflow, and am calling the command from inside a script. Due to an unfortunate typo, my script changed into the wrong directory. Thus, the input file I told crest to use did not exist in the current directory. When crest ran, it segfaulted. I spent some time playing with my settings for parallelization, assuming that was the issue, before noticing my typo.

Describe the solution you'd like
I think it would be nice to check if the necessary input files exist before proceeding to the actual meat of the code. A simple "file does not exist" error message would have told me exactly where to look to fix my issue and saved me some time.

I know this is kinda silly, but I think it would be very helpful! Especially since, to my knowledge, crest doesn't have a -define flag like xtb does to help me understand what settings/files are being appropriately read. Adding a feature similar to xtb's -define flag would also be helpful.

Thanks!

JSON output shows wrong xtb version number

Describe the bug
Current xtb version is 6.3

 xtb --version
      -----------------------------------------------------------
     |                   =====================                   |
     |                           x T B                           |
     |                   =====================                   |
     |                         S. Grimme                         |
     |          Mulliken Center for Theoretical Chemistry        |
     |                    University of Bonn                     |
      -----------------------------------------------------------

   * xtb version 6.3.0 (preview) compiled by 'ehlert@majestix' on 2020-01-15

normal termination of xtb

but when using the JSON output the xtb version is only 6.1

 xtb xtbopt.xyz --gbsa water reference -I .xcontrol

        0.00000000,
        0.00000000,
        0.00000000,
        0.00000000,
        0.00000000],
   "program call": "xtb xtbopt.xyz --gbsa water reference -I .xcontrol",
   "method": "GFN2-xTB",
   "xtb version": 6.1
}

cat .xcontrol
$write
   gbsa=true
   json=true
$end

To Reproduce
Steps to reproduce the behaviour: see above

Expected behaviour
xtb --version and xtb with json output should show the same xtb version number.

Additional context
NA.

conda forge recipe

To finalize conda-forge/staged-recipes#10563, a release including #58 is required as conda-forge preferably builds from a tarball instead of git repository.

Initial guess fails for MoS2 cutout

Dear xtb developers,

I am trying to use xtb version 6.2 to optimize the geometry of a MoS2 model system and always get the error message:

#ERROR! (goedecker_solve) DSYSV failed
abnormal termination of xtb

I have tried different combinations of keywords, but error persists even for the simplest case (xtb mos2.xyz, no further options).

xtb runs fine for other systems I had already studied using previous versions, it seems specific to the system I am trying to run now.

I am pasting below the input and output files.

Regards

Andre

input file:

89

Mo     -1.90836      3.59421     -3.29351
Mo     -4.76701      5.00656     -3.18619
Mo      0.74351      5.33114     -2.93457
Mo     -2.11514      6.74348     -2.82724
Mo      3.39537      7.06806     -2.57563
Mo      0.53672      8.48040     -2.46830
Mo     -7.62566      6.41891     -3.07886
Mo    -10.48428      7.83123     -2.97154
Mo     -4.97379      8.15584     -2.71992
Mo     -7.83242      9.56815     -2.61260
Mo    -10.69107     10.98051     -2.50527
Mo     -2.32192      9.89277     -2.36098
Mo     -5.18055     11.30508     -2.25366
Mo     -8.03921     12.71744     -2.14633
Mo      6.04724      8.80498     -2.21669
Mo      3.18859     10.21733     -2.10936
Mo      5.84045     11.95425     -1.75042
Mo      0.32994     11.62969     -2.00204
Mo     -2.52869     13.04200     -1.89472
Mo     -5.38734     14.45437     -1.78739
Mo      2.98180     13.36661     -1.64310
Mo      0.12318     14.77893     -1.53577
Mo     -2.73548     16.19129     -1.42845
S      -0.82964      2.30636     -5.03115
S      -0.94345      1.84097     -1.93827
S      -3.68829      3.71871     -4.92383
S      -3.80210      3.25332     -1.83095
S      -6.54695      5.13107     -4.81650
S      -6.66076      4.66567     -1.72362
S       1.82222      4.04329     -4.67221
S       1.70842      3.57790     -1.57933
S      -1.03642      5.45564     -4.56489
S      -1.15023      4.99024     -1.47201
S      -3.89508      6.86799     -4.45756
S      -4.00889      6.40260     -1.36468
S       4.47408      5.78021     -4.31327
S       4.36028      5.31482     -1.22039
S       1.61544      7.19256     -4.20595
S       1.50163      6.72717     -1.11307
S      -1.24321      8.60492     -4.09862
S      -1.35702      8.13953     -1.00574
S      -9.40558      6.54341     -4.70918
S      -9.51939      6.07802     -1.61630
S     -12.26424      7.95577     -4.60185
S     -12.37804      7.49038     -1.50897
S      -6.75372      8.28033     -4.35024
S      -6.86753      7.81494     -1.25736
S      -9.61237      9.69269     -4.24291
S      -9.72618      9.22730     -1.15003
S     -12.47102     11.10505     -4.13558
S     -12.58483     10.63966     -1.04270
S      -4.10185     10.01726     -3.99130
S      -4.21566      9.55187     -0.89842
S      -6.96051     11.42962     -3.88397
S      -7.07431     10.96422     -0.79109
S      -9.81916     12.84197     -3.77664
S      -9.93297     12.37658     -0.68376
S       7.12595      7.51713     -3.95433
S       7.01214      7.05174     -0.86145
S       4.26730      8.92948     -3.84701
S       4.15350      8.46409     -0.75413
S       1.40865     10.34184     -3.73968
S       1.29484      9.87645     -0.64680
S       6.91916     10.66641     -3.48807
S       6.80536     10.20101     -0.39519
S       4.06052     12.07877     -3.38074
S       3.94671     11.61338     -0.28786
S       6.71241     13.81571     -3.02179
S       6.59861     13.35032      0.07109
S      -1.44999     11.75418     -3.63236
S      -1.56380     11.28879     -0.53947
S      -4.30864     13.16654     -3.52503
S      -4.42245     12.70115     -0.43215
S      -7.16729     14.57890     -3.41770
S      -7.28110     14.11351     -0.32482
S       1.20188     13.49111     -3.27341
S       1.08807     13.02572     -0.18053
S      -1.65678     14.90346     -3.16609
S      -1.77059     14.43807     -0.07321
S      -4.51543     16.31583     -3.05876
S      -4.62924     15.85043      0.03412
S       3.85374     15.22803     -2.91447
S       3.73993     14.76264      0.17841
S       0.99509     16.64039     -2.80715
S       0.88128     16.17500      0.28573
S      -1.86356     18.05275     -2.69982
S      -1.97737     17.58736      0.39306
S       1.50163      6.72717     -1.11307
S       1.50163      6.72717     -1.11307

output file:

$ xtb mos2.xyz 
      -----------------------------------------------------------      
     |                   =====================                   |     
     |                           x T B                           |     
     |                   =====================                   |     
     |                         S. Grimme                         |     
     |          Mulliken Center for Theoretical Chemistry        |     
     |                    University of Bonn                     |     
     |                  Version 6.2 (SAW190828)                  |     
      -----------------------------------------------------------      

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
   
   FOR NON-COMMERCIAL, ACADEMIA USE ONLY.
   
   Cite this work as:
   * S. Grimme, C. Bannwarth, P. Shushkov, J. Chem. Theory Comput., 2017,
     13, 1989-2009. DOI: 10.1021/acs.jctc.7b00118
   * C. Bannwarth, S. Ehlert and S. Grimme., J. Chem. Theory Comput., 2019,
     15, 1652-1671. DOI: 10.1021/acs.jctc.8b01176
   * P. Pracht, E. Caldeweyher, S. Ehlert, S. Grimme, ChemRxiv, 2019, preprint.
     DOI: 10.26434/chemrxiv.8326202.v1
   
   for DFT-D4:
   * E. Caldeweyher, C. Bannwarth and S. Grimme, J. Chem. Phys., 2017,
     147, 034112. DOI: 10.1063/1.4993215
   * E. Caldeweyher, S. Ehlert, A. Hansen, H. Neugebauer, S. Spicher,
     C. Bannwarth and S. Grimme, J. Chem. Phys., 2019, 150, 154122.
     DOI: 10.1063/1.5090222
   
   for sTDA-xTB:
   * S. Grimme and C. Bannwarth, J. Chem. Phys., 2016, 145, 054103.
     DOI: 10.1063/1.4959605
   
   in the mass-spec context:
   * V. Asgeirsson, C. Bauer and S. Grimme, Chem. Sci., 2017, 8, 4879.
     DOI: 10.1039/c7sc00601b
   
   for metadynamics refer to:
   * S. Grimme, J. Chem. Theory Comput., 2019, 155, 2847-2862
     DOI: 10.1021/acs.jctc.9b00143
   
   with help from (in alphabetical order)
   C. Bannwarth, F. Bohle, G. Brandenburg, E. Caldeweyher, M. Checinski,
   S. Dohm, S. Ehlert, S. Ehrlich, F. März, H. Neugebauer, J. Pisarek,
   P. Pracht, P. Shushkov, and S. Spicher.
   
 * started run on 2019/10/21 at 09:46:47.821     

           -------------------------------------------------
          |                Calculation Setup                |
           -------------------------------------------------

          program call               : xtb mos2.xyz
          coordinate file            : mos2.xyz
          omp threads                :                     4
          number of atoms            :                    89
          number of electrons        :                   534
          charge                     :                     0
          spin                       :                   0.0
          first test random number   :      0.75364557330491


molecular fragmentation (1/2 indicates fragments):
111111111111111111111111111111111111111111111111111111111111111111112111
11111111122221211
# atoms in fragment 1/2:    83     6
 fragment masses (1/2) :     4130.22      192.36
CMA distance (Bohr)    :  14.796
constraining FC (au)   :  0.0500

########################################################################
# WARNING! Please study the warnings concerning your input carefully
#  - XTBHOME is not set, using HOME instead
########################################################################

           ------------------------------------------------- 
          |                 G F N 2 - x T B                 |
          | Geometry, Frequencies, Noncovalent interactions |
          |            JCTC 2019 parametrisation            |
           ------------------------------------------------- 
             k(s)              :                1.8500
             k(p)              :                2.2300
             k(d)              :                2.2300
             k(f)              :                2.0000
             kEN (H0ij)        :               -2.0000
             D4 a1             :                0.5200
             D4 a2             :                5.0000
             D4 s6             :                1.0000
             D4 s8             :                2.7000
             D4 s9             :                5.0000
             alphaj            :                2.0000

  Z AO/shell   Hii/eV     exponent
 16     Tue Apr 24 11:44:34 CEST 2018   EN: 2.580 GM2: 0.340  GM3:-0.0502  RAES: 3.10
     3s    -20.029654    1.981333
     3p    -11.377694    2.025643
     3d     -0.420282    1.702555
 42     Thu Apr 26 14:26:12 CEST 2018   EN: 2.160 GM2: 0.586  GM3: 0.0920  RAES: 5.00
     4d     -7.995133    1.777658
     5s     -7.336245    1.639917
     5p     -3.686225    1.159781

#ERROR! (goedecker_solve) DSYSV failed
abnormal termination of xtb

---

Potential energy without MTD potential in MTD trajectories

In the trajectory file from a metadynamics run, the potential energy printed is the "full" metadynamics energy, including the RMSD bias potential (and possibly also reactor wall potential). For analysis of these trajectories it would be very useful to have the electronic energy term instead (i.e. without the RMSD and wall biases). I suggest adding a boolean parameter in the $md section, to switch between the current behaviour (E_pot=E_el + E_rmsd + E_wall) and E_pot=E_el.
Currently, the alternative is to re-calculate xtb energies for all trajectory frames.

PDB residue number is not correctly translated to fragments

Describe the bug

The new PDB reader expects the residues to be continuous, which is not necessarily the case.

To Reproduce

Tested with two differently sorted versions of 4qxx, first one has continuous residues, while the second has all hydrogen atoms appended. xtb version was 2609186.

xtb 4qxx_1.pdb --cycles 1 --opt --gfn 0 --namespace 1
xtb 4qxx_2.pdb --cycles 1 --opt --gfn 0 --namespace 2

Input files and output files provided here. While the first output file is fine, in the second PDB output the residue numbers do not match the input.

Expected behaviour

Correctly fragment the structure into the residues. With lesser priority: retain the numbering of the residues.

Additional context

The residue is saved here while reading:

xtb/xtb/molecule_reader.f90

Lines 725 to 728 in 2609186

	if (this_residue /= last_residue) then
	iresidue = iresidue + 1
	last_residue = this_residue
	endif

The writer is using this fragment information to determine the residue ID:

xtb/xtb/molecule_writer.f90

Line 295 in 2609186

iresidue = mol%frag%list(iatom)

Maybe one should additionally expand the pdb_data label by the residue ID:

xtb/xtb/tbdef_molecule.f90

Lines 53 to 66 in 2609186

	type :: pdb_data
	! ATOM 2461 HA3 GLY A 153 -10.977 -7.661 2.011 1.00 0.00 H
	! TER 2462 GLY A 153
	! a6----i5---xa4--aa3-xai4--axxxf8.3----f8.3----f8.3----f6.2--f6.2--xxxxxxa4--a2a2
	! HETATM 2463 CHA HEM A 154 9.596 -13.100 10.368 1.00 0.00 C
	logical :: het = .false.
	integer :: charge = 0
	character(len=4) :: name = ' '
	character(len=1) :: loc = ' '
	character(len=3) :: residue = ' '
	character(len=1) :: chains = ' '
	character(len=1) :: code = ' '
	character(len=4) :: segid = ' '
	end type pdb_data

Thanks to @saschmi for reporting, thanks to @liljay42 for looking into this.

Thermostatistical corrections for T=0

Describe the bug
In case you try to calculate thermostatistical corrections at T=0K interesting things happen.

To Reproduce
Tested with version 6.2.1 (36dbe8b). xtb will complain for good reasons

printf "\$thermo\ntemp=0.0\n\$end\n" > input
xtb -I input <geometry> --define
... skip ...
# WARNING! Your input has following faults:
#  - A temperature of 0.0 K sounds strange to me

Ignoring the warning and still running the program with this input will produce meaningless and wrong values.

$ printf "\$thermo\ntemp=0.0\n\$end\n" > input
$ xtb -I input <geometry> --ohess
... skip ...
       T/K    H(0)-H(T)+PV         H(T)/Eh          T*S/Eh         G(T)/Eh
   ------------------------------------------------------------------------
   ------------------------------------------------------------------------

         :::::::::::::::::::::::::::::::::::::::::::::::::::::
         ::                  THERMODYNAMIC                  ::
         :::::::::::::::::::::::::::::::::::::::::::::::::::::
         :: total free energy         -42.153937359591 Eh   ::
         ::.................................................::
         :: total energy              -42.153937359591 Eh   ::
         :: zero point energy           0.182091755134 Eh   ::
         :: G(RRHO) w/o ZPVE           -0.182091755134 Eh   ::
         :: G(RRHO) contrib.            0.000000000000 Eh   ::
         :::::::::::::::::::::::::::::::::::::::::::::::::::::
... skip ...

Notice that no thermodynamic function have been evaluated, since there is no printout regarding the partition function or temperature, so the whole output is obviously useless and wrong here.

Using a very small number instead will give meaningful results (the one the user expected for T=0K):

$ printf "\$thermo\ntemp=1.0e-10\n\$end\n" > input
$ xtb -I input <geometry> --ohess
... skip ...
       T/K    H(0)-H(T)+PV         H(T)/Eh          T*S/Eh         G(T)/Eh
   ------------------------------------------------------------------------
      0.00    0.126676E-14    0.182087E+00   -0.289393E-13    0.182087E+00
   ------------------------------------------------------------------------

         :::::::::::::::::::::::::::::::::::::::::::::::::::::
         ::                  THERMODYNAMIC                  ::
         :::::::::::::::::::::::::::::::::::::::::::::::::::::
         :: total free energy         -41.971849822766 Eh   ::
         ::.................................................::
         :: total energy              -42.153937303642 Eh   ::
         :: zero point energy           0.182087480876 Eh   ::
         :: G(RRHO) w/o ZPVE            0.000000000000 Eh   ::
         :: G(RRHO) contrib.            0.182087480876 Eh   ::
         :::::::::::::::::::::::::::::::::::::::::::::::::::::
... skip ...

Run with a coffeine molecule, but this is not the point here.

Expected behaviour
Maybe kill the calculation after a full hessian run, maybe skip the thermo part, maybe a special case for T=0K, maybe fix the user input by adding some noise.

Additional context
Thanks to @fabothch for reporting and discussion.

missing man file and gbsa_parameter

Hello,
when I used meson: meson setup build_intel --optimization=2, Some errors came.

meson.build:345:0: ERROR: File man/man1/xtb.1 does not exist.

and I couldn't find gbsa_parameters

gbsa_parameter_files = ['.param_gbsa_acetone',
                        '.param_gbsa_acetonitrile',
                        '.param_gbsa_benzene',
                        '.param_gbsa_ch2cl2',
                        '.param_gbsa_chcl3',
                        '.param_gbsa_cs2',
                        '.param_gbsa_dmso',
                        '.param_gbsa_ether',
                        '.param_gbsa_h2o',
                        '.param_gbsa_methanol',
                        '.param_gbsa_thf',
                        '.param_gbsa_toluene']

Forces per particle

Thanks for open-sourcing this project. Is it possible to get the components of the forces on each particle as additional columns on the xyz(log) files? and/or potential energy per particle? I have browsed the docs, but I didn't see the option.

Add the number of point charge as the first line of the pcgrad

Is your feature request related to a problem? Please describe.
When using the QM/MM Orca interface of amber, it is required that the first line of the pcgrad should indicate the number of point charge in the system, which is not present in the pcgrad file.

Describe the solution you'd like
Normal Orca pcgrad used in amber has the format

996
0.002110738107 -0.000907351801 0.001687018358
-0.001089983662 0.000596535645 -0.000837938612
-0.001269634418 0.000426933814 -0.000967084019
-0.000165255832 0.000111137830 0.001623392385

Whereas xtb gives the format

0.00219465 -0.00095322 0.00174035
-0.00114767 0.00062388 -0.00085454
-0.00131498 0.00044651 -0.00096461
-0.00021916 0.00009229 0.00159509

Describe alternatives you've considered
I wonder if it is possible to alter the output format or at least have such an option during the compilation.

The way amber read the pc gradient is followed.

      ! MM gradients (none if do_grad)
      if ( nclatoms > 0 ) then
        open(iunit, file=basename//'.pcgrad', iostat=ios)
        if ( ios /= 0 ) then
          call sander_bomb('read_results (qm2_extern_orc_module)', &
            'Error opening Orca output file '//basename//'.pcgrad for reading', &
            'Will quit now')
        end if
        do
          read (iunit, '(a)', iostat = ios) read_buffer !First line is nclatoms
          ! End of file; data not found
          if (ios < 0) then
            call sander_bomb('read_results (qm2_extern_orc_module)', &
              'Error reading Orca output from file '//basename//'.pcgrad', &
              '(Empty file)')
          end if
          ! Read MM gradient data
          do i = 1, nclatoms
            read (iunit, '(3(f17.12))') dxyzcl(:,i)
          end do
          exit
        end do
        close(iunit)
      end if

If possible state how you can assist in providing data or code to to implement the feature
I can test if the xtb is working with amber as desired.

center of mass, segmentation fault

Describe the bug

When using xtb molecule.xyz --cma [with and without --opt] to center the molecule at the center of mass, a segfault occurs in axis_trafo.f90

This happens with the newest release version: * xtb version 6.2.1 (bf8695d)

To Reproduce
Steps to reproduce the behaviour:

1. happens with caffeine or water (tested)
2. xtb caffeine.xyz --cma --verbose
3. output showing the error:

forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source             
xtb                0000000001A54AC4  Unknown               Unknown  Unknown
xtb                0000000001A32950  Unknown               Unknown  Unknown
xtb                00000000008102B0  axis_trafo_mp_axi         332  axis_trafo.f90
xtb                000000000040A680  MAIN__.V                  285  program_main.f90
xtb                0000000001AD2542  Unknown               Unknown  Unknown
xtb                0000000002EE94D0  Unknown               Unknown  Unknown
xtb                0000000000401F47  Unknown               Unknown  Unknown

Expected behaviour
Move the molecule to the center of mass, no segfault.

Additional context
Cheers and Thanks!

Spin in Python API

Currently, there is no way to specify the spin (--uhf flag) using the Python API. Are there any plans to add this feature? I can look through the source code now that it's publicly available and see if I can get it to work if not.

Install the manual as well

Is your feature request related to a problem? Please describe.
xcontrol and other manual entries are not installed.

Describe the solution you'd like
Either they should be (through meson), or this should go in the documentation, no?

Describe alternatives you've considered
Nothing.

If possible state how you can assist in providing data or code to to implement the feature
That depends on the solution (there may be way to include manual page in Sphinx, though)

Additional context
None.

Is there any plans to release xtb on pypi?

Hi, I'm wondering whether you plan to release xtb on pypi. It would be convenient for a quick start with pip release.

Segmentation fault after exceeding certain number of atoms

Sorry in advance if this turns out to be something stupid like insufficient memory on my system (doesn't look like it to me, but who knows).

Describe the bug

If the number of atoms in the system to be calculated is greater than a certain element-specific number (e.g. 255 for H atoms), the code segfaults.

To Reproduce

Minimal reproducible example using the Python interface:

import ase
import numpy as np
from xtb import GFN0 as XTB

N = 256 # 255 works fine

a = ase.Atoms(["H"]*N)
a.positions[:] = np.random.random((N,3))*500
c = XTB()
a.set_calculator(c)
a.get_potential_energy()

Expected behaviour
This looks to me like it's caused by some hardcoded limit(s) in the code - it would be great if there was information on this in the docs, so that people can recompile the code with increased limits.

Additional context
Tested on the 6.3.0 pre-release.

GFN0-xTB calculations cannot be performed by detailed input only.

Describe the bug
GFN0-xTB calculations cannot be performed without using the command line.

To Reproduce
Tested with version version 6.2.1 (7ff4d96)

xtb --gfn 0 <input>

will perform a GFN0-xTB calculation.

printf "\$gfn\nmethod=0\n\$end\n" > gfn0.inp
xtb -I gfn0.inp <input>

will start the SCC module and fail.

Expected behaviour
Detailed input should be equivalent to the command line input.

Additional context
The setting of the method key from the detailed input is handled here:

xtb/xtb/set_module.f90

Lines 1260 to 1273 in 7ff4d96

	case('version','method')
	if (key.eq.'version') &
	call raise('S',"Don't use the 'version' key, since it is confusing",1)
	if (get_value(val,idum).and.set1) then
	if ((idum.ge.0).and.(idum.le.2)) then ! actually, this looks stupid...
	gfn_method = idum
	elseif (idum.eq.3) then
	gfn_method = 2
	call raise('S','Please, request GFN2-xTB with method=2!',1)
	else
	call raise('S','We have not yet made a GFN'//val//'-xTB method',1)
	endif
	endif
	set1 = .false.

While the correct check for GFN0-xTB is only performed in the command line parser:

xtb/xtb/argparser.f90

Lines 502 to 503 in 7ff4d96

	! make sure that we get a eht calculation instead of a scc for GFN0
	if(gfn_method.eq.0) call set_exttyp('eht')

GFN1-xTB ASE calculator does not currently support PBCs

Describe the bug
You may already be aware of this since I know the PBC integration is a work in progress, but if not:
GFN1-xTB does not currently work with the ASE interface when PBCs are present. A segmentation fault occurs ("364302 Segmentation fault"). GFN1-xTB works correctly when called from the detailed input interface. This is for xtb version 6.3.0 (preview).

To Reproduce

from xtb import GFN1
from ase.io import read

mol = read('test.cif')
calc = GFN1()
mol.set_calculator(calc)
mol.get_potential_energy()

Expected behaviour
Calculation of potential energy

Additional context
test.cif

Compile failure in new-updates.

Dear all,

I can't compile the newest updated xtb. Config with meson and gives

(base) [xchen@localhost xtb]$ meson setup build_intel --optimization=2
The Meson build system
Version: 0.51.2
Source dir: /home/xchen/Software/xtb-source/xtb
Build dir: /home/xchen/Software/xtb-source/xtb/build_intel
Build type: native build
DEPRECATION: Duplicated values in array option is deprecated. This will become a hard error in the future.
DEPRECATION: Duplicated values in array option is deprecated. This will become a hard error in the future.
DEPRECATION: Duplicated values in array option is deprecated. This will become a hard error in the future.
Project name: xtb
Project version: 6.2.1
Fortran compiler for the host machine: ifort (intel 19.0.5.281 "ifort (IFORT) 19.0.5.281 20190815")
C compiler for the host machine: icc (intel 19.0.5.281 "icc (ICC) 19.0.5.281 20190815")
C++ compiler for the host machine: icpc (intel 19.0.5.281 "icpc (ICC) 19.0.5.281 20190815")
DEPRECATION: Duplicated values in array option is deprecated. This will become a hard error in the future.
Build machine cpu family: x86_64
Build machine cpu: x86_64
Program git found: YES (/usr/bin/git)
Program date found: YES (/usr/bin/date)
Program whoami found: YES (/usr/bin/whoami)
Program hostname found: YES (/usr/bin/hostname)
Configuring xtb_version.fh using configuration
Library pthread found: YES
Library m found: YES
Library dl found: YES
Library mkl_intel_lp64 found: YES
Library mkl_intel_thread found: YES
Library mkl_core found: YES
Library iomp5 found: YES
Library mkl_rt found: YES
Run-time dependency threads found: YES 
Program a2x found: YES (/usr/bin/a2x)
Build targets in project: 5
Found ninja-1.9.0 at /home/xchen/anaconda3/bin/ninja

Ninja install the program. ninja -C build_intel test,gives,

....

../xtb/model_hessian.f90(1632): remark #15009: model_hessian_mp_strtch2_ has been targeted for automatic cpu dispatch
../xtb/model_hessian.f90(571): remark #15009: model_hessian_mp_mh_swart_outofp_ has been targeted for automatic cpu dispatch
../xtb/model_hessian.f90(1482): remark #15009: model_hessian_mp_outofp2_ has been targeted for automatic cpu dispatch
../xtb/model_hessian.f90(1773): remark #15009: model_hessian_mp_mh_eeq_ has been targeted for automatic cpu dispatch
../xtb/model_hessian.f90(716): remark #15009: model_hessian_mp_mh_lindh_d2_ has been targeted for automatic cpu dispatch
../xtb/model_hessian.f90(852): remark #15009: model_hessian_mp_mh_lindh_stretch_ has been targeted for automatic cpu dispatch
../xtb/model_hessian.f90(955): remark #15009: model_hessian_mp_mh_lindh_bend_ has been targeted for automatic cpu dispatch
../xtb/model_hessian.f90(1168): remark #15009: model_hessian_mp_mh_lindh_torsion_ has been targeted for automatic cpu dispatch
../xtb/model_hessian.f90(1752): remark #15009: model_hessian_mp_fk_lindh_ has been targeted for automatic cpu dispatch
../xtb/model_hessian.f90(1302): remark #15009: model_hessian_mp_mh_lindh_outofp_ has been targeted for automatic cpu dispatch
../xtb/model_hessian.f90(797): remark #15009: model_hessian_mp_mh_lindh_ has been targeted for automatic cpu dispatch
../xtb/model_hessian.f90(2085): remark #15009: ddvopt_ has been targeted for automatic cpu dispatch
[151/260] Compiling Fortran object 'xtb@sta/xtb_copyc6.f.o'.
../xtb/copyc6.f(22): remark #15009: copyc6_ has been targeted for automatic cpu dispatch
ninja: build stopped: subcommand failed.

I have no idea about what's going wroing.

The most confusing thing is that I can compile the old version which in the release page.

xtb.py missing?

Was xtb.py removed from github?

CREST argument parsing -- xyz with '-H' in the name

Describe the bug
If there is a '-H' in the name of the xyz file, (example-H2O.xyz), crest displays the help as one had called crest -H

Expected behaviour
Parsing input geometry as independet unicode/ASCII string

Present in CREST version 2.7.1, pre-compiled executables ran on Ubuntu 18.04 LTS.

Compiling xtb on OSX

updated and edited
Compiling on OSX might interest a few people.

A few hurdles I ran into:

• needs a fully 'shared' build option as static linking is not really a thing on OSX
• requires at least: meson configure -Db_lundef=false (possibly also for gcc)

---

current working version on Catalina and Intel19
grab: https://github.com/hokru/xtb/tree/osx3 (shortened meson config plus PR #40)

export FC=ifort CC=icc CXX=icpc
meson setup build_intel -Dstatic=false -Db_lundef=false -Db_asneeded=false

There will be an error because of wrong linking flags! Ignore and link yourself:

ifort  -o xtb 'xtb@exe/xtb_program_main.f90.o' -qopenmp -mkl libxtb.a  -Wl,-rpath,/INSERT_YOUR_PATH/xtb/build_intel/ libxtb.dylib

Clarify xtb license

From the looks of it, xtb appears to be licensed under LGPLv3+.
However, this is not reflected in the output of the program.

The problem is the dumped header

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
   
   FOR NON-COMMERCIAL, ACADEMIA USE ONLY.

which prevents the program from being packaged into *nix distributions; the output arises from

xtb/xtb/header.f90

Line 51 in ad49de1

"FOR NON-COMMERCIAL, ACADEMIA USE ONLY.",&

Would you mind removing the restrictions to non-commercial academic use in the sources and any possible example/reference log files?

SDF and MOL file reader import errors in xtb Version 6.2 RC2

Intro
I highly appreciate the MOL and SDF file reader and import, because it narrows the gap between cheminformatics with millions of molecules from PubChem and ChemSpider and the quantum chemistry world. So instead of going via information devoid xyz or coord files, the SDF and mol files can be enriched directly with meta information (energies, fukui indices, EA, HOMO-LUMO gaps etc). While we have tools to convert files (OpenBabel, ChemAxon molconvert) the direct calculation on MOL and SDF files is a really important feature, because it will allow for easier workflows and finally also broader use within the community. I am writing this somewhat lengthy intro because it is easy to just get rid of problematic features by excluding them, but that is not my intention.

Describe the bug
The mol/sdf file reader is reading only very specifically formatted molecules, but throws errors on correctly formatted standard MOL (MDL V2000) formatted files. This applies to simple molecules, not exotic SDF options. When it does that it actually leads to many different errors, from falsely breaking bonds to throwing errors regarding atom numbers and optimization failures. I am also adding additional recommendations, or if needed can file them as individual issues?

To Reproduce
Steps to reproduce the behavior:

XTB version: Version 6.2 RC2 (SAW190805)
I checked and converted most molecules with OpenBabel and ChemAxon mview and molconvert. These tools have been used to convert millions/billions of connection tables. They are pretty robust. Case 2-6 shows the errors.

Case 1 (Expected computational behavior):
Warning, this is a faulty SDF/mol molecule recreated from the xtb documentation, it can not be imported by OpenBabel or by MarvinView. There are not enough spaces after the atom coordinates (x y z O), therefore the molecules is corrupt. The xtb file reader probably just reads coordinates.

xtb h2o.sdf --opt  
TOTAL ENERGY               -5.070544442942 Eh   
GRADIENT NORM               0.000055195691 Eh/α 
HOMO-LUMO GAP              14.391940156700 eV   
normal termination of xtb

Case 2 (C6H6-m213-2D.sdf) benzene standard and error free 2D formatted mod/sdf file:

xtb C6H6-m213-2D.sdf --opt
#ERROR! (goedecker_solve) DSYSV failed
abnormal termination of xtb

Case 3 (C6H6-m213-aroma.sdf) (benzene aromatized bonds):

xtb C6H6-m213-aroma.sdf --opt
#ERROR! (goedecker_solve) DSYSV failed
abnormal termination of xtb

Case 4 (water-chemaxon.sdf) (correctly formatted SDF) atom number mismatch:

xtb water-chemaxon.sdf --opt
#ERROR! Atom number missmatch in Xmol file
abnormal termination of xtb

Case 5 (xtb water-openbabel-2D.sdf) (correctly formatted 2D SDF):

 --opt xtb water-openbabel-2D.sdf --opt
#ERROR! (goedecker_solve) DSYSV failed
abnormal termination of xtb

Case 6 (xtb water-openbabel-3D.sdf) (correctly formatted 3D SDF):
This case is interesting, because a different energy is presented, even with --opt extreme options. When compared to the working h2o.sdf example from the handbook, the energy is different and somewhat interesting the optimization failed, even when repeated.

xtb water-openbabel-3D.sdf --opt extreme

optimized geometry written to: xtbopt.sdf
           -------------------------------------------------
          | TOTAL ENERGY               63.813219402131 Eh   |
          | GRADIENT NORM            1205.618864654011 Eh/α |
          | HOMO-LUMO GAP              16.735238594075 eV   |
           -------------------------------------------------

########################################################################
# WARNING! Some non-fatal runtime exceptions were caught, please check:
#  - GEOMETRY OPTIMIZATION FAILED!
########################################################################

Please provide all input and output file such that we confirm your report.
See attached. XTB-sdf-issues.zip contains the examples shown here.

Additional recommendations

• (R1) Input check, add 2D or 3D format requirement (will xtb be able to handle flat 2D mol files?)
• (R2) Input check, add information if Kekule or aromatized bonds are required, if this information is ignored check for bond lengths. Aromatized bonds are "4" in MDL format, this is a common error in many SDF/mol software tools
• (R3) Input check, add information if explicit hydrogens are required in the mol/sdf file (xtb does not care about molecules to be chemically valid, they currently can have hydrogens attached or not, xtb will perform an optimization either way) give potential warning if hydrogens are missing.
• (R4) Input check, add warning if multiple molecules are contained in an SDF file. The molecules are detected by "$$$$". By definition SDF files allow for multiple molecules, while MOL files do not. Currently xtb only reads the first molecule and ignores all other molecules. Potentially it would be nice if xtb could stream and process a single SDF file with thousands/millions of molecules.
• (R5) Input check, check for charge, radicals, multiplicity many SDF/MOL input files can have different representations for charges (nitro groups etc).
• (R6) Add warning if final optimized connection table changed (check via InchiKey or bond length). That happens quite often and is an extended feature. It has implications on database duplicates.

Additional context

• original MDL V2000 format definitions (CTF file formats)
  http://c4.cabrillo.edu/404/ctfile.pdf

• ChemAxon structure checker, a software that detects errors in SDF/MOL files
  https://docs.chemaxon.com/display/docs/Checker+List

• OpenBabel Doc
  https://buildmedia.readthedocs.org/media/pdf/open-babel/latest/open-babel.pdf

• OpenBabel installation
  http://openbabel.org/wiki/Category:Installation

• ChemAxon molconvert
  https://chemaxon.com/marvin-archive/latest/help/applications/molconvert.html

• SDF error checker
  http://www.nonlinear.com/progenesis/sdf-studio/v0.9/faq/sdf-file-format-guidance.aspx

• command line parameters to convert or split a single multi-molecule SDF to multiple mol/sdf/tmol

# sdf extension (molconvert)
molconvert sdf C6H6-3D-quickH-opt-ok.sdf -m -o C6H6-m.sdf

# mol extension (molconvert)
molconvert mol C6H6-3D-quickH-opt-ok.sdf -m -o C6H6-m.mol

# tmol extension (openbabel)
obabel C6H6-3D-quickH-opt-ok.sdf -otmol -O C6H6-m.tmol -m