How to speed up the calculation？？？

LAMMPS LAMMPS General Discussion
1

Dear all:

  1. My model is organic molecules grafted between the upper and lower plates, with NaCl solution in the middle! Organic molecules and solvent beads are partially charged！The system contains about a hundred thousand beads！
  2. If I don’t add the long range Coulomb interaction called coul/long, the whole system takes only ten minutes to complete the calculation！！If the long-range Coulomb interaction is added, the calculation speed becomes quite slow, which increases to about a month！！
    3.My question is how to adjust my in file to reduce the computation time!
  3. Here is my in file:
    units lj
    dimension 3
    boundary p p p
    neighbor 10 bin
    neigh_modify delay 10 every 2 check yes
    atom_style full
    pair_style hybrid/overlay dpd 1.0 1.0 343587 coul/long 3.0
    bond_style harmonic
    comm_modify vel yes cutoff 3.5
    kspace_style ewald 1.0e-4
    read_data data.200000

group wall type 5
group head type 1
group C type 2
group N type 3
group S type 4
group W type 6
group NaCl type 7 8
group poly type 1 2 3 4
group ss union head wall
set group N charge 1
set group S charge -1

pair_coeff 1 1 dpd 25.0 4.5 1.0
pair_coeff 1 2 dpd 25.0 4.5 1.0
pair_coeff 1 3 dpd 25.72 4.5 1.0
pair_coeff 1 3 coul/long
pair_coeff 1 4 dpd 25.05 4.5 1.0
pair_coeff 1 4 coul/long
pair_coeff 1 5 dpd 800 4.5 1.0
pair_coeff 1 6 dpd 31.21 4.5 1.0
pair_coeff 1 7 dpd 31.21 4.5 1.0
pair_coeff 1 7 coul/long
pair_coeff 1 8 dpd 31.21 4.5 1.0
pair_coeff 1 8 coul/long
pair_coeff 2 2 dpd 25.0 4.5 1.0
pair_coeff 2 3 dpd 25.72 4.5 1.0
pair_coeff 2 3 coul/long
pair_coeff 2 4 dpd 25.05 4.5 1.0
pair_coeff 2 4 coul/long
pair_coeff 2 5 dpd 800 4.5 1.0
pair_coeff 2 6 dpd 31.21 4.5 1.0
pair_coeff 2 7 dpd 31.21 4.5 1.0
pair_coeff 2 7 coul/long
pair_coeff 2 8 dpd 31.21 4.5 1.0
pair_coeff 2 8 coul/long
pair_coeff 3 3 dpd 25 4.5 1.0
pair_coeff 3 3 coul/long
pair_coeff 3 4 dpd 25.78 4.5 1.0
pair_coeff 3 4 coul/long
pair_coeff 3 5 dpd 800 4.5 1.0
pair_coeff 3 5 coul/long
pair_coeff 3 6 dpd 31.35 4.5 1.0
pair_coeff 3 6 coul/long
pair_coeff 3 7 dpd 31.35 4.5 1.0
pair_coeff 3 7 coul/long
pair_coeff 3 8 dpd 31.35 4.5 1.0
pair_coeff 3 8 coul/long
pair_coeff 4 4 dpd 25.0 4.5 1.0
pair_coeff 4 4 coul/long
pair_coeff 4 5 dpd 800 4.5 1.0
pair_coeff 4 5 coul/long
pair_coeff 4 6 dpd 33.03 4.5 1.0
pair_coeff 4 6 coul/long
pair_coeff 4 7 dpd 33.03 4.5 1.0
pair_coeff 4 7 coul/long
pair_coeff 4 8 dpd 33.03 4.5 1.0
pair_coeff 4 8 coul/long
pair_coeff 5 5 dpd 25.0 4.5 1.0
pair_coeff 5 6 dpd 800 4.5 1.0
pair_coeff 5 7 dpd 800 4.5 1.0
pair_coeff 5 7 coul/long
pair_coeff 5 8 dpd 800 4.5 1.0
pair_coeff 5 8 coul/long
pair_coeff 6 6 dpd 25.0 4.5 1.0
pair_coeff 6 7 dpd 25.0 4.5 1.0
pair_coeff 6 7 coul/long
pair_coeff 6 8 dpd 25.0 4.5 1.0
pair_coeff 6 8 coul/long
pair_coeff 7 7 dpd 25.0 4.5 1.0
pair_coeff 7 7 coul/long
pair_coeff 7 8 dpd 25.0 4.5 1.0
pair_coeff 7 8 coul/long
pair_coeff 8 8 dpd 25.0 4.5 1.0
pair_coeff 8 8 coul/long

