Feel free to ignore this message. I can’t imagine most people have a strong opinion about this topic. Just a heads up for anyone who is also working on software to read and write data files.
Sebastian Gsänger and I are trying to figure out how to get VIPSTER and moltemplate to communicate together. Both VIPSTER and moltemplate allow users to manually specify the bond types for every bond in the molecule. (Many molecule editors just assume it can be inferred from the atom types, but not all force-fields work that way.) Sebastian suggested using the following protocol to store strings describing bond, angle, dihedral, and improper types in the LAMMPS data file:
(Regarding atom types. Specifying atom type names in the header is optional. That was my idea. To be clear, preferentially, when reading a DATA file, my code checks first for atom type names in the comments in the “Masses” section of the data file. This is to maintain compatibility with the convention that VMD/topotools uses, which I am happy to stick with. I only seek out atom types in the header section of the data file if they are not mentioned in the “Masses” section. But I don’t want to create incompatibilities with other software. Moltemplate does not generate LAMMPS DATA files containing atom-type comments in the header file. VIPSTER doesn’t either. But I included the option to read them from there because can imagine some rare cases where Masses might not be necessary such as when running Brownian dynamics simulations using the zero-mass limit.)
I figure that most users don’t need to manually specify the types of bonds which appear in their molecules. (So perhaps spamming the LAMMPS mailing list was unnecessary.) But if for some reason you do have a strong opinion about where this kind of information should appear, let me know.
Andrew
P.S. One might suggest putting the bond type names in the “Bond Coeffs” section of the LAMMPS data file. But this is not a general solution because many LAMMPS data files don’t have a “Bond Coeffs” section. In fact, this is discouraged. Axel and I have been advocating to try to keep force field parameters out of the DATA file as much as possible. (IE put “pair_coeff”, “bond_coeff”, “angle_coeff”, “dihedral_coeff”, and “improper_coeff” commands in a separate LAMMPS input script.) This is because there are currently some “_coeff” commands that don’t work when you try to put them in the data file. Input scripts are currently the safest, most general way to store force field parameters.