ERROR: New bond exceeded bonds per atom in fix bond/create

LAMMPS LAMMPS Mailing List Mirror
21

The way this is supposed to work is as follows:

a) use neigh list to find closest possible bond partner to each atom

b) reverse communicate to sync this info across procs

steps a,b should work whether newton pair is on or off

result at this point should be that each owned atom has

one atom it wants to bond with (or none)

c) forward comm of who each atom’s bond partner is

so know this for ghost atoms

d) loop over local atoms I to decide if each bond I-J is accepted

J must also want to bond to I for acceptance

if accepted:

update data structs for atom I and atom J

the update of data structs needs to insure the bond
is stored only once if newton bond on, and twice if newton bond off

you proposed code change is in the update data structs section,
which I think breaks the logic for newton bond on vs off

if I understood, you had Gravelle test if with newton bond off,

which doesn’t actually exercise the change in the if test you made

So I think there must be some other issue.

For Gravelle:

how do you know you are getting too many bonds attached

to one trap? Can you detect the first timestep at which
this happens? I.e. a shorter, smaller simulation to debug.

does this problem go away if you don’t do fix bond/break and

fix bond/create together? I’m guessing there might
be some issue with using both together that is confusing
the code.

Steve

22

The way this is supposed to work is as follows:

a) use neigh list to find closest possible bond partner to each atom

b) reverse communicate to sync this info across procs

steps a,b should work whether newton pair is on or off

result at this point should be that each owned atom has

one atom it wants to bond with (or none)

c) forward comm of who each atom’s bond partner is

so know this for ghost atoms

d) loop over local atoms I to decide if each bond I-J is accepted

J must also want to bond to I for acceptance

if accepted:

update data structs for atom I and atom J

the update of data structs needs to insure the bond
is stored only once if newton bond on, and twice if newton bond off

you proposed code change is in the update data structs section,
which I think breaks the logic for newton bond on vs off

if I understood, you had Gravelle test if with newton bond off,

which doesn’t actually exercise the change in the if test you made

So I think there must be some other issue.

For Gravelle:

how do you know you are getting too many bonds attached

to one trap? Can you detect the first timestep this happens,
to have a smaller, quicker problem to debug?

does this problem go away if you don’t do fix bond/break and

fix bond/create together? I’m thinking the issue may be
something to do with the competition between them when
using both commands.

Steve

23

The way this is supposed to work is as follows:

a) use neigh list to find closest possible bond partner to each atom
b) reverse communicate to sync this info across procs

steps a,b should work whether newton pair is on or off
result at this point should be that each owned atom has
  one atom it wants to bond with (or none)

c) forward comm of who each atom's bond partner is
    so know this for ghost atoms
d) loop over local atoms I to decide if each bond I-J is accepted
    J must also want to bond to I for acceptance
    if accepted:
      update data structs for atom I and atom J

the update of data structs needs to insure the bond
is stored only once if newton bond on, and twice if newton bond off

the original problem was you must not try to create the bond on the
wrong MPI rank. that is what was causing the original problem (with
newton bond on). setting newton_bond to off worked around it, because
then bonds get stored on both MPI ranks and it doesn't make a
difference.

you proposed code change is in the update data structs section,
which I think breaks the logic for newton bond on vs off

true. but only for newton pair off, if i am not mistaken.

if I understood, you had Gravelle test if with newton bond off,
which doesn't actually exercise the change in the if test you made

my change was intended to fix the issue for newton bond on. but i see
that not all possible scenarios are covered by that. i'll make some
more tests and will provide an improved version.

So I think there must be some other issue.

i disagree.

24

ok - Axel and I figured out the issue - so I’ll
post a patch later today …

Thanks everyone,
Steve