You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An undocumented feature allows access to the object providing MD extension code by exposing an array of the plugins in a simulation through the Python gmx.Context. (This is one reason we haven't allowed multiple simulations in a graph yet.)
Registered plugins appear in the array in the order in which they were added as dependencies to the MD simulation operation, but there is not a good way to map between the name given to an operation and the element in the list.
Workaround:
Keep track of the order in which plugin WorkElements are passed to add_dependency
Add bindings in the plugin for the name in the restraint object.
Reported as a result of conversation with @jmhays. Please post if there are updates or corrections. Feel free to comment about urgency and workarounds.
An undocumented feature allows access to the object providing MD extension code by exposing an array of the plugins in a simulation through the Python gmx.Context. (This is one reason we haven't allowed multiple simulations in a graph yet.)
Registered plugins appear in the array in the order in which they were added as dependencies to the MD simulation operation, but there is not a good way to map between the name given to an operation and the element in the list.
Workaround:
add_dependency
name
in the restraint object.Planned solutions:
The text was updated successfully, but these errors were encountered: