`run 0` without recomputing bins

Greetings once again,

I’ve mentioned earlier that I am basically only using Lammps as an implementation of certain potentials, calling it through the C API to compute forces for structures.

I understand that this really is not the use case of LAMMPS, and it was discussed previously that I am probably better off implementing the potentials on my own. Unfortunately, reimplementing REBO is such a scary prospect that I have stubbornly continued to live with the current setup. I hope there is another solution to my current dilemma.

Here’s what I do:

  1. pair_style/pair_coeffs/create_box/create_atoms and etc.
  2. Set positions using lammps_scatter_atoms.
  3. run 0
  4. Gather forces using lammps_gather_atoms, and potential using lammps_extract_compute.
  5. Repeat 2-4 ad nauseum.

(Between steps 4 and 5, control flow must return to my own code so I can e.g. use them in relaxation to find the next position)

This is slow on large structures, and when I look at perf report, I see that most of the time is spent in LAMMPS_NS::NPairFullBinGhostOmp::build.

The changes in positions are almost always within skin distance. Atoms are never added or removed, their integer “types” never change, and the periodic lattice seldom changes. But it seems that run 0 always recomputes the bins regardless.

Is there something I can do instead to avoid the unnecessary rebinning?

Thanks,

Michael

Hi,

yes, check the pre and post keywords for the run command. For example: run 100 pre no post no
From the documentation:

The pre and post keywords can be used to streamline the setup, clean-up, and associated output to the screen that happens before and after a run. This can be useful if you wish to do many short runs in succession (e.g. LAMMPS is being called as a library which is doing other computations between successive short LAMMPS runs).

Anders

Thank you for the response, Anders!

I haven’t tried “pre no” because I was worried that modifying the coordinates might cause some of the other data left behind to become incorrect. (it sounded to me like the use case for pre and post was so that lammps could be paused and resumed, without modification of the structure inbetween). If that is not the case, this sounds like a viable solution for computing forces on phonon displacements!

During relaxation, however, I also fear that sometimes movements may in fact exceed the skin distance, in which case the bins probably should be recomputed. Maybe if I do run 1 pre no without any kind of simulation enabled?

Michael

Trouble in paradise! I’m getting some weiirrd results while computing forces at displacements for phonons with pre no .

Basically, when I use run 1 pre no in place of run 0, only every tenth displacement has the correct forces! (those particular displacements also take longer to be computed)

Log files:
https://gist.github.com/ExpHP/d3299fa043d4d6e792643edc7cabecd7

What might this be?

Michael

You are correct that you should generally not use pre no if you are changing

atom positions between runs. The method you flagged is what

is bulding the neighbor list before each run. And you say this:

The changes in positions are almost always within skin distance.

If you’re confident the neighbor list will never change

then you should be able to use pre no with run 0. But
not of course with cummulative displacements.

If you’re seeing a difference in a particular run

with pre no versus pre yes, the I’d assume the

new neighbor list was different than the old one.

Steve

You are correct that you should generally not use pre no if you are changing

atom positions between runs. The method you flagged is what

is bulding the neighbor list before each run. And you say this:

The changes in positions are almost always within skin distance.

If you’re confident the neighbor list will never change
then you should be able to use pre no with run 0. But
not of course with cummulative displacements.

If you’re seeing a difference in a particular run

with pre no versus pre yes, the I’d assume the

new neighbor list was different than the old one.

Thanks for the clarification, Steve!

I must apologize, as it turns out I was running a rather old version of LAMMPS. After updating to the March 2018 stable version, I find that using run 1 pre no gives accurate results while still tearing through the displacements at lightning speed.

Indeed I am confident that, during phonon displacements, the neighbor list should never change, as there is no cumulative movement; the first step (where lammps always does pre yes) is computed with the equilibrium structure, and all of the others differ from that initial structure by 1e-3 A (nothing compared to lammps’ skin depth of 2A). That said, I tried running them again with run 0 pre no as you said and it looks like I am getting many forces of nearly zero. (Or rather, my phonon code is reporting a large number of modes with zero eigenvalue, which is indicative of zero force; but I haven’t looked too much further into it, since run 1 pre no seems to work.)

That said, there is a separate part of my code which uses lammps during relaxation, and there is plenty of net movement during this; am I correct in understanding that even run 1 pre no is not safe for this use case? (If not, perhaps I can simply implement a skin-distance check in my own code to decide when pre yes is necessary?)

Michael

Big revelation: (with a healthy dose of PEBKAC)

Indeed I am confident that, during phonon displacements, the neighbor list should never change,
as there is no cumulative movement; the first step (where lammps always does pre yes)
is computed with the equilibrium structure, and all of the others differ from that initial structure
by 1e-3 A (nothing compared to lammps’ skin depth of 2A).

It turns out this was not true. Well, I mean, superficially it is true, but there was something else important that I did not consider:

When Lammps builds neighbor lists, it remaps sites into the unit cell. However, when I was supplying it displacements, I was generating the displaced structures from my own initial input. Thus, from the point of view of LAMMPS, some of the atoms had actually moved by an entire lattice point!

All remaining issues have been resolved by reading back the coords after computing the forces of the equilibrium structure, and using those to produce displaced structures. (although I do still find that run 1 pre no is necessary and not run 0 pre no)

Michael

Glad you got things to work as you expect …

Steve