xTB and C Interface

[conradhuebler]

Dear xTB dev-team,

I hope this is the approriate way for giving feedback and adressing some issues regarding the usage of xTB and tblite in a C++ project.

But first, thanks for the work put into the methods and implemention!

I am using xTB in an program (https://github.com/conradhuebler/curcuma) to calculate energies and gradients (geometry optimsation utilising another library (LBFGS optimisation)).

Using GCC ( and icc), it seems that there is a difference between build modes Release and RelWithDebInfo. Using Release the xTB calculation seem to fail, using RelWithDebInfo they work. As I am not familiar with fortran, I am unable to dig deeper, but RelWithDebInfo is fine. It seems not to happend with the xtb program.

While most xTB methods became thread-safe, it is not working well. I am using C++ threads, adopted as ThreadPool (https://github.com/conradhuebler/CxxThreadPool) and with anything else I have parallelised it works, but not with the xTB interface. However, it used to work some time ago. One specific problem is, that the parameter file (e.g. param_gfn2-xtb.txt) could not be found in a parallel run, thought the file is there. Will tblite be a better solution?

GFN-FF is unfortranatly not thread-safe from concept due to the topo file. Are there plans to change it? In serial, it works well, after adopting the source to 1) respect the printout level in the gfnff_ini.f90 and 2) uncommenting the printout in gfnff_ini2.f90 (5247381).

After errors in the xTB calculation occur, the xTB interface and program becomes unstable. I have seen some error handling in tblite; will that give control program to the caller programm?

From the headers and C-api documentation, I did not get an information on how to suppress the printout during the tblite calculation. I suppose there was just not time to finished the documentation ;-)

In the next days, I will prepare some explicit examples for some of issues addressed ...

So long, cheers and thanks for making xTB,
Conrad

[awvwgk]

Thanks for the feedback, much appreciated.

Will tblite be a better solution?

I hope it will, please feel free complain about things that are missing or not working in tblite.

GFN-FF is unfortranatly not thread-safe from concept due to the topo file. Are there plans to change it?

Personally, I'm not interested in working on this. Maybe other developers want to take on this issue and improve on the stability and thread-safety of GFN-FF.

I have seen some error handling in tblite; will that give control program to the caller programm?

I tried to learn from the disadvantages of the xtb error handling. I hope this one works better, but feedback is always welcome.

From the headers and C-api documentation, I did not get an information on how to suppress the printout during the tblite calculation

Seems like I forgot to implement the verbosity setter (see tblite/tblite#53). The main reason is probably that with the callback based logger it is easy to suppress the output by registering a callback without any logging.

[conradhuebler]

Ok, I found that callback function (ignoring the recent commit on verbosity level) and implemented tblite as backend for most of the GFN calculations.

Works nicely, great :-) - Ok, I have not checked the specfic results, but it works serial and parallel, without obvious errors ( so far). Lets see what happens now.

Thanks and cheers,
Conrad

[awvwgk]

I also opened an issue to discuss the design of C++ bindings in tblite/tblite#57.