About other integration scheme lammps

LAMMPS LAMMPS Mailing List Mirror
1

Dear,

I have a question : Why lammps as a project as large and scalable software only has integration schemes Velocity - Verlet and Respa ?.
I am fully aware that both schemes previously mentioned have very good computational performance and physical well reproduced . However , in the literature there is a lot of integration schemes : predictor -corrector , Leap -frog , Beeman (3rd order speeds) , Velocity - Verlet corrected ( fourth order in speed ) , Gear Predictor -Corrector and Runge - Kutta . Each with its advantages ( short-term precision among others) and disadvantages ( higher computational cost, not time - reversible , etc.) , but nevertheless , have been used in some simulations under certain conditions.
¿ LAMMPS has a very rigid structure to add a new algorithm integration?

Regards

2

Dear,

I have a question : Why lammps as a project as large and scalable software
only has integration schemes Velocity - Verlet and Respa ?.

​because for most people it doesn't matter much, are very efficient, and
they have the properties that the majority of people are looking for. codes
that don't use them, often do this for historical reasons.

I am fully aware that both schemes previously mentioned have very good
computational performance and physical well reproduced . However , in the
literature there is a lot of integration schemes : predictor -corrector ,
Leap -frog , Beeman (3rd order speeds) , Velocity - Verlet corrected (
fourth order in speed ) , Gear Predictor -Corrector and Runge - Kutta .
Each with its advantages ( short-term precision among others) and
disadvantages ( higher computational cost, not time - reversible , etc.) ,
but nevertheless , have been used in some simulations under certain
conditions.

​this is more a question of "religion" than of science, so i am not
commenting on this.​

¿ LAMMPS has a very rigid structure to add a new algorithm integration?

​you can write your own integrator style(s) as derived classes just like
you can add many other variants of features to LAMMPS. however, ​different
integration schemes may also require custom fixes or adding fix APIs so
that the integrator related methods are called at the proper times for the
new integrator. this is already required for r-RESPA. in fact, the r-RESPA
integrator is an example for adding an additional integrator to LAMMPS.
please see the fix.h header file for details. as well as
integrate.h/integrate.cpp and verlet.h/verlet.cpp and respa.h/respa.cpp

axel.

3

Why not asking yourself? If you were to code a simulation software with the goal of modeling complex systems and where the integrator scheme (to solve the ODEs/PDEs) was just one among the many many features you needed to implement, what would your strategy had been?
Simplicity and robustness anybody? The rest like Axel mentioned is philosophical debate…
Of course Steve may had further arguments to go down that way.
Carlos

4

You could probably also write an alternate integration

scheme within the Verlet framework. E.g. part of what

makes it velocity-Verlet is that fix nve (for example)

implements a 1/2v, x update at the start of the step,

and a 1/2v update at the end. You could write

your own fix to update x,v as you wish at different

points during the timestep.

That said, the simple reason (almost) no one uses

other more complicated intergration methods in MD,

is they don’t make much difference. They don’t buy

you longer timesteps or more accuracy, and aren’t worth

the expense.

Steve