moltemplate - fixed the "UserWarning: pkg_resources is deprecated" warning message

This fixes issue #111 One of the moltemplate source files (lttree.py) had a dependency on the pkg_resources module, which will be deprecated on 2025-11-30. This small fix removes that dependency. Thanks to github user paigenb for reporting the problem.

- Python
Published by jewettaij 6 months ago

moltemplate - Copied the "oplsaa.lt" file to "oplsaa2024.lt"

(I will eventually remove the original "oplsaa.lt" file because the changing @atom type numbers in that file are causing difficulties for moltemplate users and maintainers.)

In addition to changing the name of that file, I also changed all of the references to that file name, which appear in many places throughout the examples.

Unfortunately this means that the old version of moltemplate which is currently on pypi (which does not include "oplsaa2024.lt") needs to be updated in order for all of these examples to work.

This release updates the name of this file so that the examples will work again for pip and conda users.

- Python
Published by jewettaij 12 months ago

moltemplate - OPLSAA @angle and @dihedral type name corrections

Corrected a bug in OPLSAA ("oplsaa.lt") which incorrectly named several angle and dihedral types (@angle:NBOACR, @angle:NBOACR, @dihedral:H~N~CT_CT) to something else. Those angle and dihedral type names have been restored. This bug was introduced by the the previous release (v2.22.1) one day earlier. Hopefully, very few users (if any) will be affected in this short time interval.
The "oplsaa2lt.py" conversion script has been debugged and cleaned up.

Again, I recommend that all OPLSAA users copy the "oplsaa.lt" file (in the "moltemplate/force_fields/" folder) to their local directory containing the other .lt files they are working on. That will protect users from updates to OPLSAA that can break backwards compatibility. That way users can continue using the same @atom, @angle, and @dihedral type names that they were using before.

- Python
Published by jewettaij about 1 year ago

moltemplate - OPLSAA improvements: Default bonded interactions chosen when duplicates are present

Better default choices for OPLSAA dihedrals, angles, or bonds when multiple such choices exist. Moltemplate will choose a reasonable default choice automatically. Users still have the option to override these default choices.

NOTE: Unfortunately, a few OPLSAA atom types have changed, breaking backward compatibility! Very few atom types were changed. But for future safetly, I suggest copying the oplsaa.lt file you are using into your local folder with your other .lt files to prevent these kinds of disruptions in the future. Moltemplate.sh will look in your local folder first for all the .lt files that it needs, including oplsaa.lt. The OPLSAA documentation was updated with these suggestions.

UPDATE(2025-3-19): To prevent backwards-compatibility-breaking changes in the future, the "oplsaa.lt" file has been renamed to "oplsaa2024.lt" (commit f671547). If you use "import oplsaa2024.lt", then the @atom type names should remain stable. (This assumes nobody finds any serious issues that completely break the "oplsaa2024.lt" file. Otherwise, future updates will go in different oplsaaXXXX.lt files.)

- Python
Published by jewettaij about 1 year ago

moltemplate - OPLSAA2023 water models fixed and moltemplate.sh bug fixed

Fixed a bug in moltemplate.sh. (The bug was introduced when releasing OPLSAA(2023) in version 2.21.1)
OPLSAA 2023 water models were tested and are working.
Numerous examples were debugged and updated.
File names and atom type names have changed (for water models and the alkane examples).

- Python
Published by jewettaij about 1 year ago

moltemplate - OPLSAA 2023 impropers corrected and verified

I corrected several serious mistakes in the improper interactions defined in the oplsaa.lt file (2023 version). If you updated your version of moltemplate to 2.21.1, please update it again. The version of oplsaa.lt from version 2.21.1 will not work.
I am now confident that the improper interactions in the latest oplsaa.lt file are correct! (I verified the new version of oplsaa.lt is correct by confirming that the number and magnitude of the impropers generated by moltemplate (for ethylene and benzioc-acid) agree with impropers generated by the ligpargen server for these molecules. There is one exception: allenes. The original BOSS files have non-sensical improper interactions for allenes. So the oplsaa2lt.py conversion script comments those out.)
The conversion script (oplsaa2lt.py) is also working, so there is no longer a need to hand-edit the generated oplsaa.lt file afterwards.

