why New bond exceeded bonds per atom in fix bond/create?

LAMMPS LAMMPS Mailing List Mirror
1

Tons of “dangerous builds” can be solved by a larger skin distance of neighbor ,such as 1.0 bin.
I have changed the datafile to “3 extra bond per atom” with a “special_bonds lj 0 1 1 extra 3” and indeed found 3 bonds formed in a single type5 bead connecting 3 type4 beads.

Then I changed the datafile back to “2 extra bond per atom” and input to “special_bonds lj 0 1 1 extra 2”
Then I have changed following command:

fix cratebond1 all bond/create 200 1 2 1 1 iparam 1 3 jparam 1 4 prob 0.5 1126546
fix cratebond2 all bond/create 200 3 2 1 1 iparam 2 5 jparam 1 4 prob 0.5 16464221

to:

fix cratebond1 all bond/create 200 1 2 1 1 iparam 1 3 jparam 1 4 prob 0.5 1126546

fix cratebond2 all bond/create 200 3 2 1 1 iparam 1 5 jparam 1 4 prob 0.5 16464221 (Iparam 1 5 differ from previous …)

This seems give correct simulatin results.
However:
http://lammps.sandia.gov/doc/fix_bond_create.html says:
The iparam and jparam keywords can be used to limit the bonding functionality of the participating atoms. Each atom keeps track of how many bonds of bondtype it already has. If atom I of itype already has maxbond bonds (as set by the iparam keyword), then it will not form any more. Likewise for atom J. If maxbond is set to 0, then there is no limit on the number of bonds that can be formed with that atom.

2

i cannot comment on that without spending a significant amount of time
that i currently don't have. this code has recently been worked over a
few times to accommodate new features and handle corner cases that
were initially not anticipated.

one way to process would be to construct a whole set of (minimal) test
inputs (just a few atoms) that test each scenario. ideally, this would
have to be done in multiple variants, so that also the case of bond
being formed by atoms that are "owned" by two different MPI tasks. the
latter is particularly tricky to handle. also, support for using fix
bond/create multiple times was also originally not intended.

ultimately, it boils down to two questions: does the code behave
reasonably and as one can expect? and is the documentation consistent
with the code and precise in the behavior it explains.

since steve is currently working on these issues, it is easier for him
to comment and state what is to be expected and what not.

axel.

3

Thank you.

2014-04-14 4:45 GMT+08:00 Axel Kohlmeyer <[email protected]>: