Desmond cms file

[Sirish Lakkaraju]

I am trying to read in a Desmond cms file to run an MD simulation in OpenMM. I could only find this class : DesmondDMSFile. But when I try to read in CMS file using this class constructor, I bump into the following error :

sqlite3.DatabaseError: file is encrypted or is not a database

Since, CMS is a newer format to define a Desmond-prepared system compared to DMS, is there any other way I can read in the CMS file and run MD from here?

Thanks,
Kaushik

[Emilio Galllicchio]

A .cms file can be converted to a .dms file using the mae2dms application distributed with Maestro/Desmond. (However, note that versions after 2013.3 do not appear to have this converter.) Note also that .cms files generated by Maestro include OPLS parameters, whereas the default DesmondDMSFile class implicitly assumes Amber combining rules.

A modified DesmondDMSFile class capable of handling the OPLS force field is available here:
https://github.com/egallicc/openmm_agbn ... dmsfile.py

[Peter Eastman]

A CMS reader would be a nice addition, if anyone wants to write one!

[Sirish Lakkaraju]

Thank you Emilio. Motivation to work with Desmond comes from its capability of supplying ligand topology and parameters. Thank you for the note on the limitations of the DMS. That makes it less attractive.

Although this may seem a circuitous way, I am exploring converting the cms first into gromacs top/gro using :

https://github.com/shirtsgroup/InterMol

Once we have this gmx top/gro, then proceeding from there.

Does anyone see a blatant problem with doing so?

@Peter, I may actually end up writing the CMS reader if thats the way to go.

Thanks,
Kaushik

[Peter Eastman]

Does anyone see a blatant problem with doing so?

Hopefully it will work, though I can't guarantee it. OpenMM's TOP file reader only supports a subset of the features in Gromacs. It depends whether the converted file uses any features that aren't supported. But adding support for new features is usually pretty easy, and mostly driven by user requests. So if you try it and it complains that something isn't supported, I'm happy to look into adding it.

@Peter, I may actually end up writing the CMS reader if thats the way to go.

That would be great!

[Emilio Galllicchio]

Thank you Emilio. Motivation to work with Desmond comes from its capability of supplying ligand topology and parameters. Thank you for the note on the limitations of the DMS. That makes it less attractive.

I think the DMS format is superior to the CMS format. Mostly because it can be accessed in a structured way using standard SQL commands.

I agree, DMS it is great for storing coordinates together with the topology and the force field parameters + anything else one desires.

The issue with OPLS is due to the default OpenMM behavior of using internally Amber combining rules. It has nothing to do with the DMS format. In fact, DMS can store tables with specific force field information, such as combining rules, to ensure portability.

Perhaps we could coordinate? If you write a CMS i/o module for parmed, we pledge to do the same for DMS.

[Peter Eastman]

If the problem is just in the OpenMM DMS importer, let's fix that. Other combining rules aren't a problem. We already do that for CHARMM, for example.

[Emilio Galllicchio]

If the problem is just in the OpenMM DMS importer, let's fix that. Other combining rules aren't a problem. We already do that for CHARMM, for example.

I will submit a pull request to add OPLS capability to DesmondDMSFile.

However, the larger issue I think is that there is a lack of tools to prepare and store molecular systems in DMS format. Because the force field parameters (and, to an extent, the force field functional form and simulation settings) are stored together with coordinates, velocities, and topology, the system definition is protected from external changes. The format can easily store additional forces as well. For example, we store such things as restraining forces, alchemical states, and implicit solvent parameters in custom tables.

Anyway, this issue is probably not directly an OpenMM issue. Nevertheless, the DMS format plays very well with the design of OpenMM and it would be nice to see it more widely adopted.

[Sirish Lakkaraju]

Just a quick update : converting the Desmond CMS to Gromacs top/gro using InterMol as mentioned above and then making use of the OpenMM's GromacasTopologyFile works okay. Its roundabout, but works. I am validating energies just to be doubly-sure but if simulation trajectories are to go by, this holds up fine.