Add results from the openmm840 qa#117
Conversation
| date: 2026-03-18 | ||
|
|
||
| # REQUIRED: OpenFE version used to produce the gathered reports | ||
| openfe_version: 1.8.0 |
There was a problem hiding this comment.
Am I correct in remembering that we would put the full environment file on zenodo? Would it still make sense to have a few key entries here like openmm version and the openff toolkit version?
| # REQUIRED: license for the submission (e.g. CC-BY-4.0) | ||
| license: CC-BY-4.0 | ||
|
|
||
| # RECOMMENDED / OPTIONAL metadata |
There was a problem hiding this comment.
Should we add extra experiment data here? Like the FEP method used, simulation length, number of repeats, etc...
|
TODO:
|
jaclark5
left a comment
jaclark5
left a comment
There was a problem hiding this comment.
Here are some suggested changes to be consistent between the submission.yaml and the prepare_metadata_submission.py
|
Update _example_plan_rbfe.py to make sure that the "system_name" and "system_group" are saved in the mapping annotations. |
|
I think I updated everything according to the meeting today.
|
This should be resolved |
|
|
||
| qualname = payload.get("__qualname__") | ||
| if qualname == "AlchemicalArchive": | ||
| archive_obj = payload | ||
| elif qualname == "AlchemicalNetwork": | ||
| network_obj = payload |
There was a problem hiding this comment.
This script looks great, but how do we feel about working with the keychain dicts? would it be better to deseralise the objects and use the API to interagate them when extracting the information that would be my personal preference.
| # RECOMMENDED / OPTIONAL metadata for protocol settings | ||
| protocol_settings: | ||
| - protocol: RelativeHybridTopologyProtocol | ||
| count: 3 |
There was a problem hiding this comment.
How should this work when a network contains a mix of protocol settings will the networks be listed under both protocols?
| names = [trans.name for trans in _transformation_refs(network_obj, mode)] | ||
| if names: | ||
| # !!!! NoteHere !!! what is hard coded to detect calculation type? | ||
| if any(n.startswith("complex_") or n.startswith("solvent_") for n in names): | ||
| return "rbfe" | ||
| return "asfe" |
There was a problem hiding this comment.
Checking the protocol type on the transformation would be safer.
| openmm_version: TODO | ||
| openff_toolkit_version: TODO | ||
| mapper: "KartografAtomMapper 1.2.0 (LSA)" | ||
| forcefield: ["ff14SB", "phosaa10", "tip3p_HFE_multivalent", "tip3p_standard"] |
There was a problem hiding this comment.
This is listed here and in the protocol settings is this the searchable tag? If so we probably want the small molecule forcefield here as well.
There was a problem hiding this comment.
Or is the tags list intended to be the searchable keys?
| This submission describes the charge_annihilation_set, jacs_set RBFE benchmark | ||
| (charge_annihilation_set: egfr, irak4_s2, irak4_s3; jacs_set: p38, tyk2) prepared with | ||
| tip3p_HFE_multivalent/ff14SB/phosaa10/tip3p_standard and am1bcc_at. The submission contains 160 | ||
| edges, 45 unique ligands, and 1 unique proteins. Note this means the charge annihilation sets are |
There was a problem hiding this comment.
1 unique proteins
This is wrong
| summary: | | ||
| This submission describes the charge_annihilation_set, jacs_set RBFE benchmark | ||
| (charge_annihilation_set: egfr, irak4_s2, irak4_s3; jacs_set: p38, tyk2) prepared with | ||
| tip3p_HFE_multivalent/ff14SB/phosaa10/tip3p_standard and am1bcc_at. The submission contains 160 |
There was a problem hiding this comment.
Force fields are listed again but not the small molecule force field or charges.
3 participants
A draft of the results object from a local qa run of openmm-8.4.0.