The improper interactions were the only remaining part of the OPLSAA.lt that I still had serious doubts about. Now that they seem to be working, I'm happy to recommend that people start using the new (2023) version of the "oplsaa.lt" file. (I trust it more than the (2008) version that moltemplate users have been relying on for years. That's because the 2023 version is based on a direct conversion from the original BOSS files.)

- Python
Published by jewettaij about 1 year ago

moltemplate - Introducing OPLSAA version 2023

OPLSAA has been upgraded to the 2023 version with numerous changes.
The OPLSAA examples (and the "loplsaa.lt" file used by LOPLS) have been updated as well.

Many thanks to Domenico Marson who wrote the program that converts BOSS files into moltemplate format!

To use the new "oplsaa.lt" file, you must change the @atom numbers in your .lt files

Many new atom types have introduced into OPLSAA since the previous (moltemplate) version (from 2008). The same atom types are present in the new version, but the @atom numbers assigned to them have changed (to make room for these new atom types). So you must update the @atom type numbers in your .lt files that use "oplsaa.lt".

Alternatively, you can continue using the old version of "oplsaa.lt" and "loplsaa.lt"

...without changing your @atom type numbers. But the .lt file names have changed. You must replace "import oplsaa.lt" with "import oplsaa2008.lt" everywhere it appears in your .lt files. (If you are using LOPLS, then also replace "import loplsaa.lt" with "import loplsaa2008.lt") To see how this is done, see the old examples.

WARNING: The new (2023 version) of OPLSAA is highly experimental.

Please understand the risks of using this new force field.

And please report any problems that you find with this new version.

Specific concerns with the 2023 vrsion: - The improper interactions have not been tested carefully. - The new version of OPLSAA gives you many additional choices for your dihedral, angle, and bond interactions. This makes it possible for you to improve your simulation accuracy, but it also requires more effort on your part. To see the list of choices, you must now run moltemplate with the "-report-duplicates bytype _" arguments. For example: ``` moltemplate.sh system.lt -report-duplicates bytype _ ``` - If you see a file named "warningduplicatedihedrals.txt", "warningduplicateangles.txt", "warningduplicatebonds.txt", or "warningduplicateimpropers.txt" after running moltemplate, then it is a good idea to read the first few warning messages in those files and modify your .lt files accordingly (for example, by adding a custom "Data Dihedrals" section). Several examples demonstrate how to do that, including butane.lt and benzoic_acid.lt

Remaining work to do:

