Supporting multiple types of boundary conditions for long-range electrostatics in OpenKIM Simulator Models

Hi everyone,

I would like your input on a decision we have to make at OpenKIM.

This is a follow up on a discussion @akohlmey, @tadmor and I had a few weeks ago. OpenKIM will be adding many more LAMMPS Simulator Models (SM) with long-range electrostatics soon. If you are unaware, a KIM SM is essentially an encapsulation of a set of LAMMPS commands and parameter files. See, for example the model-init and model-defn keys in the following SM specification (which does indeed include long-range electrostatics):

Some of the commands are internal KIM commands, so they may be unclear, but hopefully you get the idea.

KIM SMs should be as straightforward as possible for the user to deploy and work under as many conditions as possible, which is where the difficulty comes in – as demonstrated in the example, different periodicity settings require different settings for pair_style, kspace_style, and possibly kspace_modify.

We use conditionals to cover as many cases as possible, even though obviously we cannot cover all possibilities. To aid in these conditionals, the KIM LAMMPS package defines some LAMMPS variables in order to expose information about the state of the simulation to the LAMMPS commands in the SM (for example, kim_periodic). We can put new variables like this into the KIM package if required.

Here is a summary of what the linked example does (with some elaboration to understand implications to other cases and other types of SMs). I think it is a reasonable solution and I propose continuing to use it, but I wanted to run it by the community before we commit to this solution for new models:

  1. If the box is nonperiodic, use the /coul/cut version of the pair_style with a cutoff equal to the diagonal size of the box (if /cut is not available, as in /cs pair_styles, use /wolf with a damping of 0 to replicate the behavior of /cut).
  2. If the box is 3D periodic and contains charges, use /coul/long and kspace_style pppm
  3. If the box is 2D periodic, add kspace_modify slab to 3)
  4. Do not provide any special support for 1D periodicity. Leave it as /coul/long and kspace_style pppm with no other modifications. This means that, nominally, KIM SMs do not support 1D periodicity, but the user does have the option of issuing their own kspace_modify wire command (which I understand is far from the ideal way to do 1D Coulomb, but it both provides a workaround for advanced users, and avoids inexperienced users unknowinly using inadvisable simulation settings).

What do you think? Is this the best option to cover as many cases as possible, or does anyone have ideas for improvement?

Cheers, ilia

@ilia_nikiforov I would be very surprised if you would get much usable feedback in this forum, and whatever you get is rather biased, because the majority of people posting here are beginners with sometimes limited experience. It is occasionally quite frustrating to not have a channel to communicate with the majority of LAMMPS users, and especially the more experienced ones that do not look for assistance and are often too busy, too. On top of that, there has been a tradition within the LAMMPS community, especially among the “power users” to rather contact the “main gui™”, Steve Plimpton, directly with their concerns, even after we have well established that there are now many more shoulders carrying the load of maintaining the software and making choices.

What you are asking about is essentially a problem that is intrinsic to all approaches to create abstractions from simulations: you cannot have at the same time “ease of use”, “consistency and correctness”, and “flexibility and support for all permutations of options”. At some point you have to make choices and give up on trying to support “everything”. Specifically, when it comes to some of the more complex choices and settings. For those it is often better to not use an abstraction but operate “close to the metal” so that one knows exactly what is happening.

1 Like