Modification of Verlet::run execution order (specifically the point at which reneighboring is performed)

Hello all,

I am implementing a new method which utilizes the partition functionality to run multiple nearly identical simulations which re-sync themselves each time-step. Consequently they must communicate their states to each other which means it is best if they agree with respect to their spatial decomposition. To that end I have modified the execution order of Verlet::run to have the reneighboring performed before any integration (so that at this point each simulation will be in perfect agreement and therefore should always make the same decision about reneighboring). I understand that modifications of this sort to core LAMMPS functionality cannot likely be distributed as such. My question is: will re-ordering Verlet in this way have any undesirable effects which I have, in my inexperience, not predicted.

Thank you very much to all,

David

Hello all,

I am implementing a new method which utilizes the partition functionality
to run multiple *nearly *identical simulations which re-sync themselves
each time-step. Consequently they must communicate their states to each
other which means it is best if they agree with respect to their spatial
decomposition. To that end I have modified the execution order of
Verlet::run to have the reneighboring performed before any integration (so
that at this point each simulation will be in perfect agreement and
therefore should always make the same decision about reneighboring). I
understand that modifications of this sort to core LAMMPS functionality
cannot likely be distributed as such.

​actually, changes to the Verlet integrator *can* be distributed. all you
have to do is to create a class that is derived from Verlet and overrides
the relevant functions. for example, please see the verlet/split class,
which splits the Kspace force computation on a seperate partition of
processors.

  My question is: will re-ordering Verlet in this way have any undesirable
effects which I have, in my inexperience, not predicted.

without knowing the details, there are indeed fixes that expect certain
processes happen in a particular order and that ​there is a good chance
that some of them would be confused or even crash because of your changes.
the number of different modules in LAMMPS is very large and any deviation
from the expectations can lead to problems, as you already have recognized.

overall, i don't quite understand why you need to change the order of the
calls. to have the reneighboring fully synchronized, wouldn't it be
sufficient to check whether "neigh_modify check yes" is active and simply
require that it is set to "no"? this way a potential divergence due to
small numerical differences when computing the maximum displacement since
the last reneighbor can be avoided.

axel.

Thank you for the quick response,

overall, i don’t quite understand why you need to change the order of the calls. to have the reneighboring fully synchronized, wouldn’t it be sufficient to check whether “neigh_modify check yes” is active and simply require that it is set to “no”? this way a potential divergence due to small numerical differences when computing the maximum displacement since the last reneighbor can be avoided.

I will provide additional detail which will hopefully make it clear.

    1. Create identically initialized replicas
    1. Perform one step of dynamics which each replica employing a different value of delta t
    1. Choose the “winning replica” which advanced the simulation farthest among the set of replicas that satisfied some error criterion (multiple criteria exist ) if this set is empty reduce delta t values for all simulations and repeat this dynamics step until the set is non-empty
    1. Distribute the positions, velocities and forces for each atom from the winning replica to the others (this means all simulations are identical at the beginning of each timestep but not after the first position update [which is when neighboring is normally done]
    1. If the largest/smallest possible time-step size was selected change all simulations to have a larger/smaller delta t (increase/decrease delta t of each simulation by a constant multiplicative factor)
  1. Return to step 1 and repeat as desired

David

A couple suggestions:

a) I would not mess with the Verlet class. It currently

does the neighbor check after atoms move (in the middle

of the timestep), which is the correct place to do it for

velocity Verlet.

If you put the reneighbor at the beginning you will potentially

mess up other operations which depend on the

current sequence of events. E.g. ones called by other fixes.

b) You could look at the prd command (prd.cpp) which

does more complicated things, e.g. running for 100s of steps

before stopping and comparing replicas. It has logic

and methods for deciding which replica is the “winner”

and broadcasting info from that replica to all the others.

It accounts for the possibility that the spatial decomp

is different on different partitions when that happens.

If I recall it also allows for odd-ball things like

2 replicas using different # of procs.

PRD also interfaces with the Verlet class thru its

current methods (e.g. init, setup, run) w/out any

alteration to the Verlet class.

So I suggest you write a new command, in the pattern

of prd. That is what basically all the multi-replica

methods in LAMMPS do, e.g. prd, tad, neb.

Steve