-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More thorough unit tests for non-Parmed writers #217
Comments
This issue has been partially addressed, but we could still use more thorough unit testing. I'm thinking it would be nice to have some single point energy tests to make sure we're getting consistent results from all three writers. We could maybe get some inspiration from unit tests used by ParmEd and Intermol. |
Just curious, what kind of energy tests were you thinking? Since we're constructing compounds in 'code' and then writing them for a particular MD engine, it's not like we can compare before and after. If it were converting from MD engine to MD engine, we'd have the same system with the same force field, but just converted to fit the MD engine's form. If this were an mBuild compound, it's not like we could evaluate the bond energies of an mB compound (no force field) and compare it to the output gsd/hoomdxl/gro/lammps compound's bond energies (with a force field applied) |
I was thinking something along the lines of what I did locally to test the GSD writer, which would basically be:
We could even check against some of the ParmEd writers as well. We would probably want to check a few different systems with different force fields. One problem with this approach would be figuring out how to get the tests to run on Travis because we would need to access the LAMMPS binary (and GROMACS or whatever other engines from the ParmEd writers we want to test). We might be able to create a LAMMPS package within our conda channel similar to how omnia hosts several PACKMOL versions, but I'm not sure about that. |
These would not be exclusively mBuild tests, but tests of the full workflow of mBuild + Foyer + either ParmEd or mBuild for writing. However, I think these fit better within mBuild then Foyer. |
Not sure if these are mature enough yet but eventually I think this will be the way to go: |
Also for actually evaluating energies, these scripts may be a good starting point: MolSSI is also working on a fully fledged replacement for InterMol/the conversion part of ParmEd. Don't think they're quite there yet but they're building off of some of that code: |
And last but not least: https://www.biorxiv.org/content/biorxiv/early/2018/04/22/306043.full.pdf |
I think comparing identical, static structures is a good idea (as opposed to comparing the averages from MD runs and doing the "physical validation" stuff...that is something we should think about long term though). In reality, if the goal is to just test the writers, we could feed it any arbitrary set of particles/parameters to make sure things are being parsed correctly. For these types of tests, we should actually think about doing something similar to how we derive forcefield parameters. E.g., calculate the tosional energy landscape by spinning a molecule around a bond or stretch a bond out and see how the various components to the energy change. That is, not rely on a single configuration, but also look at a series of configurations to ensure the trends are as expected. I definitely agree with Christoph about using docker for the simulation engines. |
👍 to the idea of using Docker for LAMMPS and Gromacs. I still don't know much about how to actually use Docker, so this might be a good time to get started. I'll have to look over those packages you linked @ctk3b . At first glance, they appear to maybe be a bit more involved than we need for just single point energy calculations, but if this is something we can take advantage of then no need to reinvent the wheel. The Gromacs Python API is something I've been meaning to check out for awhile, so I'll look into that, could be useful here. And right, @chrisiacovella, I wasn't thinking of anything as involved as the whole physical validation package. Just some single point energies to validate that for an atomtyped compound (really a parametrized ParmEd |
As long as you're running tests on structures with more than a handful of atoms, this is the only test required to validate your writers. If you want to be extra sure, you can readily achieve this:
by building a system that has a handful of molecules and running a few steps of equilibration to get a sampling of different realistic configurations.
Yeah I don't think you need to use most of the packages but I would advocate against re-inventing the wheel that "runs a single point energy calc and parses the output into a canonical form". That being said, none of these packages thus far provide scripts that cover LAMMPS, HOOMD and GROMACS which is what you're probably after. Might make sense to start a little utility library that simply lets you run ^ this is what we recommended to the EEX developers as well but I don't think they'll get to all the packages you're interested in in the near future. |
👍 I like this idea for an approach. And then we can basically just parametrize a unit test to look at different structures and engines. |
Just wanted to add that LAMMPS is available on conda-forge and bioconda maintains a version of GROMACS (not that this conda is necessarily an easy way to go for this problem). https://anaconda.org/conda-forge/lammps |
As we're moving away from ParmED, the writers here become less relevant. |
Current unit tests for writers that don't go through Parmed (lammps, hoomdxml, and soon gsd) test only that files are written without error. More thorough tests that check to make sure the expected sections are present (and contain the expected number of atoms, bonds, etc.) should probably be included.
The text was updated successfully, but these errors were encountered: