minor update regarding "system.in" files

Normally, moltemplate files contain write_once() and write() commands that append text to files with names like "In Settings" or "In Init". Later, moltemplate will automatically convert the names of these files to "system.in.settings" and "system.in.init". After this patch, users can now write to the "system.in.settings" and "system.in.init" files directly (instead of "In Settings", and "In Init", and other files that begin with "In "). Moltemplate.sh will now check these files as well when it checks to make sure that all of the necessary coeffs have been defined.

Known bug

If the user writes to "system.in.settings" and also writes to "In Settings", the text in "In Settings" will erase the text in "system.in.settings" (instead of appending the two files together). This is an easy to fix, but I don't have time to get to it now. I'll post another update soon.

escape characters are now parsed correctly

Fixed a bug in the lexer preventing escape characters ('\') from being interpreted correctly when preceding curly brackets ('\{') or other escape characters ('\\'). This may have been impacting ATB database users and MOLC users. Hopefully the ATB files work well again with moltemplate now. (And hopefully this fix doesn't break anything else.)
Thanks to Otello M. Roscioni (MaterialX LTD) for discovering the bug!

several bug fixes for DREIDING and dump2data.py

Bug fixes

Three bugs were fixed in this release.

1. A small correction was made to the DREIDING force field was made. According to Matt Bone: "This is a very niche bug that will only have affected people with dihedral bonds involving O_2_b1 and other X_2_b1 atom type labels."
2. Moltemplate no longer erases the useful comments (such as atom types) in the system.data file created whenever the -xyz or -pdb or -raw arguments are used. (This also occurred when using "dump2data.py".)
3. An attempt was made to fix "dump2data.py" so that it can handle triclinic boundary conditions correctly. (This has still not been tested, and there is a high probability that it still does not work.)

Examples

Numerous changes were also made to the documentation that accompanies the OPLSAA and COMPASS examples, and a new example was added.

Credit

Thanks to Matt Bone (U. Bristol) for bug reporting and bug fixing!

regular expressions appear to be working now

(...at least simple ones do, such as "@{atom:re.C[1-2]}")
Regular expressions can now appear in "_coeff" commands as well as in "By Type" angle generation sections (which typically appear in force-field files). More testing is needed. Corresponding updates were made to the manual ("moltemplate_manual.tex"), but the pdf version of the manual has not yet been updated.
An early, crufty version of the "postprocess_transitions.py" file has been added. (It is not yet complete.)

DREIDING force-field support added

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 and here.
(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 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.
(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.

check for missing masses

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 in Masses section of DATA file are consistent

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".

fixed a bug in cleanup_moltemplate.sh and 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!

pair_coeff commands can now appear anywhere

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.

edge case bug

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.)