The list of improper interactions generated by the "oplsaa2lt.py" script is incorrect. (I'll worry about this later.) But this should not be an issue for users who just want to use the existing "oplsaa.lt" file included with this release. (That file was corrected by hand.)

- Python
Published by jewettaij about 1 year ago

moltemplate - -report-duplicates warns when multiple choices exist for the same bonded interactions

Added the "-report_duplicates" which warns the user when multiple bonds, angles, dihedrals, or impropers were automatically generated for the same set of atoms. This kind of ambiguity occurs frequently. This is especially important for the upcoming 2023 version of the OPLSAA force-field, which contains many duplicate or ambiguous bonded interaction definitions.

This feature makes it possible for users to find out when other possible bonded interactions exist. If so, they can override the default choice manually.

This feature is probably not very useful unless you are using the 2023 version of OPLSAA force field (which has not yet been released).

- Python
Published by jewettaij about 1 year ago

moltemplate - OPLSAA impropers were corrected

Summary

For OPLSAA, the strength of the improper forces was corrected. Previously simulations prepared with the OPLSAA force field, had improper forces which were too weak by a factor of 2. After this correction, those improper forces have been strengthened to the correct value.

The impact of this change is expected to be small. (See below.)

How this happened

All of this time, I have been relying on the TINKER version of the OPLS parameters. Apparently I have been misinterpreting the numbers in the improper section of that file.

Impact

In OPLSAA, improper forces are only used to impose planar constraints. The strength of these interactions was already quite strong. Strengthening them by a factor of 2 only serves to make these atoms a little bit more co-planar than they were before. So hopefully this correction should not have a large effect on the shape or flexibility of a molecule.

Most papers describing force fields (including OPLS) omit a detailed explanation of improper forces (and their symmetries). I apologize for this mistake, but there may be additional errors in the way improper interactions are calculated. (See below.)

Remaining sources of error: Symmetry

In the current implementation of OPLSAA for moltemplate, multiple improper interactions are generated for atoms bonded in a Y-shape. (For example, ethylene contains 6 improper interactions, even though the Y-shape only appears twice. See here for details.) That's because the improper angle used to calculate the forces depends on the order of these atoms. The improper interaction is calculated 3 times using all 3 (=3!/2) different ways of ordering the 3 outer atoms.

It is not clear whether the original authors of the OPLS force fields intended all 3 of these (somewhat redundant) interactions to be calculated, or if the strength of these interactions should have been weakened (by 1/3) accordingly.

(If anyone knows the answer, please contact me. Currently moltemplate calculates all 3 and does not weaken these interactions.)

Contributors

I'd like to thank Domenico Marson who found the new parameters used by BOSS and explained them to me. He has been working on getting the 2023 version of OPLSAA converted to moltemplate format. That version will hopefully be available in moltemplate shortly. (See #104 for details.)

- Python
Published by jewettaij over 1 year ago

moltemplate - -overlay-all behaves consistently on different OSs

The option -overlay-all has been redefined to have a consistent behaviour on different OSs.
Cosmetic changes to the cleaning of processed files: removing head tab spaces.

(Credit: Otello Roscioni)

- Python
Published by jewettaij about 2 years ago

moltemplate - atom creation is now optional

Change of philosophy: moltemplate now handles the case where atoms are not created. It requires the option -nocheck to render the input deck successfully. This way, moltemplate can create valid input decks for more heterogeneous tasks such as rerun, create_atoms etc. I verified that the program produces a valid input deck for standard usage, with the "new MOLECULE" command invoked.

This change generalizes the kinds of files that moltemplate.sh can create.

Thanks to Otello Roscioni (hothello) for contributing this change!

- Python
Published by jewettaij almost 3 years ago

moltemplate - fixed bug in cleanup_moltemplate.sh

Fixed bug #86 which prevented cleanup_moltemplate.sh from working whenever "moltemplate" was installed using pip or pip3.

(This bug did not effect the small number of users like me who install moltemplate by other means.)

All credit belongs to github user PhnRvTjN (Phani Ravi Teja Nunna) for solving the bug, and to github user yurivict for reporting the bug!

- Python
Published by jewettaij about 3 years ago

moltemplate - python3 is now default intepreter for .py executables

I replaced ```

!/usr/bin/env python

with

!/usr/bin/env python3

``` ...everywhere.

This means users are no longer required to use "python" instead of "python3" when trying to run .py executable files directly from the shell (such as mol22lt.py, ltemplify.py, and genpoly_lt.py). This will enable most users to be able to invoke these python programs directly by their names, without having to predicate them with "python3".

Comment:

I'm sorry I didn't make this change earlier. I've been using anaconda python for a long time, and anaconda automatically adds a link from "python3" to "python", so that users can type "python" instead of "python3". I didn't realize that for most users, "python" isn't even defined.

- Python
Published by jewettaij about 3 years ago

moltemplate - better support for LT files not named "system.lt"

When the LT file is not named "system.lt": - generated "run.in.EXAMPLE" files are renamed to avoid file name collisions (so that users can run moltemplate.sh on multiple LT files in the same directory) - The "cleanupmoltemplate.sh" script can also handle files with names that do not begin with "system" (by including the "-base" argument).
- The "cleanupmoltemplate.sh" script no longer assumes that the python interpreter is named "python". (It could be named "python" or "python2".)

- Python
Published by jewettaij about 3 years ago

moltemplate - bugfixes for cleanup_moltemplate.sh and several OPLS water models

1) I fixed an edge-case bug causing "cleanupmoltemplate.sh" to fail without printing out an error message. This would happen whenever the user ran moltemplate.sh on a file not named "system.lt", and then attempted to run "cleanupmoltemplate.sh" afterwards. (This is a situation that "cleanupmoltemplate.sh" does not handle gracefully.) I did not fix this limitation. But now whenever a user does this, it prints out a detailed error message explaining how to get around this limitation. 2) I fixed some serious mistakes in the "spcoplsaa.lt" and "tip3p_oplsaa.lt" files (for the SPC and TIP3P water models). Thanks to github user feifzhou for pointing them out!