mass 1 1.0
mass 2 1.0
mass 3 1.0
mass 4 1.0
mass 5 1.0
mass 6 1.0
mass 7 1.0
mass 8 1.0

bond_coeff * 180 0.8
velocity all create 1.0 4928459 dist gaussian
fix 1 ss setforce 0.0 0.0 0.0
velocity ss set 0.0 0.0 0.0

timestep 0.001

thermo 10
thermo_style custom step dt time atoms temp press pe ke etotal evdwl ecoul epair elong enthalpy vol density
thermo_modify flush yes lost ignore lost/bond ignore
dump 1 all custom 100 dump.lammpstrj.gz id mol type mass x y z xu yu zu vx vy vz q

fix 2 all nve/limit 0.1
fix 3 all temp/rescale 100 1.0 1.0 1.0 0.2
run 150000
write_data data*
write_restart restart.equil

3B89732B7921283721AAB5D9DCC20960
3B89732B7921283721AAB5D9DCC209601123×1395 203 KB

2

I dont know if it is normal to have such an ultra large difference in computing time as you mentioned when using or not using coul/long (maybe there is something else not correct in the script?).

Other than that, as I see your system is not homogeneous in atom/volume, this may help your cause: balance command — LAMMPS documentation

3

Why such a huge neighbor list skin?
That will cause a whole lot of undesired pairs to be included in your neighbor list.
A typical value for reduced units would be 0.3 \sigma

Why such an aggressive neighbor list setting? Remember the law of diminishing returns? Going from delay 0 to delay 1 has a saving potential of 50% on the neighbor list build time. With delay 2 it grows by 16% points to 66%. From there on the savings decline. On top of that you can save with “check yes”. Of course by using a huge neighbor list skin you make this work, but that just wastes much more time in the pair style than what you save in doing the neighbor lists less frequent.

Why is this needed? Your equilibrium bond length is only 0.8 \sigma so the default communication cutoff would suffice, even if you switch the neighbor list settings to more meaningful and efficient ones.

These two items in combination are the main performance killer here. With a plain dpd pair style and a 3 \sigma cutoff, you have basically O(N) scaling with system size, so your simulation will be quite fast. However, adding coulomb will slow it down. If you do explicit coulomb with a very large cutoff, your scaling will approach O(N^2) with 100,000 particles that is quite costly. Using kspace_style ewald reduces this to O(N^{\frac{2}{3}}), but that is still very costly. Run for a few hundred steps and compare the timing summary LAMMPS prints for a run with and without coulomb where all the other settings are the same and see for yourself.

The best option to speed up the calculation is to use kspace style pppm. There the limiting factor is the 3d-FFT, which scales O(N \log (N)) and thus will be much better than ewald.

Both of these are bad choices for a production simulation and the need to use them is usually an indication of a bad initial geometry or an unsuitable choice of simulation parameters (e.g. the magnitude of the charges in relation of the DPD pair coefficients). Likely the DPD pair style is not repulsive enough. Plain coulomb has a divergence when particles overlap, but in DPD that is quite possible, so you need to use at the very least a softened coulomb pair style to avoid the singularity and bad behavior when particles of opposite charge come to close, but more likely you need a completely different pair style that handles a suitably dampened coulomb for mesoscale particles, which coul/cut and coul/long are for atomic scale point particles to be used in combination with far more repulsive pair styles like LJ or Morse or Born-Mayer_Huggings or Buckingham.

Please keep in mind that thermalization is already included in the DPD pair style.

In general, are you making up your parameters (including charges) or are you following a specific publication that has the exact settings documented?

3 Likes
4

THANK YOU SO MUCH！I really appreciate your reply

5

I really appreciate your reply！！Thank you for your detailed answer

6

Like Axel said you need to use PPPM not Ewald for large systems.

7

Yes, pls dont get ultra carried away with the idea that I gave because probably, given the points that Axel raised on how the different long range solvers scale with N and the fact that your system has very large N, the balance command is not going to do much anyways.

I just mentioned it because it was one thing within my knowledge that could help you to speed up the calculation (like I said, I didnt know how to judge the huge computing time difference you seem to have when you use coul/long vs not).

8

THANKs

1 Like