The issue of extending the KIM API to support long-range electrostatic interactions and charge equilibration was discussed with a group of experts at a working dinner at the SES Annual Technical Meeting at Purdue University on Wednesday 01-Oct-2014. Additional discussions with the KIM development team and Axel Kohlmeyer were held on 15 and 16-Oct-2014. Based on these discussions, the following plan has been devised. We would welcome your input on this plan. We also have specific questions marked below by "QUESTION" for your attention.

PLAN FOR EXTENDING THE KIM API TO SUPPORT LONG-RANGE ELECTROSTATICS AND CHARGE EQUILIBRATION

1. The need for electrostatics and/or charge equilibration is considered part of the Model definition.

While it is true that the electrostatics physics is independent of a particular model, it is the case that some models choose to include this physics and others do not. For this reason it is considered part of the Model. A Model must specify whether it requires such calculations to be performed in its ".kim" descriptor file.

2. Electrostatics

* Simulators/Models must specify what type(s) of electrostatics support they

provide/require by specifying an ordered list of supported methods. There

will initially be four methods: `None', `ShortRange', `LongRange',

`QEqShortRange'. (In the future additional types, such as

split charge (SQEq); etc., may be added.)

For example, a Simulator that can support all methods, but prefers

long-range, might list:

ElectroStaticsMethod1 := LongRange

ElectroStaticsMethod2 := ShortRange

ElectroStaticsMethod3 := QEqShortRange

ElectroStaticsMethod4 := None

A Model that requires QEq will list:

ElectroStaticsMethod1 := QEqShortRange

A Model that only works with one method would list:

ElectroStaticsMethod1 := QEqShortRange

The KIM API matching process will start at the top of the Model's

ElectroStaticsMethods list and search through (from top to bottom) the

Simulator's list until a match is found. If no match is found the Model

and Simulator are incompatible. The KIM API will provide a function that

allows the Model/Simulator to obtain the value of the matched method.

* If a Simulator/Model lists anything other than `None', it must also

include a "charges" argument in the Model Input section of its ".kim" file.

* If `ShortRange' is successfully matched, then the Simulator must provide

values in the charges array and the Model must use these values to compute

electrostatic contributions (to the energy, forces, etc.) using a short

range approximation of the Coulomb effect. The Model must include these

contributions in its values for energy, force, etc. Thus, the Model will

implement the total configuration energy function as:

E = sum_i [ E_i^pot(r^{ij}, charges[j]) + E_i^c(r^{ij}, charges[j]) ],

where E_i^pot is the (possibly charge dependent) "standard" short-range

potential and E_i^c is the short-range approximation to the Coulomb

interaction energy. The other Model output arguments (forces, virial, etc.)

are derived as expressions in terms of the derivatives of E.

[ QUESTION: Do we need a `electrostaticsCutoff' setting to allow for

separate cutoff values for E_i^pot and E_i^c? If so, does the Model

define this? Maybe we can just use the "multiple cutoff" support, that is

planned for the KIM API, instead of support for a special electrostatics

cutoff? ]

* If `LongRange' is successfully matched, then the Simulator must provide

values in the charges array and the Model must use these values only to

compute its "standard" short-range potential. Thus, the model will

implement its configuration energy function as:

E = sum_i [ E_i^pot(r^{ij}, charges[j]) ].

The other Model output arguments (forces, virial, etc.) are derived as

expressions in terms of the derivatives of this E function. In order to

obtain the total configuration energy, the Simulator must perform the

long-range electrostatics computation and add the appropriate terms to

each Model output obtained from the KIM Model. Thus, the total

configuration energy is:

E_tot = E + E^c(coordinates[i], charges[i]),

where E is the energy obtained from the Model and E^c is the long-range

Coulomb energy contributed by the Simulator.

* If one of the QEq methods is successfully matched, then the Simulator and

Model must, in addition to listing "charges" in the Model Input section,

also list "electronegativities" and optionally "electrostaticsHessian"

arguments in the Model Output section of their ".kim" files. (These are

the first and second derivatives of the energy with respect to charge.)

[ QUESTION: what about x^i q^j coupling terms, i.e. position-charge

coupling: d2E/(dx^i dq^j)? If relevant, how do we implement this data

structure? Memory management becomes challenging in this case if we want

to avoid high memory usage data structures. ]

The Simulator will be responsible for providing initial `charges' values

and evolving the charges (using the electronegativities and

electrostaticsHessian values) in a manner consistent with charge

equilibration requirements.

- If `QEqShortRange' is successfully matched, then the Model must use the

charges values to compute the energy using a short-range approximation of

the Coulomb energy. Thus, the Model will implement the total

configuration energy function as:

E = sum_i [ E_i^pot(r^{ij}, charges[i]) + E_i^c(r^{ij}, charges[j]) ],

where E_i^pot is the (possibly charge-dependent) "standard" short-range

potential and E_i^c is the short-range approximation to the Coulomb

energy. The Model will compute, upon request, the first

(electronegativities) and second (electrostaticsHessian) derivatives

with respect to the charges of this energy function.

[ QUESTION: We understand that for computational reasons, when charge

equilibration is performed a short range approximation to the

electrostatic energy is used. However, some models may choose to use the

equilibrated charges to a long-range electrostatic calculation for the

energy and forces. This means there are two energy functions. One is

used only for charge equilibration to obtain charges. The second is the

one used for evolving the atomic positions. Does this happen in

practice? Should we design the standard to support or this or is having

a single energy function as we propose above sufficient? Keep in mind

that adopting the two-energy approach would increase the complexity of

the KIM API and hence the burden on model developers. ]

* If "None" is successfully matched, then neither the Simulator nor the Model

will make use of any `charges', `electronegativities', or

'electrostaticsHessian' arguments defined in their respective ".kim" files.

We look forward to your input!

Ryan & Ellad

kim-api-electrostatics-and-qeq-v06.txt (7.14 KB)