Legacy Release Notes

v2.5.3 March 2025

Bug Fixes

  • An issue has been fixed with enforcing atom ordering for Gromacs that caused the Solvation Cube to consume significantly more memory than expected.

  • An issue has been fixed where residues of nonprotein components were renumbered after simulations.

v2.5.2 March 2025

General Notice

The Delete MD Recovery Cube has been updated to use a less memory-intense protocol.

v2.5.1 February 2025

General Notice

Various aspects of Orion MD Core have been refactored and improved significantly in this version. Please note that some changes are unfortunately API-breaking, which may affect existing implementations. These changes are explicitly marked as (API-breaking) in the release notes below.

Cube Updates

  • The Solvation Cube has been updated as follows:

    • The default salt concentration has been increased to 150 mM from 50 mM.

    • The box size for small molecule is now determined considering the largest small molecule conformation along Omega sampling.

    • A new md_cutoff_distance cube parameter has been defined to ensure that the minimum image convention is always enforced along MD runs.

    • Ions in solutions are now placed far from the solute.

    • A new min_number_of_salt cube parameter has been defined to ensure that the selected minimum number of ions are always present in solution. This parameter has been introduced to ensure future charge corrections change ligand mutations along RBFE calculations.

  • (API-breaking) The Collection Setting Cube has been refactored to use a new parameter, collection_fields, to specify which collection will be set on the input record. Additionally, a new string parameter, operation, has been introduced to define the action to perform on the collection. Supported values for operation are "open", "close", and "create".

Major Improvements

  • Support has been added for storing the bond orders in trajectories generated by the MD cubes using OpenMM as the engine. Bond orders can be accessed in output trajectory files as follows:

    import mdtraj
    # NOTE: mdcore must be imported for bond orders to be recognized by mdtraj,
    # even if mdcore is not explicitly used
    import orionmdcore
    
    # load the trajectory from the last stage
    traj_file = md_record.get_state_trajectory()
    traj = mdtraj.load(traj_file)
    
    # check if bond orders are present
    for bond in traj.top.bonds:
        assert bond.order is not None
    
  • MDDataRecord has been improved in the following ways:

    • MDDataRecord now internally uses the link, as opposed to integer IDs, to reference MD data stored as Orion resources (e.g., shards and files). ID fields from old records are automatically upgraded to links once MDDataRecord is initialized.

    • MDDataRecord.get_value and MDDataRecord.set_value now return/expect Orion resources instead of links when dealing with link-type fields. For example:

      # generic record
      link_dict = record.get_value(MDFields.mddata)  # returns a link dict referencing the shard
      link = APISession.get_link(link_dict)
      shard = link.get_shard()
      
      record.set_value(MDFields.mddata, link)  # sets with a link referencing the shard
      
      # MDDataRecord
      md_record = MDDataRecord(record)
      shard = md_record.get_value(MDFields.mddata)  # returns the shard
      md_record.set_value(MDFields.mddata, shard)  # sets with the shard
      
    • Related utility functions and tools, including mdocli, have been refactored to support links stored on MDDataRecord.

    • A new function, get_stage, has been added to MDDataRecord that can be used to retrieve MD stages by either stage index or name.

    • MDDataRecord.get_stages and other MD stage getters now return an MDDataRecord instead of a generic record.

    • (API-breaking) The input parameter of MDDataRecord.get_stage_by_name, MDDataRecord.has_stage_name, and MDDataRecord.delete_stage_by_name has been renamed from stg_name to name for improved clarity and simplicity. Additionally, the parameter can now be provided as either a positional or keyword argument. For example:

      stage = md_record.get_stage_by_name("production")  # stage name as positional argument
      stage = md_record.get_stage_by_name(name="production")  # stage name as keyword argument
      
    • (API-breaking) The input parameter of the several member functions of MDDataRecord related to getting and setting the MD stage data has been changed such that the user can provide either the name or the index of the stage. The name of the parameter has been changed from stg_name to stage_id to reflect this new capability. Additionally, the parameter can now be provided as either a positional or keyword argument. For example:

      traj_file = md_record.get_stage_trajectory("production")  # stage name as positional argument
      traj_file = md_record.get_stage_trajectory(stage_id="production")  # stage name as keyword argument
      traj_file = md_record.get_stage_trajectory(-1)  # stage index as positional argument
      traj_file = md_record.get_stage_trajectory(stage_id=-1)  # stage index as keyword argument
      
  • Atoms in all components except for ligand and other_ligands are now reordered in MDComponents to enforce and satisfy the requirements for GROMACS topology. This should allow systems that were previously failing in GROMACS to be successfully simulated.

  • A new property, designunit, has been added to MDComponents for converting and retrieving an OEDesignUnit object from MDComponents.

