C/C++ Interface Oddities about xtb

[nabbelbabbel]

I can make a PR for the CMake files once I have cleaned them up.

There could be a few minor changes required to the overall build process to keep things nice an tidy though.
(Only one list of the sources, the way xtb_version.fh is generated, etc.)

[awvwgk]

Thanks for the report.

I guess the bond order problem is kind of known (at least I knew that I have to fix it at some point).

A lock would certainly help to prevent several xtb calls to run and use the same global variables, but I would rather prefer to purge all global variables from the code base than managing a mutex. So this is a long term goal.

Regarding the CMake build, would you consider sharing the build files? I've never used CMake myself for a project, but there is some interest in building xtb with something else than meson.

[awvwgk]

My last try to remove global variables was #38, but it failed eventually.

The concept of the API currently ensures that the global storage is setup correctly every time, this causes problems when to instances try to call the API at the same time. This also makes the API slower.

A solution would be to separate these steps and require to initialize and finalize xtb before using the API, which would be okay, I guess. The initialization state (uninitialized, GFN-FF, GFN0-xTB, GFN1-xTB or GFN2-xTB) could be saved to prevent using it with the wrong method.

[nabbelbabbel]

The initialization state (uninitialized, GFN-FF, GFN0-xTB, GFN1-xTB or GFN2-xTB) could be saved to prevent using it with the wrong method.

So ten threads would then hold a state of their own each? That would work.

Given that I have not looked into the code that much, I'd ask what there actually is that is initialized and can be kept across calculations with different molecules.

I assume thats this is many of the parameters and precalculated stuff from the parameters?
Coming more from a C++ side, not having dealt with Fortran in a while, I wonder if Fortran has something along the lines of constexpr (C++) ? This would mean that this particular chunk of data would be resolved at compile time, meaning this data is never reinitialized. (This means the data is then folded into the binary and that binary is then bigger, loads a bit slower and compiles a bit slower.)

[awvwgk]

I would prefer ten threads with independent states, but no. For the near future it will be something like the library having one global state, deciding which method is used, but all the threads can perform the calculation with the given method independently.

Generally Fortran is pretty good at evaluating even complex expressions at compile time, so this is not a problem at all. The real problem is the way the parametrisation is handled, this code needs some serious refactoring to make it possible to use compile time evaluation in the first place. Also I'm somewhat afraid of touching this part of the code, because it will cost me a lot of time and hardly anybody will notice it except for new bugs introduced.