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.