Minor Improvements

  • Package dependencies have been updated to include the latest versions.

  • The use_gpu_cpu option in the OpenMMSimulations class has been renamed to "use_gpu" and changed to take Boolean values.

  • A precision option has been added to the OpenMMSimulations class, allowing users to specify the numerical precision for simulations when using the GPU. Supported values for this option are "single", "double", "mixed", and "auto". If precision="auto", the simulation defaults to mixed precision when available; otherwise, it falls back to single precision. The default value is "mixed", which requires mixed precision (i.e., fails when mixed precision is unavailable).

Bug Fixes

  • A rounding error has been fixed when calculating the total number of steps in MD runs.

  • An issue has been fixed that can lead to memory leaks when deserializing MDComponents from a record.

  • A bug has been fixed in the Delete MD Recovery Cube that could cause a deadlock.

  • An issue has been fixed where no record is emitted from NVT/NPT cubes when the simulation runtime is zero.

  • Various smaller bugs have been fixed.

v2.4.1 June 2024

This patch adds support for the Sage 2.2.0 small molecule force field from Open Force Field.

Cube Updates

  • The default Ligand Force Field is now “OpenFF_2.2.0”.

Bug Fixes

  • Improved input validation for the restraintWt parameter.

v2.4.0 April 2024

Cube Updates

  • The CollectionSetting Cube now creates V2 ShardCollections by default. This behavior is controlled by the new V2 switch, which defaults to On.

  • Cubes that need to run OpenMM on a GPU now print a more informative error message when no GPU platform is available.

  • The IterChecker Cube no longer deletes the per-iteration MD stages (cycle_0, cycle_1, etc.) after concatenating them. This task has been delegated to the new DeleteMDStagesCube.

Bug Fixes

  • Cubes no longer attempt to load the reference positions when the Restraint to Reference switch is turned Off.

General Notice

The package distribution now includes both the orionmdcore and oeommtools Python packages (oeommtools was released separately in a previous release).

v2.3.1 February 2024

API-Breaking Changes

  • The default value for the ForceFieldCube.ligand_forcefield parameter has been changed from “Gaff_1.81” to “OpenFF_2.0.0”.

New Features

  • The ForceFieldCube.ligand_forcefield parameter has a new “Custom” value. When this value is selected, the ligand force field is defined by inputting one or more SMIRNOFF XML files via the custom_offxml_file_in parameter.

  • When the ligand_forcefield is set to “Custom”, “OpenFF_1.3.1”, or “OpenFF_2.0.0”, and the new prefer_bespoke switch is turned On (the default), the force field can be augmented with bespoke parameters by providing them in the field specified by the bespoke_forcefield_field parameter. This field accepts a list of SMIRNOFF XML strings.

  • The new SolvationCube.random_seed_from_system_time parameter specifies whether Packmol should generate its random seed from the system time. The default (and historical) behavior is to use Packmol’s fixed default seed.

  • Residue numbers in the output topology now match those in the input design unit or molecule.

Bug Fixes

  • A bug in which the IterMDNptCube could schedule a cycle of zero length has been fixed.

General Notice

This version of Orion MD Core has more flexible requirements:

>>> from importlib.metadata import metadata, requires
>>> metadata("openeye-orionmdcore")["Requires-Python"]
'>=3.9'
>>> requires("openeye-orionmdcore")
['click <9,>=8.1.3',
 'h5py <4,>=3.1.0',
 'lxml <5,>=4.6.0',
 'mdtraj <2,>=1.9.6',
 'numpy <2,>=1.21.2',
 'oeommtools <2,>=1.2.1',
 'openeye-orionplatform <7,>=5.1.1',
 'openeye-snowball <0.28,>=0.26.0',
 'openeye-toolkits >=2023.2.3',
 'openff-toolkit <0.15,>=0.14.4',
 'openmm <8.1,>=7.7.0',
 'openmoltools ==0.8.8',
 'parmed ==3.4.4',
 'pdbfixer <2,>=1.8.1',
 'pyparsing <3,>=2.4.7',
 'tqdm <5,>=4.57.0']