- Python
Published by jewettaij over 3 years ago

moltemplate - updated GAFF2, amber2lt.py, and a few alkane examples

The @atom:hw and @atom:ow atom types in "gaff2.lt" now have been given epsilon and sigma parameters (of 0.0 and 1.0). These parameters are not correct, but at least users who don't need these atom types and want to use "gaff2.lt" will be able to do so (without LAMMPS complaining about missing pair_coeffs).

Similarly the amber2lt.py program will now supply default epsilon and sigma parameters (of 0.0 and 1.0) for atoms when this information is lacking in the FRCMOD or DAT file containing the force-field parameters (such as "gaff2.dat").

The amber2lt.py program accepts a slightly wider range of FRCMOD file formats.

Thanks to Karteek Bejegam and Jonathan Campeggio for their debugging help and suggestions!

- Python
Published by jewettaij over 3 years ago

moltemplate - added the amber2lt.py conversion tool

The newly added amber2lt.py program converts force-field files used by and created by AmberTools (such as FRCMOD and DAT files) into moltemplate (LT) format. The "gaff.lt" and "gaff2.lt" files were created with this program. Now users can use this tool as well with their own custom FRCMOD files.

The amber2lt.py script replaces amberparm_.py files and amber.sh scripts that were used before. (Those scripts were buggy and undocumented.)

- Python
Published by jewettaij over 3 years ago

moltemplate - fixed a bug in moll22lt.py

Fixed a bug in mol22lt.py which occurs when the subID numbers in the MOL2 file do not begin at 1. (In the past, I had only tested it on files where the subunit ID begins at 1.)

- Python
Published by jewettaij over 3 years ago

moltemplate - mol22lt.py and documentation improvements

mol22lt.py now creates less confusing LT files when the MOL2 file contains only a single subunit. Additional improvements to the documentation were also made.

- Python
Published by jewettaij over 3 years ago

moltemplate - fixed a small bug in mol22lt.py

The "--charges" argument for mol22lt.py should be working now.

I forgot to mention that the AMBER "gaff.lt" and "gaff2.lt" files were also recently updated today (in moltemplate v2.20.8). This should help a lot of people who use GAFF or GAFF2.

I also made some minor improvements to the mol22lt.py documentation

- Python
Published by jewettaij over 3 years ago

moltemplate - initial (alpha) attempt at MOL2 file conversion

The new converter program (mol22lt.py) converts MOL2 files to moltemplate (LT) files. This program has not been widely tested and probably fails on some MOL2 files. But the program appears to be useful in some cases.

I fear it is possible I have misinterpreted the MOL2 file format when I wrote this converter. Once I this feature has been tested on a wider variety of MOL2 files, I'll post another version update.

- Python
Published by jewettaij over 3 years ago

moltemplate - bugfix: stop deleting the "system.in" file

This is a very minor update, but I thought it was important. Some people edit that file, and their work was getting erased. Thanks again to Jordan Dialpuri for catching this bug.

- Python
Published by jewettaij over 3 years ago

moltemplate - renamed the "system.in" file to "run.in.EXAMPLE"

I also removed the "moltemplate_manual.pdf" file because it was causing the .git directory to grow in size rapidly as I made frequent changes to this large binary file.

Thanks to Jordan Dialpuri for the suggestion!

- Python
Published by jewettaij over 3 years ago

moltemplate - fixed a bug when using "@{atom:NAME}" syntax

