Best way to update positions and velocities for an OpenFF Interchange?

[orionarcher]

I'd like to update an interchange with positions and trajectories from an OpenMM simulation. Something like:

# interchange and opemm_simulation already in scope

openmm_state = openmm_simulation.context.getState(
    getPositions=True,
    getVelocities=True,
    enforcePeriodicBox=self.wrap_dcd,
)
interchange.positions = openmm_state.getPositions(asNumpy=True)
interchange.velocities = openmm_state.getVelocities(asNumpy=True)

Will this cause any errors or issues downstream? I am nervous about units or writing the interchange back to OpenMM or another platform.

[mattwthompson]

(I've transferred this from bespokefit/discussions to our general discussions repo since it appears to be a more general question)

Without having tried all of the ways to digest results from OpenMM, this should be fine. There is some magic under the hood that's meant to, if it sees OpenMM Quantity objects, convert everything through to the right type. The sorts of things I would check, for each attribute, are

• Is the right type?
• Are they in the correct units? If asNumpy=True or something similar strips units, unitless arrays are interpreted with some default units
• Do the arrays have the right shape?
• Are some of the values numerically the same as what's stored in OpenMM?

In general, errors should be loud (if all positions are silently converted between nanometers and Angstroms, the crash should be rapid and violent).

We have ensure_quantity that's meant to be a possible added safeguard here or in cases in which you might want to do a conversion before passing an array around: https://github.com/openforcefield/openff-units?tab=readme-ov-file#dealing-with-multiple-unit-packages: https://github.com/openforcefield/openff-units?tab=readme-ov-file#dealing-with-multiple-unit-packages

(Extra caveat - you mentioned forces, which aren't explicitly stored anywhere in our infrastructure since, ironically, forces themselves don't enter the picture until long after force field world has quieted down. If it's in principle just another unit-bearing Nx3 array, we'd think about adding it in somewhere - velocities are already implemented with just 1 LOC.)

All this being said - if something looks off, it could certainly be a bug & I'll have a closer look.

[orionarcher]

Thanks Matt! That's a very helpful sanity check.

I will implement some testing aligned with your suggestions and let you know if anything looks funky.

[mrshirts]

I'm suspicious about adding forces, since one would have to check that they are consistent with the force field definitions - which I don't think is within OpenFF representations scope. I would say the force is what the MD engine says it is, and leave OpenFF toolkits out of the whole argument :)

[orionarcher]

Apologies, I realize I wrote "forces" in the title when I meant "positions," now corrected. The current behavior fully covers my use case.