Greetings, LAMMPS users,
At the risk of suggesting a solution that only exposes my ignorance and/or reading comprehension fail, I suggest that the documentation for the fix bond/create and special_bonds extra include an explicit comment like:
Special_bonds extra includes all the special neighbors (1-2, 1-3, and 1-4) and needs to be substantially larger than just the expected one special neighbor for each new bond, even if you don’t think you’re using those 1-3 and 1-4 interactions. The lists are still created with each new bond.
I had FENE bead-spring systems that reacted as they ran last winter, upgraded to the 1Aug2014 LAMMPS version with the new fix bond/create version, and then spent a lot of time in the past couple of days with the mailing list and trial and error before I figured out that lack of extra extra storage was my problem so the value that used to be 1 is now 9.
From the mailing list, I’m not the only one who didn’t realize that extra meant really extra. The 1-2,1-3, and 1-4 lists are mentioned at the top of the special_bonds explanation of extra, but mentioning it again later would also be helpful to reinforce the point.
Joanne
good suggestion - I added some new text to both the special_bonds and fix bond/create
doc pages … see if you think it is more clear (in next patch).
Steve
good suggestion - I added some new text to both the special_bonds and fix
bond/create
doc pages ... see if you think it is more clear (in next patch).
how about taking this one step further?
if any of the "extra" parameters are not specified explicitly, we
could just make the code us a "safe" default, e.g. allow a maximum of
32 special neighbors (26 is the largest in all of the examples bundled
with LAMMPS).
this is a feature where in order to quickly understand the error
message, one needs to know quite a bit of the internals of LAMMPS.
given the fact that LAMMPS has a large non-technical user base, it may
be OK for them to waste a little memory in exchange for not getting
bothered by somewhat cryptic error messages.
axel.
I’m not clear on the problem. This is only an issue for the special
case when the system initially has no molecules (i.e. bonds), like
starting with an empty box. If you just run a problem like in.rhodo, LAMMPS
figures this out for you, based on the molecules that exist.
If you’re creating bonds out of nothing, it seems reasonable to require
the user to think about how much connectivity they plan to induce.
If we just allocate 32 ints per atom, that will in many cases be
the largest data structure in the code, bigger even than neighbor lists.
That doesn’t seem like a good idea.
Steve
I'm not clear on the problem. This is only an issue for the special
case when the system initially has no molecules (i.e. bonds), like
starting with an empty box. If you just run a problem like in.rhodo, LAMMPS
figures this out for you, based on the molecules that exist.
If you're creating bonds out of nothing, it seems reasonable to require
the user to think about how much connectivity they plan to induce.
bonds, yes. special neighbors is - as we can see from the discussions
on the mailing list - a much more challenging issue. ..and i doubt
that a more detailed documentation will help much. it will mostly save
people that would figure it out by themselves save some time and
frustration.
If we just allocate 32 ints per atom, that will in many cases be
the largest data structure in the code, bigger even than neighbor lists.
That doesn't seem like a good idea.
i would want to allocate those extra ints automatically *only* if
somebody asks for _extra_ bonds/angles/dihedrals in the data file and
only if there is no explicit request for leaving room for special
neighbors already. so this would not apply to the common case.
axel.