fixed a bug that occurs when @{atom:NAME} syntax is used inside pair_coeff commands. (The explicit use of {} brackets was sometimes failing.)

Thanks to Otello Roscioni (MaterialX, LTD, https://materialx.co.uk) for reporting the bug!

- Python
Published by jewettaij almost 4 years ago

moltemplate - updated the LOPLS force field file ("loplsaa.lt")

The new version of "loplsaa.lt" includes much more clear atom type descriptions (for the atoms described in the 2015 LOPLS paper, at least).

I also removed some (hopefully) unnecessary and confusing atom types (such as 81LL, 118L, 718LL).

The moltemplate.sh program has not been modified, but I updated the version info anyway. (I had to change the version number of the project in order to be able to upload a new version to pypi.)

Please let me know if I have made any mistakes in the process. -Andrew

- Python
Published by jewettaij almost 4 years ago

moltemplate - speed improvement when using wildcards or DREIDING

The changes in this commit can significantly increase the speed of moltemplate.sh when the user's LT files contain wildcard characters ('*' characters) in any of the LAMMPS coeffs or coeff commands. In particular, simulations using the DREIDING force field ("dreiding.lt", which uses wildcard characters frequently) should be faster to prepare. Some coarse-grained force fields also make frequent use of wildcard characters.

- Python
Published by jewettaij about 4 years ago

moltemplate - fixed serious bug in "bond type" count in data files

Fixed a serious bug (the number of bond types in the generated data files are incorrect). LAMMPS would crash when run using data files generated by moltemplate. This bug was caused by a typo introduced in version v2.20.0 on 2022-1-11.

- Python
Published by jewettaij about 4 years ago

moltemplate - fixed a bug parsing blank lines with whitespace

Fixed a bug introduced in the previous version (v2.20.0) causing moltemplate to misinterpret blank lines containing nothing but white space (spaces or tabs). Thanks to github user conandolley103 (Tue Le) for reporting this bug!

- Python
Published by jewettaij about 4 years ago

moltemplate - improved ltemplify.py (whitespace) compatibility and improved dump2data.py and raw2data.py

1) Improved compatibility with ltemplify.py. This required adding better support in moltemplate.sh for atom types and names containing whitespace (which ltemplify.py frequently generates). 2) Improved performance and behavior of dump2data.py and raw2data.py.

This update might break some people's LT files.

- Python
Published by jewettaij about 4 years ago

moltemplate - fixed bugs in genpoly_lt.py and genpoly_modify_lt.py

1) Now you can omit the bond type in genpolylt.py. 2) The "-inherits" argument finally works in genpolymodify_lt.py.

- Python
Published by jewettaij about 4 years ago

moltemplate - corrections to ellipsoid orientation code (read dump)

1) Bugfix: read dump now handles ellipsoid orientation correctly. 2) Corrected the MOLC citation.

Thanks to Otello Roscioni for discovering both problems and correcting them.

- Python
Published by jewettaij about 4 years ago

moltemplate - fixed an issue importing XYZ coordinates

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

- Python
Published by jewettaij over 4 years ago

moltemplate - a few small bug fixes

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!

- Python
Published by jewettaij over 4 years ago

moltemplate - bug fixed (mixtures of ellipsoidal and ordinary particles)

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.

- Python
Published by jewettaij almost 5 years ago

moltemplate - several bugs fixed (ltemplify.py, dump2data.py, lttree_postprocess.py)

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!

- Python
Published by jewettaij almost 5 years ago

