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

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

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!

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!

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.

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 "cleanup_moltemplate.sh" script can also handle files with names that do not begin with "system" (by including the "-base" argument).
• The "cleanup_moltemplate.sh" script no longer assumes that the python interpreter is named "python". (It could be named "python" or "python2".)

bugfixes for cleanup_moltemplate.sh and several OPLS water models

1. I fixed an edge-case bug causing "cleanup_moltemplate.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 "cleanup_moltemplate.sh" afterwards. (This is a situation that "cleanup_moltemplate.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 "spc_oplsaa.lt" and "tip3p_oplsaa.lt" files (for the SPC and TIP3P water models). Thanks to github user feifzhou for pointing them out!

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!

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

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