ahy3nz / commpare Goto Github PK

A lot of the tests have force field/model parameters that aren't understood when converting into ParmEd, and also a lot of parameter information that isn't understood when converting out of ParmEd, and this will throw a bunch of errors. It would be good to somehow catch a list of all these problematic systems while still chugging along the rest of the unit tests

• We have a lot of structure/chemical formulas as reference systems
• We will soon have access to multiple general force fields (OPLS and GAFF) for atomtyping and parametrization

We need a somewhat-elegant and flexible way to test all these possible combinations. My first thought is just using it.product within mm_tests/mosdef_inputs to build + atomtype/parametrize all the different permutations and then shoot them all off to different engines

If simulation run parameters are needed, we need long range treatments across engines as consistent as possible. That could be in places like the run scripts, build-run-measure routines, or the xml that creates the parmed/openmm objects

Missing anything?

Too much hoomd status updating, need to quiet status updates

https://github.com/gromacs/gromacs/tree/master/python_packaging/test

As an example for using gmxapi

As more engines get incorporated, it's unlikely a single user will have every engine locally available. Pulling down a docker image would make every engine available

These should hopefully be the "easy" tests, having various mbuild compounds, foyer atomtype with oplsaa, and then do some energy comparisons. This way we don't have to deal with the turbulence of convering into parmed, just converting out of parmed