Create_bonds for class2 impropers

Hello LAMMPS,

Before I glance through the code, why doesn’t LAMMPS currently support create_bonds when using class2 impropers?

Thanks,

Jake

PS. the version of nearest neighbor compute I sent earlier prints the square of distance

Hello LAMMPS,

Before I glance through the code, why doesn't LAMMPS currently support
create_bonds when using class2 impropers?

because very few people use them and thus nobody has asked or
considered to implement support for it.
many of the features in LAMMPS are added by the people that need them
or that can make a good case why something would be of good use for a
large number of LAMMPS users or is easy to do. the time of developers
is very limited and a packages as large as LAMMPS also requires quite
a lot of time for simple maintenance and bugfixing work.

axel.

Hello,

I guess I should have clarified: I would assume that class2 impropers implements a parent impropers class which create_bonds ‎uses, but something about class2 as opposed to other improper types causes a bug. I was wondering if anyone knew what that something was before I took a look at it.

Thanks

Original Message

Hello,

I guess I should have clarified: I would assume that class2 impropers implements a parent impropers class which create_bonds ‎uses, but something about class2 as opposed to other improper types causes a bug. I was wondering if anyone knew what that something was before I took a look at it.

if you think there is a bug, then please provide a simple example that
reproduces it.

class2 force fields are a tricky issue, though, since there is not
just a single interaction to be added on the bond topology, but there
are multiple many-body interactions needed. so i don't think that it
would overall be easy to properly support class2 for bond/create
beyond adding bonds.

axel.

It’s b/c not all improper styles define the atom ordering consistently,
and fix create/bond doesn’t have logic to detect or handle the different cases.
The better solution is to make the topology of all the improper styles
consistent with each other, so that fix bond/create doesn’t need to
distinguish between them, but no one has done that yet.

Steve

It's b/c not all improper styles define the atom ordering consistently,
and fix create/bond doesn't have logic to detect or handle the different
cases.

Improper interactions are notoriously difficult to generate correctly
and various force-fields use different improper-atom-order conventions
(and symmetry/redundancy properties). Anyone is using this feature
might want to check the atom order of the generated impropers. (...and
perhaps change the parameters of the generated improper interactions
to compensate when the atom order differs from what you expect).
One way to check to see which improper interactions were created using
the "write_data" command (for example). Then examine the "Impropers"
section of the data file.

Cheers

In case my earlier answer wasn’t clear, fix bond/create assumes

impropers have a certain ordering of their 4 atoms and bonds and adds them accordingly.

I think that ordering is correct for all the improper styles, except class2 and ring.

So fix bond/create flags those as not compatible with what it does.

Until someone carefully looks at all the improper styles and either

a) makes their ordering consisitent, or

b) understands it to the level they each can “publish” an ordering

based on the bonds they assume, so that other commands

like fix bond/create can simply query that ordering

then this issue won’t be resolved.

The reason for the confusion is all the improper styles were

written independently (over many years), and various force

fields have their own conventions on ordering.

Steve

Hey All,

Thanks, this really helped me out.

Considering we are specifying the improper type in create/bonds, the order of atoms is technically already known from the data file (assuming all that matters is atom type) and could be extracted. Therefore it should be possible to assign them in that order in the create_impropers method of fix bond/create. This should also apply equally well to all other improper types. [in the future, it might also eliminate the need to specify the improper type at all]

Also I think a critical addition to create/bonds would be to update the adjacent bond types if itype or jtype is changed to inewtype or jnewtype.

I can take a shot at coding the first part at least.

Thanks,

Jake

PS

  1. itype standing for improper type is a little confusing at times, when itype is already used for atom i

  2. just to make sure, despite lammps saying i would need to turn off pairwise interactions when both improper and pair_style is defined, these are already turned off by default right? (assuming no more than a 1-4 neighbor)

Considering we are specifying the improper type in create/bonds, the order of atoms is technically already known from the >data file (assuming all that matters is atom type) and could be extracted. Therefore it should be possible to assign them in >that order in the create_impropers method of fix bond/create. This should also apply equally well to all other improper >types. [in the future, it might also eliminate the need to specify the improper type at all]

I don’t think this is correct. First, there is no data file or data file information
known to fix bond/create. The user didn’t even have to have a data file
to use this command, and it wouldn’t have to have any impropers listed in it.

It’s been a while since we coded this, but I think the logic that is in
FixBondCreate::create_improper() works for all of
the current improper styles except class2 and ring (that needs to be
checked more carefully). That is b/c the ordering
of atoms and what bonds exist between those atoms is consistent for all those
other improper styles. But not for class2 and ring. There is no info anywhere
in the code that stores that ordering. It’s hard-coded into those two improper
classes. Therefore I don’t see anyway that create_improper() can
do the right thing unless there is some exchange of info between the
improper style and fix bond/create. That is what I suggested in my
earlier email.

Another, possibly better way to do this, would be to have fix bond/create
take a “molecule” file as optional input, as defined by the molecule command.
Then when a new bond is added, the local region around that bond could be
“matched” to the list of angles, dihedrals, improper etc in that file and multiple
ang,dihed,impro created with the ang,dihed,impro types listed in that file.
Again, that would require that all improper styles be consistent in their orderings.

I think Tim Sirk (CCd) has been working or at least thinking about something
like that, so I suggest you confer with him before modifying anything in fix bond/create.

Steve