Scientific workflows / ML interatomic potentials
Polymer elastic-response workflows with UMA / FAIR-Chem
Building a polymer elastic-response workflow with UMA / FAIR-Chem and LAMMPS, from individual snapshots to batch calculations and stress–strain analysis.
Workflow schematic
From polymer snapshots to elastic response
Workflow schematic based on the implementation; it illustrates calculation stages, not a validated property result.
Polymer snapshot
Select an input configuration and record the run settings.
UMA + LAMMPS
Prepare and sample a fixed-box baseline at 300 K.
12 perturbations
Apply positive and negative strains in six modes; sample stress.
Elastic response
Assemble the stiffness matrix and postprocess modulus estimates.
The question this work led to
When GPU memory limits practical simulation, how can we reduce resource demands without compromising the physics?
Research question
What does it take to turn a pretrained interatomic potential into a reproducible polymer-simulation workflow under practical GPU-memory constraints?
Approach
- Used the FAIR-Chem–LAMMPS interface to build snapshot-based polymer calculations with UMA and a fixed-box baseline at 300 K.
- Implemented positive and negative perturbations in six strain modes, with stress sampling and finite-difference stiffness-matrix postprocessing.
- Organized single-snapshot and batch execution with per-run metadata and postprocessing for elastic-response estimates.
- Added tooling to inspect model cutoff and neighbor settings, directed edge counts, and neighbors per atom to examine the size of the molecular graph supplied to the potential.
What I built and learned
- A reusable workflow linking polymer snapshots, UMA / FAIR-Chem calculations, and stress–strain postprocessing.
- Batch-launch and graph-inspection tools for investigating the practical resource requirements of the workflow.
- A research question grounded in experience: how can MLIPs use GPU memory and computation more efficiently while preserving their physical predictions?
Working on this project exposed me to GPU-memory limitations. That experience motivated the later MACE resource study, where I measured runtime, sampled device memory, and allocated GPU-hours together.
Scope & limitations
- This case study documents an implemented elastic-response workflow. It does not report a validated UMA modulus benchmark, glass-transition temperature, or equilibrium density.
- No specific UMA memory footprint or optimization speedup is reported here. The later MACE measurements are a separate study.
- Changing a pretrained model’s neighbor settings can alter its predictions. Such changes require scientific validation and are not automatically equivalent to memory optimization.