---
title: 'MuMMI: Multiscale ML Modeling Infrastructure'
url: https://www.emergentmind.com/topics/multiscale-machine-learned-modeling-infrastructure-mummi
type: topic
---

# MuMMI: Multiscale ML Modeling Infrastructure

Searching arXiv for recent MuMMI-related papers and closely related multiscale ML workflow work.
Multiscale Machine-Learned Modeling Infrastructure (MuMMI) denotes an ML-driven, ensemble-based multiscale molecular dynamics workflow system for coordinating very large numbers of simulations across scales and for using machine learning to connect those scales efficiently in biomolecular studies, especially RAS–RAF membrane interactions [2507.07352]. In the formulation described for Mini-MuMMI, MuMMI is a massively parallel multiscale workflow management infrastructure that can orchestrate thousands of molecular dynamics simulations operating at different timescales, spanning from millisecond to nanosecond [2507.07352]. Full MuMMI is described as a three-scale system coupling a continuum model, a coarse-grained Martini bead model, and an all-atom model, with adjacent scales dynamically coupled pairwise using machine learning; Mini-MuMMI is a curated, smaller, and portable realization that preserves the core workflow, dataflow, and control logic while omitting the macro model for simplicity [2507.07352]. A recurring theme across MuMMI-relevant work is that multiscale predictive workflows require explicit micro–macro consistency, learned coarse descriptors, conditional coarse-to-fine generation, and hybrid ML/physics coupling rather than purely black-box substitution of simulation [2208.10715].

## 1. Definition, scope, and naming

MuMMI, in the sense relevant here, stands for **Multiscale Machine-Learned Modeling Infrastructure** and refers to a multiscale workflow management infrastructure rather than a single ML architecture or a single simulation code [2507.07352]. Its central scientific motivation is that biologically important processes span spatial and temporal scales that no single monolithic simulation can cover efficiently: atomistic simulations provide detail but are too expensive for long timescales, whereas coarse-grained or continuum descriptions reach larger scales at reduced fidelity [2507.07352].

The current MuMMI configuration is framed around the problem: given two protein conformational states, A and B, find a sequence of conformational states connecting A to B [2507.07352]. The paper provides performance context for why this is difficult by direct simulation alone: a large all-atom simulation with 1.5 million atoms runs at about **14 ns/day** on recent GPUs, while even a coarse-grained version of the same system reaches only about **1 μs/day** on one NVIDIA V100, whereas important conformational changes often occur on **microsecond-to-millisecond** timescales [2507.07352]. MuMMI was therefore developed to bridge scales in time and length using multiscale simulation, use machine learning to define and sample a reduced latent representation of conformational space, and manage huge ensembles of simulations over large HPC systems with robust scheduling, allocation, and failure handling [2507.07352].

A common source of confusion is that the acronym “MuMMI” is used differently in other domains. In "Performance and Power Modeling and Prediction Using MuMMI and Ten Machine Learning Methods" [2011.06655], MuMMI explicitly means **Multiple Metrics Modeling Infrastructure**, an HPC performance/power modeling tool rather than the biomolecular multiscale workflow system. That usage is distinct and should not be conflated with the multiscale molecular-dynamics infrastructure discussed here [2011.06655].

This suggests that “MuMMI” is best treated as a context-dependent acronym. In biomolecular multiscale simulation, it refers to a machine-learned multiscale workflow system [2507.07352]; in HPC performance modeling, it refers to a multiple-metrics measurement and regression infrastructure [2011.06655].

## 2. Scientific framing and multiscale organization

MuMMI is organized around the premise that pathway discovery between endpoint conformational ensembles is more tractable as an ensemble workflow than as a few long trajectories [2507.07352]. Simulations representing states A and B are first generated manually by domain experts; frames from those simulations are then used to train an autoencoder that learns a reduced-dimensional latent space encoding the structural correlations of the endpoint states [2507.07352]. Once trained, MuMMI samples latent-space points likely to correspond to promising intermediate conformations, decodes those points into coarse-grained protein structures, and builds full coarse-grained simulation systems by adding membrane and solvent before running MD to test and refine those structures [2507.07352].

