Closed ahy3nz closed 2 years ago
In the context of that PR I would rather have it merged as is, or after whatever fixes you want to the current behavior.
But more generally, this will be tricky because of how different engines treat things. In my view - because this is how LAMMPS and GROMACS does things - the cutoff isn't a property of the topology but rather a setting for the input file and therefore outside the scope of this project.
By the way, what are alpha
/r_on
?
Okay i'll leave out anything specifying FF params in #47 - I could try to put in a GSD reader (or should this be a separate PR)?
https://hoomd-blue.readthedocs.io/en/stable/module-md-pair.html#hoomd.md.pair.lj For alpha/r_on
Should be a separate PR if you want to take a stab at it. I'm in favor of smaller PRs that take small steps over huge PRs that try to do everything at once (which I am often guilty of doing)
info included in forcefield class
For the gsd writer #47 , one next step is to write out all FF parameters to an external python module that can be called from the actual hoomd run script. For example:
force_field.py
run.py:
To move further and write
force_field.py
from aTopology
, we will need to account for these hoomd specifications (or smartly infer/guess):sigma
andepsilon
Other specifications, like the atom types or bond types are already accounted for inTopology