I was wondering if there is a BAOAB integrator available or of there is one in development/plans? I have written a simple version that misses some functionality, which I can improve and contribute, but I want to make sure that I am not redoing something that is already done.
I don’t know anything about the requirements of that integrator, but please note that the general workflow of LAMMPS is set up for using a Velocity Verlet integrator. Have a look at 4.7. How a timestep works — LAMMPS documentation
Just checked with grep and it looks like BAOAB only exists in fix pimd/langevin.
$ grep -i baoab *.{cpp,h} */*.{cpp,h}
REPLICA/fix_pimd_langevin.cpp: else if (strcmp(arg[i + 1], "baoab") == 0)
REPLICA/fix_pimd_langevin.cpp: integrator = BAOAB;
REPLICA/fix_pimd_langevin.cpp: "baoab integrators are supported!",
REPLICA/fix_pimd_langevin.cpp: if (integrator == BAOAB || integrator == OBABO) {
REPLICA/fix_pimd_langevin.cpp: } else if (integrator == BAOAB) {
REPLICA/fix_pimd_langevin.cpp: } else if (integrator == BAOAB) {
REPLICA/fix_pimd_langevin.cpp: fmt::format("Unknown integrator parameter for fix {}. Only obabo and baoab "
REPLICA/fix_pimd_langevin.cpp: } else if (integrator == BAOAB) {
REPLICA/fix_pimd_langevin.cpp: else if (integrator == BAOAB)
REPLICA/fix_pimd_langevin.cpp: fmt::format("Unknown integrator parameter for fix {}. Only obabo and baoab "
REPLICA/fix_pimd_langevin.cpp: else if (integrator == BAOAB)
REPLICA/fix_pimd_langevin.cpp: "baoab integrators are supported!",
REPLICA/fix_pimd_langevin.h: enum { BAOAB, OBABO };
REPLICA/fix_pimd_langevin.h: int integrator; // obabo or baoab
Yeah, that’s what especially surprises me. If it is implemented in pimp, why isn’t it implemented more generally? It is essentially a langevin based integrator with a specific breakdown of steps.
I implemented a preliminary version a couple of days ago, but I am not sure if I potentially missed anything specific to LAMMPS.
But it is a very general integrator that is used in GROMACS, OPENMM and elsewhere.
Because people implement in LAMMPS what they need, and if they are nice they share their work and contribute it for inclusion into LAMMPS. Thus, it looks like people are happy with the many choices of integrators and thermostats that are already available.
How should anybody but you know if you don’t provide any details or ask specific questions?
There is a whole programmer’s guide section in the LAMMPS manual with a ton of information.
Please have a look and help yourself ![]()
Well, I am doing LAMMPS development from 2008 and things got quite complicated since then. I especially don’t want to gamble with something like an integrator that is interconnected with many other things like rigid constrains and shake. I was going to attach my code, hoping that someone may have a look. And if noting is missing I will be happy to contribute it for everyone to use and be able to set a twice larger time step like it can currently be done in GROMACS, OpenMM and other MD engines, but it did not allow me to attach files here for some reason. Yes, but thank you for great advice!!!
To the best of my knowledge the leading edge in research in this kind of integrators that allow longer timesteps for Langevin dynamics is the Gronbech-Jensen integrator: fix gjf command — LAMMPS documentation
You probably want to have a look at the referenced publications. This is active research and code is maintained and regularly updated by the researchers.
What do you mean by that? I thought we had made it easier to contribute and added lots of checks and recommendations to the distribution and the documentation. LAMMPS: A Case Study For Applying Modern Software Engineering to an Established Research Software Package
It is a spam prevention measure of the forum, you have to be recognized as a regular user instead of a new user (by reading and posting messages) to be allowed to attach files. But adding stuff here is not likely to be effective. The best way to get feedback on your code is to submit a pull request on GitHub (submit it as draft if you feel it is not 100% ready).
P.S.: since there are implementations of the integrator in other open source packages, you can probably ask an AI coding agent like Claude Sonnet or ChatGPT Codex to write a new/alternate implementation for you and compare it to your own. Since the “memory” of those models includes all kind of data from the web, anything that is included in popular content can be quite successfully transferred. These models are mostly in trouble if you want them to program something completely knew for which no equivalent templates exist from which they can synthesize the desired text.
Thanks, that is actually very helpful. I will do some additonal checks and submit a pull request. And will also look into the other integrator that you mentioned.
I am confident about my implementation of BAOAB scheme, but what I am not sure if there is anything LAMMPS specific that I may be missing (like an important flag or integration with constrains that would require an additinal function calls). That was also the reason behind my question earlier. Because I was wondering if there is any fundamental reason that there is still no BAOAB integration in LAMMPS. For instance, due to incompatibility of BAOAB scheme with Velocity Verlet.
In terms of complexity, it is very subjective opinion. I do agree that many things got easier and overall structure of the code got much much better over. the years but there are some things that now have too many options and layers, like NVT integrator for example. But I am also sure there is a good reason for that.
I would suggest you give it a try and submit a PR for the BAOAB integrator. You can start as a draft PR, work on it, and then change it to ready to review when the PR is ready. The PR reviewers may be able to help with missing important flags or integration with constraints with additional functional calls and so on.
Maybe someone already implemented the BAOAB integrator for LAMMPS for their work, but they haven’t contributed to the public LAMMPS just yet. It is an opportunity for your contribution, in my opinion.
As I already state, people implement what they feel is needed for their purpose. Obviously, nobody has felt this need strong enough to implement it. I suspect that this is because the available alternatives are sufficient.
That is really something for you to sort out. It should be evident from the theory of the integrator and from any kind of validation tests that you would be running.
But you don’t have to use the Nose-Hoover thermostat complex as the point of reference. There are several simpler integrator fixes to look at as reference.
There are the following pages in the manual:
and also the comments describing the meaning of the various flags in src/fix.h
As for contstraints (or rigid bodies) their impact on a thermostat are usually handled by the temperature compute that is used by the thermostat fixes to compute the current temperature to figure out how strongly to change the system properties (i.e. forces and/or velocities) to reach the target temperature. Outside of more diagnostic changes to the fix interface, there has not been much that is relevant to time integration that was changed for a long time.