Full MuMMI is described as a **three-scale** system [2507.07352]. The scales summarized in the Mini-MuMMI paper are shown below.

| Scale | Role |
|---|---|
| Continuum model | Simulates milliseconds of time on a **1 μm² membrane** |
| Coarse-grained Martini bead model | Explores protein–lipid interactions |
| All-atom model | Captures specific interactions between lipids and proteins |

Adjacent scales are dynamically coupled **pairwise using machine learning** [2507.07352]. The paper describes two forms of coupling: forward coupling, in which the coarser scale chooses what to refine at the next finer scale, and backward coupling, in which finer-scale results improve the fidelity of the adjacent coarser model [2507.07352]. Mini-MuMMI omits the macro model used in full MuMMI to pre-equilibrate lipids around ML-generated protein structures, so it is a simplified subset of the full architecture rather than a redefinition of it [2507.07352].

A broader conceptual literature situates this design within the complementarity of machine learning and multiscale modeling. "Integrating Machine Learning and Multiscale Modeling: Perspectives, Challenges, and Opportunities in the Biological, Biomedical, and Behavioral Sciences" argues that multiscale modeling is needed for mechanism and emergence, while ML is needed for multimodal and multifidelity data fusion, dimensionality reduction, surrogate construction, and uncertainty-related tasks [1910.01258]. "Challenges and opportunities for machine learning in multiscale computational modeling" similarly distinguishes hierarchical and concurrent multiscale workflows and treats ML as surrogate, accelerator, and augmentation layer for cross-scale computation [2303.12261]. These papers do not describe MuMMI itself, but they provide a field-level rationale for why MuMMI adopts closed-loop coupling between simulation and learning [1910.01258; 2303.12261].

## 3. Workflow architecture and control structure

The Mini-MuMMI paper presents MuMMI’s architecture as a separation between an **application layer** and a **coordination layer** [2507.07352]. This separation is a central design choice: domain-specific workflow logic and scientific computation stay in the application layer, whereas scheduling, messaging, and execution control are handled in the coordination layer [2507.07352].

The application layer contains three sequential jobs: **Structure Generator (SG)**, `createsims`, and `CGAnalysis` [2507.07352]. The Structure Generator itself contains a **Sampler**, **Generator**, and **Validation module** [2507.07352]. The sampler selects novel latent-space points between A and B by interpolating between points encoded from those states and uses an on-the-fly feedback mechanism intended to balance exploration versus exploitation based on simulations already seen [2507.07352]. The generator decodes selected latent-space points back into coarse-grained structures using the decoder part of the autoencoder [2507.07352]. The validation module runs a short energy minimization in vacuum with GROMACS; if the resulting total energy is below a threshold, the generated CG structure is considered valid [2507.07352].

`createsims` is a Python script that transforms SG output into full MD-ready systems by adding water, salt, and an **8-component plasma membrane model**, using **insane** for membrane construction and performing energy minimization and equilibration with **GROMACS** [2507.07352]. `CGAnalysis` is another Python script that launches the coarse-grained MD simulation, performs in-situ analysis of the generated frames, and periodically writes feedback files to the filesystem [2507.07352]. Every \(X\) frames, where \(X\) is a tunable parameter, analysis procedures run and feedback files are emitted; these are later consumed by the sampler in SG [2507.07352].

The coordination layer comprises the **Workflow Manager (WM)**, **Maestro**, **Flux**, **RabbitMQ**, and filesystem-based data exchange for larger products [2507.07352]. The Workflow Manager decides which jobs to run and when; it requests new structures from SG, schedules `createsims` and `CGAnalysis` jobs when resources are available, and prioritizes simulations considered most useful for the optimization criterion [2507.07352]. The WM is highly configurable via **YAML configuration files**, and the paper states that users can add custom modes and job types [2507.07352]. **Maestro** provides workflow management, while **Flux** is used for scalable scheduling because schedulers like Slurm or IBM LSF had too many limitations at MuMMI’s scale [2507.07352].

The architecture therefore forms a closed-loop adaptive workflow: **latent-space sampling → structure generation → simulation setup → CG simulation + in-situ analysis → feedback → improved sampling** [2507.07352]. The paper also describes a slower outer loop at campaign level: a period of exploration under a fixed trained model is called a **round**, a campaign typically consists of **2 to 5 rounds**, and model retraining is currently manual and intermittent rather than online [2507.07352].

