Moltemplate

Latest version: v2.22.3

Safety actively analyzes 723177 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 6 of 13

2.19.12

Depending on the version of awk installed, not all users were effected.
Hopefully the new awk code (at line 572 of moltemplate.sh) should be more robust and work with all flavors of awk.
Thanks to Daoud El Kadiri for reporting and locating the error (and helping with debugging)!

2.19.11

This is a minor update.

A bug was fixed that prevented moltemplate (ttree.py) from crashing when applied to nonsensical input. Another bug was fixed in genpoly_lt.py. Thanks to Sean Steadley (NC State University) and Reginaldo Gonçalves Leão Jr for reporting these bugs!

2.19.10

Previously, moltemplate users could prepare simulations containing particles that were either all-ellipsoidal, or all point-like partlcles. But there was a bug which prevented simulations containing some ellipsoidal particles mixed with ordinary (non-ellipsoidal) particles. Hopefully this has been fixed now.

2.19.9

Several bugs were fixed in *ltemplify.py*, *dump2data.py*, and *lttree_postprocess.py*. The ice and other water examples have been fixed (replacing "fix shake" with "fix rattle" everywhere). Thanks to Nathan Odendahl (UC Berkeley), and github user "davidfir3" for feedback, bug reporting, and bug fixing!

2.19.8

The order of the atom types listed in the "dreiding.lt" file has been modified to (hopefully) make sure that LAMMPS does not get confused regarding which atoms are hydrogen-bond donors and acceptors. This is an attempt to address issue 46.

I *think* this is working now. However, if you use hydrogen bonds with DREIDING, then please double-check the "system.in.settings" files created by moltemplate.sh, and check each "pair_coeff" command containing the text "hbond/dreiding/lj". Make sure that the atom types are listed in the correct order, with donor atom types listed before acceptor atoms. Before doing this, I suggest running [cleanup_moltemplate.sh](https://github.com/jewettaij/moltemplate/blob/master/doc/doc_cleanup_moltemplate.md#cleanup_moltemplatesh) first. *(Otherwise the number of pair_coeff commands in the "system.in.settings" file might be too large to check by hand. The "cleanup_moltemplate.sh" program should work without issue with DREIDING simulation files as long as your main LT file is named "system.lt". Just type "cleanup_moltemplate.sh" into the terminal after running moltemplate.sh. In the future, when "dreiding.lt" is debugged, this extra effort won't be necessary.)*

Many thanks to Aileen Huang (ahuang5student.gn.k12.ny.us) for reporting this issue!

2.19.7

-The MARTINI force field implementation has been incorrect for years, apparently. *(It might still be, but at least MARTINI simulations now show no visually obvious signs of failure.)* We obtained the MARTINI force field parameters from the EMC program instead of the original source (the cgmartini.nl web site). I am still not positive that the MARTINI force field parameters provided by EMC are compatible with the most recent MARTINI files. (If not, please let me know.) Consequently, it might be necessary to reimplement MARTINI using the original source files in the future.
-The "drymartini.lt" force field file was also added (although it has not yet been tested.)
-I fixed a (hopefully) minor problem in the OPLSAA implementation. I was using a non-bonded distance cutoff that may have been too short (10 Angstroms instead of 11). (The 1996 OPLSAA paper used an 11 Angstrom cutoff for most interactions.) Hopefully this change not significantly effect most simulation results. *(Note to users: We do make mistakes, so it's never a bad idea to double-check the global settings in the force-field files we provide.)*
-Finally, I added some messages that tell users what papers to cite when they run moltemplate. (Hopefully this is not too annoying.)

Page 6 of 13

© 2025 Safety CLI Cybersecurity Inc. All Rights Reserved.