molssi / eex Goto Github PK

The current amber writer counts the dihedrals as they are stored in the datalayer. As Amber only supports charmm dihedrals, we need to now how many equivalent charmm dihedrals (both types and actual dihedrals) are stored in the datalayer. Additionally, we need to distinguish among those dihedrals that contain hydrogens and those that don't.

We do not currently read or write information on improper torsions for amber.

From amber documentation (http://ambermd.org/prmtop.pdf):

Information about improper torsions is stored in DIHEDRALS_INC_HYDROGEN and DIHEDRALS_WITHOUT_HYDROGEN section.

"If the fourth atom is negative, then the torsion is improper."

Currently atom indices are stored in the datalayer with the negative sign discarded. It's not immediately clear why it is stored this way, or if amber actually reads this information....

There is currently no way to specify periodicity of simulation system in datalayer, and no way to store information about non rectangular boxes.

Use lgtm to clean up EEX

The way to call a function for these functional form conversion in convert_form.py (and also the mixing rule application in nb_converter.py and the NB functional form conversion in nb_converter.py) is currently being done in an ad-hoc manner (assembling the function name and calling it by string). The current version is probably not very robust. Maybe we need to find a way to make this more elegant.

The EEX readme should be expanded (written)

Jupyter notebook examples do not work after port from old repository. Jupyter notebook testing should be incorporated in tests.

Write a function that returns the compatible functional forms for a given functional form when translating. This should be placed in md_helper to be useable among all modules.

We have previously added a remove_terms function in the datalayer which allows for terms to removed from the datalayer. The motivation for the addition of this function was to allow terms to be removed and replaced during conversion from one file type to another.

A copy function for the datalayer could be useful so that the original datalayer object remains unchanged and is not overwritten. I believe this can be compared to pandas, where actions are performed on a copy of a datalayer unless inplace=True is set.

Using deepcopy will not work for HDF5 backend (but is fine for memory backend), so copy function should be added to datalayer (information in file layer and datalayer will have to be copied).

Note: Pandas dataframes and hdf5 both have copy functions

PR #12 adds a way of wrapping dihedral, angle, bond converters. Could we also include the NBs here?

New terms are not added to the datalayer after initial terms are added for a particular order for the HDF5 backend.

Will need to clean up docstrings at some point -

Add testing docstrings

pytest --doctest-module

The internal metadata for the mixing rule is duplicated in nb_converter.py and additional_metadata.py.

Note also that the function set_mixing_rule in datalayer.py uses the dict defined nb_converter.py as metadata.

We need to define the mixing metadata only in one place (probably in additional_metadata.py). Then, we might need to automatically map functions in nb_converter.py to the metadata keywords.

When running test_compare_alkanes.py from lammps to amber, the resulting amber topology file doesn't output NB parameters. Any idea @janash?

We agreed that all inputs to datalayer functions should be dictionaries, but some functions still accept list/tuples.

The convert_form function returns a dictionary of integers except. There are some exceptions:

1. If attempting X-->charmm, the resulting conversion is a dict of vectors.
2. If attempting charmm-->charmm, the resulting conversion is a dict of ints.

In general, we might want to return always vectors?