A plausible implication is that MuMMI’s most distinctive systems property is not merely multiscale simulation, but multiscale simulation with nested feedback loops operating at different timescales: fast online feedback via analysis files within a round, and slower manual latent-space model updates between rounds.

## 4. Machine learning mechanisms and cross-scale representations

The principal ML mechanism described in Mini-MuMMI is an **autoencoder-defined latent space** for protein structures [2507.07352]. The paper states that, in the demonstrated use case, the trained autoencoder produced a **32-dimensional latent space** [2507.07352]. This latent space serves as a reduced-dimensional representation encoding structural correlations in the endpoint ensembles and as the space from which candidate intermediate conformations are sampled [2507.07352]. The paper does not provide explicit formulas for the autoencoder loss, the sampler objective, or exploration/exploitation scoring functions [2507.07352].

The endpoint states are operationally defined using **CRD membrane distance** [2507.07352]. The paper specifies:
- **ensemble A:** CRD membrane distance \(\geq 4.2\) nm
- **ensemble B:** CRD membrane distance \(\leq 3.2\) nm

The CRD membrane distance is defined as the distance of the CRD domain from the plasma membrane center [2507.07352]. The latent-space model is trained from simulation ensembles corresponding to these two states, and the structure generator uses the learned latent representation to produce putative intermediates bridging them [2507.07352].

MuMMI’s ML role can be interpreted within a broader class of coarse-to-fine and closure-learning methods. "GANs and Closures: Micro-Macro Consistency in Multiscale Modeling" formalizes a related problem by decomposing the full state as
\[
Z=(X,Y),
\]
where \(Y\) are slow or coarse variables and \(X\) are remaining fast or fine variables, and by targeting the conditional distribution
\[
P(X\mid Y=y)
\]
as the key object for micro–macro consistency [2208.10715]. That paper is not a MuMMI infrastructure paper, but it studies lifting, conditional ensemble generation, and closure quantities in a way directly analogous to MuMMI-style needs for plausible fine-scale realizations conditioned on coarse descriptors [2208.10715]. Its definition of closure,
\[
B(z,\epsilon) = \int \mu_1(z,\phi_2)\,\nu_z^\epsilon(d\phi_2), \qquad
B(z)=\lim_{\epsilon\to 0} B(z,\epsilon),
\]
leading to the reduced equation
\[
\frac{d}{dt}\phi_1 = B(\phi_1),
\]
makes explicit the idea that reduced dynamics depend on conditional expectations over fine-scale equilibrium conditioned on coarse state [2208.10715].

This suggests that MuMMI’s latent-space sampling and candidate generation can be understood as one realization of a more general multiscale ML program: learn reduced coordinates that support efficient traversal of coarse configuration space, then reconstruct and validate fine-scale states through simulation. Mini-MuMMI demonstrates this logic operationally, although it does not formalize it with the conditional-probability notation of [2208.10715].

A further distinction is necessary between MuMMI as infrastructure and model-level multiscale ML architectures. "Machine Learning Multiscale Interactions" introduces the **Multiscale Structural Ensemble (MuSE)**, a hierarchical architecture for ML force fields that constructs coarse representations using **Soft Coarse-Graining Pooling (SCGP)** and fuses multiscale embeddings back at atomistic resolution [2605.25710]. MuSE is explicitly architecture-agnostic and compatible with SO3krates, MACE, and PaiNN, but it does **not** describe workflow orchestration, job scheduling, adaptive campaign management, or a multisimulator ecosystem [2605.25710]. MuMMI and MuSE therefore operate at different layers: MuMMI is a workflow infrastructure; MuSE is a model-level multiscale representation and coupling mechanism [2507.07352; 2605.25710].

## 5. Implementation, deployment, and performance characteristics