v2.1.2 September 2023

Warning

This version reintroduces a bug, fixed in version 2.1.1, in which the IterChecker cube incorrectly records the combined simulation time as the time of the last stage. Furthermore, while version 2.1.1 requires oeommtools==1.2.*, this version requires oeommtools==1.2.0. Hence it is unable to leverage new features in oeommtools 1.2.1, including the retention of residue numbers when converting from an OEMol to an OpenMM topology. These issues are fixed in version 2.3.1.

Bug Fixes

  • Support has been added for systems containing iron and other metal cofactors, which previously failed during force field assignment.

v2.1.1 September 2023

New Features

  • A new cube type, Parallel Iteration Checker Cube was added to enable scalability of the (serial) Iteration Checker Cube.

v2.1.0 July 2023

General Notice

  • This version v2.1.0 pins Python 3.9 and OpenMM 7.7.

  • Minor bug fixes have been made.

Cube Updates

  • In the Solvation Cube, the “geometry” parameter name has been changed to “Periodic Box shape”. The parameter offers two options: a “cubic” or “rectangular” periodic box.

  • The Iterative NPT Cube has a better way of setting trajectory intervals for long simulations (>= 10 ns).

  • The Ligand Charge Cube now supports ELF10 charge assignment of macrocycles.

v2.0.1 April 2023

General Notice

  • Since the first MD pkg release, we have been using Pickle to serialize and deserialize MD custom objects passed along the OpenEye data records. A main side effect of pickling them is that the class objects API is embedded inside the produced dataset. Therefore, updating the object APIs could generate issues. To overcome the problem, all the MD custom objects are now using JSON serialization and deserialization, which does not have this side effect. To avoid compatibility problems, in this release both serializers (pickle and JSON) are supported. However, the support for pickle will be dropped in future releases, and only the JSON serializer will be kept. The MDAPIDatasetConverterCube can be used to convert old datasets into new datasets where the JSON serializer/deserializer is used.

New Cubes

  • Iterative NPT Cube. This cube performs NPT MD simulations in the cyclic MD Floe (Plain MD Floe) on the provided system. If the MD cycle is complete, the cube emits the record to the “success” port and if not, it emits the record to the “cycle_out_port” port.

  • Iteration Checker Cube. This cube checks if the MD cycle is complete. If the MD cycle is complete, it emits the record to the “true” output port, and if not, it emits the record to the “false” output port.

Cube Updates

  • The MDAPIDatasetConverterCube has been updated to support the conversion from old pickle datasets to the new JSON serializer/deserializer

  • The ComplexPrepCube has been updated to raise a fatal error if the protein cannot been found.

v1.1.6 June 2022

General Notice

  • Add new Cube for checking the wall clock time of production runs

  • G4/G5 AWS instances support for OpenMM/GROMACS

  • Minor bug fixing

New Cubes

  • MDSpeedChecker Cube. This Cube estimates the wall clock time a production run will require and if the estimated time exceeds the 12 hour time limit, the Cube will fail the job.

Cube Updates

  • All Cubes have been updated for improved exception handling.

v1.1.5 April 2022

General Notice

  • New Cubes for Long Trajectory MD support; these are Cubes to enable iterative Floes.

  • Package dependencies update

  • Minor bug fixing

New Cubes

  • MDProxyCube. The MD Proxy Cube runs chunks of MD simulations in cycles till the desired total MD running time has been reached

  • MDRecoveryRestartProxyCube. This Cube is able to restart or recover a previously run long MD simulation. It is used in association with the MD proxy cube.

Cube Updates

  • All the MD Cubes are by default pinning g3 spot instances to improve reliability.

v1.1.2 December 2021

General Notice

  • Better Implicit Solvent Support

  • Add CPU support to OpenMM and Gromax

  • Add HMR support to Gromax

New Cubes

  • MDAPIDatasetConverterCube

Cube Updates

  • All the MD cubes have been updated to support Implicit Solvent simulations