Lammps Balance command

LAMMPS
,
1

I am running the Dec’2021 Lammps version on an HPC cluster - Bridges2.

I am using the following script, and although the output indicates that balancing has been completed, the simulation does not proceed afterwards, with the run command failing to execute. Can someone help with the essential things to get the balance command right?

2

Your post is violating multiple of the forum guidelines and thus you are making it very hard to provide any advice or assistance.

  1. your quoted input in your post is unreadable (have you looked at it? does it look like your input to you??). The guidelines explain how to properly quote from files.
  2. you are not providing information about which LAMMPS version you are using, what platform you are running on and what your command line is
  3. when reporting errors or potential bugs, it is usually required to provide a minimal(!) but complete(!!) input deck that allows to reproduce the problem quickly. Ideal is often a case where you can reproduce the issue by modifying one of the LAMMPS examples, then you only need to provide the modified input and it is guaranteed that the system is small enough for debugging.

Please edit your post accordingly.

3

Now there is no script here at all. How should we know?
You are using a very old version of LAMMPS, so there may be bugs that have since been fixed.

Two obvious questions:

  • does your input run without the balance command (and without the comm_modify)?
  • do you have proof that the balance command is even needed?
4

Yes, it runs without the balance and comm_modify command.
Without using it, there is a lot of imbalance in the number of atoms per processor.

Here is an example from the slurm output file:
Nlocal: 687.5 ave 1376 max 46 min
Histogram: 1 4 0 2 1 1 2 2 2 1

Part of the script is here. ( let me know if there are some changes needed here)

label loop
if “{currEps} >= {epsFinal}” then “jump SELF break”
print ‘current epsilon12 is ${currEps}’

pair_coeff 1 2 lj/gromacs {currEps} {Ddum}

fix logThermo all print 200 “(step) {T} {P} (vol) (ke) (pe)”

comm_style tiled
balance 1.1 rcb

dump mydump all atom 1250 file.cube
dump_modify mydump sort 2 append no

run ${stepLength} upto

write_data filename

unfix logThermo
undump mydump
variable temp equal {currEps}+{rampStep}
variable currEps delete
variable currEps equal {temp} print {currEps}
reset_timestep 0
jump SELF loop

5

Please re-read my first response. I cannot read your quoted script this way and there is further important information missing. It is not possible to give good advice on such fragmented, incomplete and misformatted information. If you don’t improve the quality of your post significantly, you will have to find somebody else to get assistance.

Much more information is needed to make some meaningful suggestions, like the actual geometry and distribution of particles and number of processor. Many imbalance issues can be resolved with a smart use of the “processors” command after knowing the geometry of your system.

The benefit of recursive bisectioning is offset with an increased communication cost.
You also have a very small number of atoms per processor, so there is a good chance that you are already beyond the limit of scaling and that tiled communication will only make you slower.

This doesn’t say much. The real useful information in in the timings breakdown.
But with so few atoms, the simulation should not take very long anyway. Or if it takes long, than the reason is likely elsewhere.