Mini-MuMMI was created as a preconfigured, smaller, simpler version of MuMMI intended for modest HPC clusters, smaller-scale experiments, teaching and adaptation, and possibly even laptops [2507.07352]. The paper emphasizes that Mini-MuMMI is not different from the full version of MuMMI from a workflow perspective: same jobs, identical data flow, and smaller I/Os but identical patterns [2507.07352]. The main reductions are in molecular system size, ML model size, deployment burden, and omission of the macro model [2507.07352].

The Mini-MuMMI molecular system is a KRAS-RBDCRD membrane system with about **1280 total lipids** and about **50K total particles** [2507.07352]. This is about **3× smaller** than the system in the referenced 2024 MuMMI pathway study and about **6× smaller** than a more recent unpublished production campaign [2507.07352]. For the reported campaign, simulations were configured to stop at **600 ns** [2507.07352].

The reported demonstration ran on **Frontier**, described as a 1.353 exaflops system with **9,472 compute nodes**, each node containing **4 AMD MI250X GPUs**, **1 64-core AMD 3rd Gen EPYC CPU**, **512 GB CPU memory**, and **512 GB GPU memory** [2507.07352]. One MI250X contains two GCDs, and the paper treats each GCD as a GPU for accounting purposes, effectively yielding **8 GPUs per node** [2507.07352]. The campaign ran for **36 hours on 64 nodes** and **4 hours on 5 nodes**, achieving **1,983 simulations**, **1,632 simulations longer than 600 ns**, and **aggregated simulated time: 1109.4 microseconds**, described as about **1.1 milliseconds of CG simulation in 36 hours** [2507.07352].

Per-job resource usage is also explicit [2507.07352]:
- **createsims:** 1 GPU + 6 CPU cores
- **CGAnalysis:** 1 GPU + 6 CPU cores

A Frontier node has 56 usable CPU cores for this workload and 8 GPUs, so the deployment uses **6 cores/job** to fit **8 simulations per node** [2507.07352]. CGAnalysis shares those 6 cores between GROMACS simulation and Python in-situ analysis, with typically **1–2 cores** used for Python analysis [2507.07352].

The paper provides a performance comparison among three MuMMI system sizes [2507.07352].

| System | Createsims time | CGAnalysis rate |
|---|---:|---:|
| Small system (Mini-MuMMI) | \(584.2 \pm 81.3\) s | \(2096.7 \pm 290.3\) ns/day |
| Medium system | \(3602.1 \pm 895.6\) s | \(1179.08 \pm 237.3\) ns/day |
| Large system | \(2981.7 \pm 369.6\) s | \(538.1 \pm 104.8\) ns/day |

For the small system, the paper also reports **ML validation time: \(3.49 \pm 0.7\) s per structure**; for the large system, **\(6.43 \pm 10.10\) s** is reported [2507.07352]. Feedback files remain small, with size **8.0 KB** for the small system, **8.5 KB** for the medium system, and **29 KB** for the large system [2507.07352]. These figures support the workflow design in which messaging is lightweight and adaptive control is feasible at scale [2507.07352].

A plausible implication is that MuMMI’s scalability is achieved not by a single extremely long simulation, but by decomposing the campaign into many relatively compact jobs whose orchestration, validation filtering, and resubmission logic are optimized for high-throughput execution.

## 6. Use case: RAS–RAF membrane interactions

The principal scientific use case described is the interaction between **KRAS** and the **RBD and CRD domains of RAF** in the context of the plasma membrane [2507.07352]. The paper states that RAS mutations are implicated in roughly **a third of all human cancers**, and **KRAS** is the most frequently mutated RAS isoform [2507.07352]. MuMMI had previously been used to reveal lipid-dependent dynamics of RAS signaling proteins, including lipid fingerprints associated with protein orientation and interactions, and Mini-MuMMI is positioned as a compact version of the same conceptual strategy focused on **KRAS-RBDCRD** [2507.07352].

The two-state setup follows earlier MuMMI work and distinguishes conformational ensembles A and B by CRD membrane distance [2507.07352]. Using the **32-dimensional latent space**, Mini-MuMMI generated **1,983 valid new structures** [2507.07352]. These were converted into CG simulations, and the resulting simulation frames populated the region between the two endpoint ensembles, indicating successful bridging of conformational space between A and B [2507.07352]. The paper describes a figure with three distributions: top, the initial A and B ensembles; middle, generated structures between the states; bottom, frames produced after running the CG simulations [2507.07352]. The main reported result is that many frames from the generated and simulated structures fill the intermediate region between the endpoints [2507.07352].

