Moltemplate

Summary
Researcher Matthew Bone (Bristol Composites Institute, University of Bristol, UK) has contributed the "dreiding.lt" file which adds support for the DREIDING force field. When preparing an all-atom simulation using moltemplate, the most difficult task is to determine the correct type for each atom. (Some tools make this easier, but this issue can arise with these tools as well.) DREIDING has the advantage that it is comparatively easy to choose appropriate atom types for a wide variety of molecules. Matthew provided a short guide, currently available [here](https://github.com/jewettaij/moltemplate/blob/master/doc/DREIDING_Label_Manual.pdf) and [here](https://github.com/m-bone/moltemplate-DREIDING/blob/master/DREIDING_Label_Manual.pdf).
(This guide might be moved in the future, but it will remain available.)

Limitations: *atomic charges*
Some force-fields (like COMPASS, and moltemplate's version of OPLSAA) include rules for assigning partial charges to atoms. Most force fields, including DREIDING do not. So DREIDING users will have to obtain atomic charges by some other means, probably by using 3rd-party tools. (Alternatively, LAMMPS' [fix qeq/point](https://lammps.sandia.gov/doc/fix_qeq.html) feature can be used to assign partial charges, especially for simple molecules containing only C, H, O, N atoms. If this fix is run infrequently, or run only once at the beginning of the simulation, then it should not slow the simulation down significantly.)

Examples
Examples using the DREIDING force field will be made available [here](https://github.com/jewettaij/moltemplate/tree/master/examples/all_atom/force_field_DREIDING).
(Currently there is only one example.)

Development Status: *beta*
As of 2020-10-19, this software has been tested for consistency between LAMMPS
and Materials Studio using only two simple molecules (butane and ethylene).
Please use this force field with caution and report any inconsistencies you find.

Moltemplate (specifically "lttree_postprocess.py") now complains whenever the user fails to specify the mass of one of the particle types in the "Data Masses" section.

*(This assumes that a "Data Masses" section exits. If not, moltemplate prints a warning message. Moltemplate does not force users to define a "Data Masses" section. But if one is present, moltemplate will check that all atom type masses are defined there.)*

Atom type names are now listed as comments in the Masses section of the DATA files generated by moltemplate for all popular force fields supported by moltemplate. (The atom type names will now be consistent with the string following "atom:") The scripts that convert these force field files into LT format have been updated for python3 compatibility. The "cleanup_moltemplate.sh" script has been updated to preserve these atom type names (and not erase them). Finally, the "ltemplify.py" script now has a "-preamble" argument allowing users to prepend text at the beginning of the files generated by "ltemplify.py".

A bug in *ltemplify.py* was preventing the *cleanup_moltemplate.sh* script from working correctly sometimes. In particular some files from the ATB database were causing it to fail. Thanks to Alberto Zoccante (Università del Piemonte Orientale) for reporting the bug!

1) Fixed bug preventing "pair_coeff" commands from being understood correctly if they appear outside of the "system.in.settings" file (ie. outside the "In Settings" section). (This is the place where those commands usually appear.) Now "pair_coeff" commands can appear in any file created by the user, and they will be post-processed correctly (even if the atom-variable-names contain wildcards).
2) Made some additions to the moltemplate_manual including a new chapter on creating (and using) force fields.

fixed a bug preventing generation of helpful error messages in response to non-sensical user input (eg "atom:"). The previous version would crash with an uncaught exception when presented with this input:

write_once("In Settings") {
pair_coeff atom:WallParticle/W atom:
}
Molecule {
write("Data Atoms") {
$atom:w $mol:. atom:W 0.0 0.0 0.0 0.0
}
}

(The syntax error in this example is on line 2. The new version of ttree.py and moltemplate.sh generate error messages instead of crashing.)