The MBAR Reweighting Layer
ReweightingLayer is a calculation layer which employs the Multistate Bennett Acceptance Ratio (MBAR) method to calculate observables at states which have
not been previously simulated, but for which simulations have been previously run at similar states and their data
cached. It inherits the
WorkflowCalculationLayer base layer, and primarily makes use of the built-in
workflow engine to perform the required calculations.
Because MBAR is a technique which reprocesses exisiting simulation data rather than re-running new simulations, it is typically several fold faster than the simulation layer provided it has cached simulation data (made accessible via a storage backend) available. Any properties for which the required data (see Calculation Schema) is not available will be skipped.
The theory behind applying MBAR to reweighting observables from a simulated state to an unsimulated state is covered in detail in the publication Configuration-Sampling-Based Surrogate Models for Rapid Parameterization of Non-Bonded Interactions.
The reweighting layer will be provided with one
ReweightingSchema per type of property that it is being requested to
estimate. It builds off of the base
WorkflowCalculationSchema schema providing an additional
storage_queries attribute will contain a dictionary of
SimulationDataQuery which will be used by the layer to
access the data required for each property from the storage backend. Each key in this dictionary will correspond to the
key of a piece of metadata made available to the property workflows.
The reweighting layer makes available the default metadata provided by the parent workflow layer in addition to any cached data retrieved via the schemas
When building the metadata for each property, a copy of the query will be made and any of the supported attributes
substance) whose values are set as
PlaceholderValue objects will have their values updated
using values directly from the property. This query will then be passed to the storage backend to retrieve any matching
The matching data will be stored as a list of tuples of the form:
(object_path, data_directory, force_field_path)
object_path is the file path to the stored dataclass, the
data_directory is the file path to the ancillary
data directory and
force_field_path is the file path to the force field parameters which were used to generate the
This list of tuples will be made available as metadata under the key that was associated with the query.