moltemplate - updated DREIDING to fix hydrogen bonds

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 "paircoeff" 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 first. *(Otherwise the number of paircoeff commands in the "system.in.settings" file might be too large to check by hand. The "cleanupmoltemplate.sh" program should work without issue with DREIDING simulation files as long as your main LT file is named "system.lt". Just type "cleanupmoltemplate.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 (ahuang5@student.gn.k12.ny.us) for reporting this issue!

- Python
Published by jewettaij almost 5 years ago

moltemplate - updated MARTINI and OPLSAA and added DRYMARTINI

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

- Python
Published by jewettaij almost 5 years ago

moltemplate - use "python3" by default instead of "python"

moltemplate.sh only switches to python" or "python2" if "python3" is not available.

Also: The installation instructions in the README.md file have also been elaborated to help users with python installation difficulty.

- Python
Published by jewettaij almost 5 years ago

moltemplate - fixed file ambiguity issue and added a citation request

I fixed the issue that was introduced in version v2.19.4. Now moltemplate.sh will warn you if you try to write to both "system.in.settings" as well as "In Settings". I also now print a message asking users to cite the moltemplate paper.

- Python
Published by jewettaij about 5 years ago

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

- Python
Published by jewettaij about 5 years ago

moltemplate - 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!

- Python
Published by jewettaij about 5 years ago

moltemplate - 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 O2b1 and other X2b1 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!

- Python
Published by jewettaij about 5 years ago

moltemplate - 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 ("moltemplatemanual.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.)

- Python
Published by jewettaij over 5 years ago

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

- Python
Published by jewettaij over 5 years ago

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

- Python
Published by jewettaij over 5 years ago

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

- Python
Published by jewettaij over 5 years ago

moltemplate - 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!

- Python
Published by jewettaij over 5 years ago

moltemplate - pair_coeff commands can now appear anywhere

1) Fixed bug preventing "paircoeff" 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 "paircoeff" 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.

- Python
Published by jewettaij over 5 years ago

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

- Python
Published by jewettaij over 5 years ago

moltemplate - fixed python3 specific bug involving ".."

fixed a python3-specific bug in ttree.py causing expressions containing ".." (like "@atom:../A") to sometimes cause an uncaught exception. Example: MoleculeTypeA { write_once("In Settings") { @atom:../A } } MoleculeTypeB { } These kinds of expressions should work again now. (The A leaf node should be created in "/" now.)

- Python
Published by jewettaij over 5 years ago

moltemplate - updated the manual and fixed 2 bugs

updated the manual. updated dump2data.py. fixed a bug reading triclinic boundary conditions from PDB files that affects some versions of awk. Corrected the README file for the EFF example.

- Python
Published by jewettaij over 5 years ago

moltemplate - fixed a minor edge-case bug in genpoly_modify_lt.py

Previous versions of genpolymodifylt.py would crash when told to make 0 modifications. The current version handles this edge case more gracefully. Several examples and README files were also updated.

- Python
Published by jewettaij over 5 years ago

moltemplate - COMPASS bug fix

fixed a bug in COMPASS and "msifrc2lt.py" causing low priority dihedrals and impropers to occasionally override high priority ones

- Python
Published by jewettaij over 5 years ago

moltemplate - infrastructure, regex, COMPASS improvements

Summary: This release contains infrastructure improvements for parsing text, as well as bug fixes for the COMPASS force field as well as the "msifrc2lt.py" converter script.

Infrastructure:
1) Greater consistency with the way wildcards and regular expressions are handled. All rules for generating angles, dihedrals, impropers, and looking up bond types and charge-by-bonds, as well as all paircoeff, bondcoeff, anglecoeff, dihedralcoeff, and improper_coeffs can accept wildcards and regular expressions (eg "@atom:re.c[1-6]") . (NOTE: Regular expressions have not been tested yet, but the infrastructure for supporting them is finally there.) 2) Counter variables ($ and @) can no longer contain , or () characters. (In the future, this will make it much easier to create source code for programming languages. Note to self: The +-=/. characters are still allowed. The / and . characters are used for path resolution and should never be forbidden.)

COMPASS: The "msifrc2lt.py" script has been (hopefully) fixed and is now able to convert the COMPASS force field files again. This made it possible to fix 2 bugs in the "compass_published.lt" force field file: 1) wildcards are now given low priority instead of high priority, and 2) non-hybrid bond, angle, dihedral, improper, and pair styles are used by default (for KOKKOS compatibility). Also: Commas were removed from the atom type names (and replaced with ~ characters).

- Python
Published by jewettaij over 5 years ago