This suggests that, in the demonstrated setting, MuMMI does not merely interpolate in latent space; it uses simulation to test whether decoded candidates can be embedded into physically meaningful membrane environments and remain productive under dynamics. That distinction is important because the validation and CGAnalysis stages prevent the latent representation from functioning as a purely geometric generator divorced from downstream physics [2507.07352].

The same broader logic appears in other multiscale ML domains, though with different scientific targets. In multiscale chemical-reaction modeling, for example, "When Machine Learning Meets Multiscale Modeling in Chemical Reactions" shows how low-order moments or slow variables can replace full fine-scale representations when time-scale separation exists [2006.00700]. In composites, "LS-DYNA Machine Learning-based Multiscale Method for Nonlinear Modeling of Short Fiber-Reinforced Composites" builds an offline/online multiscale constitutive workflow connecting process simulation, RVE homogenization, a Deep Material Network database, and FE deployment [2301.02738]. These are not MuMMI applications, but they reinforce the general principle that multiscale ML infrastructures rely on selective refinement, structured surrogates, and explicit cross-scale dataflow rather than homogeneous end-to-end black-box learning [2006.00700; 2301.02738].

## 7. Limitations, distinctions, and broader significance

The Mini-MuMMI paper is explicit about several limitations of the current MuMMI realization [2507.07352]. The initial simulations for states A and B and the first training of the ML model are manual; these steps are not yet automated by MuMMI [2507.07352]. Model retraining is manual and intermittent rather than online, even though the paper states that ideally MuMMI would retrain on the fly once enough new data have accumulated [2507.07352]. MuMMI also remains strongly shaped by the RAS–RAF scientific use case, despite the configurability of the Workflow Manager and the separation between application and coordination layers [2507.07352]. The paper further notes practical HPC friction: services such as RabbitMQ or Redis can be difficult to deploy on secure HPC systems, and the software stack is large, involving **200+ packages**, motivating use of **Spack** for deployment [2507.07352].

Mini-MuMMI also omits the macro model present in full MuMMI, which simplifies deployment but removes the continuum-to-CG part of the three-scale chain [2507.07352]. This omission should not be mistaken for a conceptual revision of MuMMI; it is a deliberate reduction for portability [2507.07352].

A second distinction concerns what MuMMI is **not**. It is not equivalent to a model-level multiscale neural architecture such as MuSE [2605.25710]. It is not identical to micro–macro lifting work based on conditional GANs, although that literature addresses closely related issues of coarse-to-fine reconstruction and closure estimation [2208.10715]. And it is not the same MuMMI as the Multiple Metrics Modeling Infrastructure used in HPC performance/power studies [2011.06655].

From the broader literature, a plausible implication is that MuMMI occupies a systems-level niche within multiscale scientific ML. Review work emphasizes that successful integration of ML and multiscale modeling requires simulation orchestration, multimodal or multifidelity data handling, adaptive learning, theory- or physics-guided constraints, and attention to interpretability and uncertainty [1910.01258; 2303.12261]. Mini-MuMMI demonstrates a concrete workflow embodiment of several of those principles: latent-space reduction, ensemble simulation, adaptive structure proposal, in-situ feedback, scalable scheduling, and portability to smaller computing environments [2507.07352].

Its significance therefore lies less in a single ML algorithm than in its operational synthesis of multiscale simulation and machine learning. In the reported demonstration, Mini-MuMMI preserved the workflow architecture and adaptive control patterns of full MuMMI while reducing system size and deployment complexity, and it generated **1,983 valid intermediate structures** and more than **1.1 milliseconds** of aggregate CG simulation in a short campaign on Frontier [2507.07352]. Within the broader development of multiscale scientific ML, MuMMI is best understood as a workflow infrastructure for discovering, generating, and refining transition-relevant molecular configurations across scales under HPC constraints [2507.07352].

Source: https://www.emergentmind.com/topics/multiscale-machine-learned-modeling-infrastructure-mummi