User-defined potentials

[aslozada]

Hi Sebastian, @awvwgk,
Again, this project, tblite, is very nice.

I read some of the features of tblite at https://tblite.readthedocs.io and I have a proposal.

Between 2015 and 2017, I wrote a program for stochastic simulation (MELQUIADES), mainly aimed at users --with no intention of writing source code-- interested in implementing (using) diverse interaction potentials. Thus, a feature in this program is:  the user can write some form of potential, as written on paper, the program performs a syntactic analysis (parsing) of this formula and finally a new object code can be obtained.

I think that in the case of tblite a similar feature could be implemented in the definition of electrostatic interactions or London dispersion interactions. For example, the coulombic interactions in some simulations it may be necessary to apply some damping condition (coulomb -> yukawa) or increase multipolar contributions, etc.

[awvwgk]

I like the idea. Currently the Hamiltonian is build from three different kind of containers, beside the integrals:

• density independent energy contribution
• density dependent energy contribution
• density dependent energy contribution with a density independent contribution (combination of the above)

The separation is of course arbitrary as we would just use the third container type for everything.

A density independent energy contribution must provide:

• an interface to evaluate its energy, gradient and strain derivative for a given geometry

A density dependent energy contribution must provide:

• an interface to calculate its potential from a density and geometry
• an interface to calculate its energy from a density and geometry
• an interface to evaluate its gradient and strain derivative from a (converged) density and geometry

The combined container provides both sets of interfaces. Of course a container can have an arbitrary complex initialization process outside of the actual calculation.

Another aspect is that the container is not allowed it modify it self, e.g. it cannot cache information in its instance, but has to carry a separate cache object for this purpose. This makes all containers thread-safe and multiple threads can use the same instance without side effects, while maintaining the cache objects in thread-local storage.

My idea was to allow user defined containers provided via Fortran and C, which work via a callback mechanism and a way to build an arbitrary calculator from those containers. Populating the container in C via Python should be possible. This is a huge project and will take some time to complete. Having a concrete application would make it more feasible to consider it in near future

What currently has to be done:

• generalize the calculator to hold more abstract containers
• allow a more generic cache and provide a mechanism for containers to taint it
• expose a mechanism to query to density from C (preferably by reference rather than copies)
• expose a mechanism to add to the potential from C (preferably by reference rather than copies)

This would allow to modify all parts of the method except for the Hamiltonian and the integrals. Since the Hamiltonian evaluation can be performance critical this requires some special consideration. Using a too opaque abstraction will result significant performance penalties.

[awvwgk]

I think that in the case of tblite a similar feature could be implemented in the definition of electrostatic interactions or London dispersion interactions. For example, the coulombic interactions in some simulations it may be necessary to apply some damping condition (coulomb -> yukawa) or increase multipolar contributions, etc.

An alternative approach, which is easier accessible than a programmatical way of constructing and modifying methods is creating the required flexibility in the parameter file. Currently you can export a parameter file with

tblite param --method gfn2 --output gfn2-xtb.toml

Basically all components defining the Hamiltonian can be modified, removed or added in this file. In anticipation of future extensions all component tables use a subtable (multipole.damped) in case we come up with a different potential shape it can be easily specified in the parameter file as well.

This provides a more human-friendly way to work with the parametrization data, even if it would be somewhat less flexible than being able to define your own energy expression, because they would have to be coded up in tblite first to actually become usable.