ptc-cmc / mccabegroup Goto Github PK

Molecule folders should have itp files for gromacs simulations

Tabulated potentials were originally:
1 distance unit = 6 angstroms
1 energy unit = 0.1 kcal/mol
1 force unit = 1 energy unit/1 distance unit

Currently, generation of a bilayer sets bilayer cross-sectional area based on calculating the "bounding box" of the lipids in the leaflet. Thus, when lipids are long and highly tilted, the actual area per lipid is significantly larger than the nominal value set. Furthermore, this void space is increased upon mirroring the leaflet; for my tests with CER AP, this results in unstable bilayers.

I'm working on a fix in my branch.

The way the files are now, setting up bilayers in gromacs will throw warnings because the atom names in the gro files do not agree with the atom names in the ITP file. This is okay because the ITP atom types are fine, so at the end of the day the simulations should run correctly by ignoring these warnings.

The solution would just be to rename in the first field in each .mol2 line to match the atom names in the ITP files (the second atom field in the ITP file should match the first fieeld in the `mol2 file)

The FFA topologies from Tim use nrexcl=2 - in doing so, there's no need to enumerate a [ pairs ] section. ParmEd isn't able to interpret nrexcl=2, only nrexcl=3. I'm working on a PR that changes the FFA itp files to use nrexcl=3 and specifies a [ pairs ] directive. If we can do this, then we can very easily use parmed to read gromacs files and then run a simulation in openmm

This is sort of related to #16.
I'm converting gromacs to parametrized lammps files via foyer (scripts/gmx_to_lmps.py). Briefly, a new mbuild compound is created (in order to preserve the hierarchy for residue naming further down the line), but then coordinates are updated from a specified file. This compound is converted to a parmed structure, where every atom name is turned into a custom element via the "_" convention (this part is important). Atomtypes and forcefield objects are generated via the ff.xml files. It is important to note that all the classes/types/elements in the ff.xml files are based off the actual atomtypes, not the atomnames.
Here's where the conflict occurs, because the ForceField object only knows the non_element_types as the atomtypes, there end up being many conflicts because the Structure atoms are based on the atomnames because that is how we named them in the mbuild python file.
@chrisiacovella i'm tagging you because this is sort of a design decision we need to make here. Do we keep the gromacs atomnames in the mol2 files for the mbuild python modules? If we do, then we'll either have to (1) adjust the gmx->lmp conversion workflow to rename all the mb.Compound and pmd.Structure atoms to be based on their atomtypes, not the atomnames as specified in the gmx itp or mol2 files [might be hard] (2) modify the ff.xml files to account for every possible atom name and relate all atom names to their underlying atomtypes [definitely hard] (3) we could revert the mol2 names back to the atomtypes so this gmx -> foyer -> lmp workflow still functions (I know this conversion code worked before the #16 update)

Some old codes have angles.txt, bonds.txt, coords.txt,charges.txt, etc. These need to be readily converted into XML style

AP, NP, NS, EOS etc
ecer2, ucer3, etc