Improved LAMMPS support.

[mrshirts]

Description
Please describe the behavior you would like added to Interchange.

Various things we've discovered about lammps files that are requiring/using some post-generation modification we would like to improve on.

• One HIGHLY annoying thing with the hybrid functional form: Currently in the lammps data file output, hybrid functions (i.e. "bond_style hybrid harmonic" are specified in the data file as:

Bond Coeffs

1 harmonic      582.698766451   1.225198386222
2 harmonic      329.96998057905 1.427343958716
3 harmonic      301.15400723785 1.345741232799
4 harmonic      264.62148576755 1.52190126495
5 harmonic      370.04670688625 1.093899492634
6 harmonic      366.7408841747  1.425895053732

This is a totally valid simulation input. However, with the harmonic specified explicitly in the Bond Coeffs section, APPARENTLY, when running from a restart file (and then converting that restart file to a new data file), this section is just plain skipped. Not clear why - maybe the restart file can't store strings, so just ignores the lines instead (seems bad). Thus, if one wants to continue a run by using the restart file, hybrid style terms have to be specified in the input file instead of the data file, i.e one would put in lines like:

bond_coeff                      1 harmonic      582.698766451   1.225198386222
bond_coeff                      2 harmonic     329.96998057905 1.427343958716
bond_coeff                      3 harmonic      301.15400723785 1.345741232799
bond_coeff                      4 harmonic      264.62148576755 1.52190126495
bond_coeff                      5 harmonic      370.04670688625 1.093899492634
bond_coeff                      6 harmonic      366.7408841747  1.425895053732

• In the data file, "Atoms" should be "Atoms # full" to match the "full" in the atom style. The comment triggers lammps to check if the data is indeed of atom full style.

• The "atom/bond/etc count" section format has changed. LAMMPS reads both, but some tools/libraries do not use the old format. Something like:

9375 atoms
9250 bonds
16625 angles
28500 dihedrals
2250 impropers
 
8 atom types
9 bond types
5 angle types
25 dihedral types
1 improper types

Should now be written like:

9375 atoms
8 atom types
9250 bonds
9 bond types
16625 angles
5 angle types
28500 dihedrals
25 dihedral types
2250 impropers
1 improper types

• (lower priority) Apparently, it handles things better if the 'tilt' section is not included if all zeros. i.e. if all zeros like "0.0 0.0 0.0 xy xz yz", then omit printing that line.

We can work around these for now, but it might be good to adjust them. @timbernat can potentially help to generate a PR for some of these.

The first one is highly annoying, but would eliminate a decent amount of scripting.

[mattwthompson]

Will take a closer look tomorrow, but in passing these all look like good ideas

hybrid functional form

I forget if there was a good reason for doing this ... I think this was motivated by needing to get one of the torsion styles to match up, but I don't remember if this means the bond style must also be the cursed hybrid style. Certainly only harmonic bond stretching is supported now. Pretty annoying re: restart files!

Atoms # full

I didn't know about this trick - seems funky to encode this information after a pound, but also potentially useful! It looks like there are several sections this could apply to? https://docs.lammps.org/read_data.html#format-of-the-body-of-a-data-file

The "atom/bond/etc count" section format has changed

No dog in the fight, but is the ordering implied by some sort of community understanding or other tool? You're right that LAMMPS itself does not care ("Header lines can come in any order.")

it handles things better if the 'tilt' section is not included if all zeros

Should be an easy patch - check if this condition is met, then don't print that stuff

I'd be happy to review/co-author PRs from Tim or others on any of these. Preferably separate PRs for each, and it looks like the list top-to-bottom is ordered in descending scope/difficulty.

[mattwthompson]

Contributions still welcome for any of these ideas - please one at a time, though, and in separate PRs