PTM-Psi: Cloud-Native PTM Simulation

• PTM-Psi is a cloud-native computational framework that simulates combinatorial thiol post-translational modifications on proteins using orchestrated containerized workflows.
• It leverages asynchronous, loosely coupled workflows on Microsoft Azure Quantum Elements to dynamically allocate resources for each simulation stage.
• By integrating AlphaFold2, NWChem, GROMACS, and Python analysis tools, PTM-Psi achieves high-throughput, cost-efficient molecular dynamics simulations and detailed protein analysis.

Searching arXiv for papers on PTM-Psi and related protein PTM simulation workflows. PTM-Psi denotes a computational framework for simulating post-translational modifications on protein structures and interactions, and in its cloud-native realization it is implemented as an asynchronous, loosely coupled workflow on Microsoft Azure Quantum Elements (AQE) for high-throughput investigation of combinatorial thiol PTMs. In the reported implementation, the existing PTM-Psi workflow was refactored into a cloud-native library integrating AlphaFold2, NWChem, GROMACS, and Python-based analysis tools, with dynamic resource allocation tailored to each stage of the simulation pipeline. The motivating use case is the computational investigation of a combinatorial explosion of thiol PTMs on an exemplary protein megacomplex critical to the Calvin-Benson cycle of light-dependent sugar production in cyanobacteria (Samantray et al., 11 Jul 2025).

1. Definition and scope

Within the reported architecture, PTM-Psi is a workflow for structural modeling and simulation of PTM-dependent protein behavior, with explicit support for protein targets supplied either as a PDB structure or as a sequence for AlphaFold2. The cloud implementation is organized around a top-level Python driver that reads a user YAML or JSON description of the protein target, the list of thiol PTM sites and types, and the selected downstream analyses such as MD, TI, PCA, and KTN (Samantray et al., 11 Jul 2025).

The framework is designed for a setting in which PTM state spaces grow combinatorially. That growth is formalized as

$N_{\rm inst}=\prod_{i=1}^s m_i,$

where $S$ is the set of cysteine sites, $|S|=s$, and each site $i$ admits $m_i$ distinct PTM chemistries. In the demonstration case, $s=3$ modules—GAP2, PRK, and CP12—with $m_{\rm GAP2}=3$, $m_{\rm PRK}=6$, and $m_{\rm CP12}=6$, implying $N_{\rm inst}=3\times 6\times 6=108$; the reported study ran a reduced 16-case set, while stating that the library will scale up to $S$0 without code changes (Samantray et al., 11 Jul 2025).

This scope places PTM-Psi at the intersection of structural modeling, force-field generation for non-standard amino acids, all-atom MD, and multilevel trajectory analysis. A plausible implication is that PTM-Psi is intended less as a single simulation code than as an orchestration framework for heterogeneous computational tasks.

2. Cloud-native architecture

The defining architectural feature is an asynchronous, loosely coupled “flow-of-workflows.” Users interact through the Azure Quantum Elements Open OnDemand web client or through the AQE/Slurm command line. The workflow manager fans out $S$1 independent sub-workflows, one per PTM-combination instance, by generating a unique subdirectory and a small Slurm job script for each instance (Samantray et al., 11 Jul 2025).

Independence among instances is strict except for minimal internal ordering constraints. Each instance must finish structure preparation before force-field generation, and must finish MD before trajectory post-processing, PCA, KTN, or TI. Synchronization points are therefore limited largely to final scoring and aggregation of quantities such as $S$2 or free energies. The pipeline is described as “pleasingly parallel,” reflecting that no task $S$3 depends on any other $S$4 for $S$5 (Samantray et al., 11 Jul 2025).

Dynamic resource allocation is central. PTM-Psi inspects each sub-workflow step and dispatches it to the reported optimal hardware profile: AlphaFold2 on GPU-node partitions with CPU plus modest GPU; NWChem on large CPU-only nodes with 120 vCPU; GROMACS MD on GPU nodes with $S$6 per node linked by NVLink; and Python-based analysis on CPU-only or mixed nodes depending on memory and CPU load. Azure autoscaling through the AQE batch API spins nodes up or down according to Slurm queue depth, so that bursts such as 200 submitted GROMACS jobs trigger matching GPU-node allocation and subsequent release when the queue drains (Samantray et al., 11 Jul 2025).

This architecture is explicitly intended to reduce operational complexity while lowering entry barriers to data interpretation with structural modeling for a redox proteomics mass spectrometry specialist.

3. Software stack and workflow decomposition

The refactored PTM-Psi library unifies four containerized engines under a single Python API, each shipped as an Apptainer/Singularity container (Samantray et al., 11 Jul 2025).

AlphaFold2 is wrapped as ptmpsi.af2. It accepts either a UniProt identifier or a FASTA sequence, writes a PDB to structures/REF<i>/, and launches through af2-run.sh with a request for 1 GPU and 8 CPU.

NWChem is wrapped as ptmpsi.ffgen. It consumes a PTM’d PDB and generates non-standard amino-acid parameters via DFT at B3LYP/6-31G*, outputs Amber-style .frcmod and .lib files, and then translates them to a GROMACS .top through AmberTools.

GROMACS is wrapped as ptmpsi.md. The MD workflow is specified as full all-atom explicit-solvent MD with minimization, NVT/NPT equilibration, and 100 ns production. GPU resources are detected automatically via gmx gpus, and PME plus all bonded terms are offloaded to GPU where supported. The reported representative ensemble size is

$S$7

The Python-based analysis module is exposed as ptmpsi.analysis. It implements univariate metrics including radius of gyration, RMSD, RMSF, and DSSP-based secondary structure, together with multivariate PCA, kinetic transition network analysis, and thermodynamic integration. The data-flow is specified as trajectories (*.xtc) and topologies (*.tpr) through GROMACS trjconv, then into netCDF, then into the ptmpsi.analysis API, and finally into HDF5/Binder for combined PCA/KTN (Samantray et al., 11 Jul 2025).

The orchestration layer itself is entirely in Python, invoking the containerized engines through subprocess and storing inputs and outputs in a directory tree keyed by a unique 8-digit PTM code.

4. Formal workflow model and scaling behavior

The meta-workflow is defined by one sub-workflow per PTM instance,

$S$8

with the stages $S$9 = structure import or AF2, $|S|=s$0 = force-field generation (NWChem), $|S|=s$1 = MD production (GROMACS), $|S|=s$2 = trajectory postprocessing, $|S|=s$3 = univariate metrics, $|S|=s$4 = PCA ranking, $|S|=s$5 = KTN and TI (Samantray et al., 11 Jul 2025).

Because the $|S|=s$6 are independent, they are submitted as Slurm job arrays with array size equal to $|S|=s$7. Aggregation occurs only after all sub-workflows have produced outputs such as $|S|=s$8 and $|S|=s$9.

The idealized time-to-solution model is reported as

$i$0

for $i$1 independent simulations on $i$2 identical nodes, each capable of running $i$3 runs concurrently, where $i$4 is the wall clock for one 100 ns trajectory at fixed resolution. Near-linear scaling is reported until Slurm queue saturation or I/O contention occurs. The throughput-versus-cost model is written as

$i$5

and

$i$6

The reported “knee” of the curve for MD-only workloads is roughly 40 GPU nodes, beyond which cost grows faster than throughput (Samantray et al., 11 Jul 2025).

A common simplification would be to interpret PTM-Psi scalability purely as a GPU acceleration problem. The reported formulation suggests instead that the dominant abstraction is orchestration of many independent, heterogeneously provisioned tasks.

5. Performance, throughput, and cost

For the cloud deployment, the reported GPU-MD throughput is 50 sub-workflows per hour per 10 GPU nodes, with 8 runs per node. Queue latency is reported as 2–5 minutes, versus 1–3 hours on the original on-prem cluster for comparable jobs, and average node utilization exceeds 90% once the job-array ramp-up completes. On a 40-node GPU partition, the reported sustained throughput is approximately 400 100 ns MDs per day; the original on-prem cluster, described as 16 Xeon E5 nodes with 4 GPUs total, produced approximately 40 100 ns MDs per day, i.e. 10× slower (Samantray et al., 11 Jul 2025).

For the direct 16-case end-to-end comparison, the reported on-prem pipeline required 120 minutes of queue latency, 10 hours of MD runtime per case, 2 hours of analysis per case, and 7 days of total wall clock. The AQE cloud configuration with 40 GPUs reported 5 minutes of queue latency, 8 hours of MD runtime per case, 1 hour of analysis per case, and 24 hours of total wall clock, corresponding to a 7× end-to-end speedup (Samantray et al., 11 Jul 2025).

The reported economic comparison gives an on-prem amortized cost of approximately \$i$$712 <a href="https://www.emergentmind.com/topics/undecided-state-dynamics-usd" title="" rel="nofollow" data-turbo="false" class="assistant-link" x-data x-tooltip.raw="">USD</a> per 100 ns MD plus analysis, a 2.5× cost reduction attributed to efficient autoscaling, GPU offloading, and the use of spot or preemptible nodes. At the per-case MD stage, the reported acceleration is more modest—1 to 1.25× faster on H100 than on on-prem V100—indicating that the end-to-end gain arises from the whole pipeline rather than from single-kernel acceleration alone (<a href="/papers/2507.09014" title="" rel="nofollow" data-turbo="false" class="assistant-link" x-data x-tooltip.raw="">Samantray et al., 11 Jul 2025</a>).</p> <p>This suggests that PTM-Psi on the cloud is best understood as a workflow-throughput system rather than merely a faster MD execution environment.</p> <h2 class='paper-heading' id='reproducibility-extension-and-scientific-significance'>6. Reproducibility, extension, and scientific significance</h2> <p>The reported reproduction pathway is deliberately explicit. It consists of cloning the BSD-3-clause PTM-Psi repository from <code>https://github.com/pnnl/PTMPSI</code>, provisioning an Azure Quantum Elements account with quota for at least 40 GPU nodes and 20 CPU-only nodes, building or pulling the Apptainer images <code>af2.sif</code>, <code>nwchem.sif</code>, <code>gmx.sif</code>, and <code>ptmpsi_analysis.sif</code>, writing a single JSON configuration file, and launching the workflow with <code>ptmp-workflow run --config my_run.json --submit-array</code>. Progress is monitored through Open OnDemand or <code>squeue -u$$USER (Samantray et al., 11 Jul 2025).

Upon completion, the aggregated results.h5 file contains per-instance $i$8 from Eqn (18), $i$9 from Eqn (28), and representative structures for KTN from Eqn (27). The framework is also described as extensible: new PTM chemistries such as sulfenic acid can be added by supplying appropriate NWChem driving scripts in ptmpsi/models/, and alternate MD engines such as AMBER or OpenMM can be incorporated through a 10–20 line Python adapter following the same Slurm-template conventions (Samantray et al., 11 Jul 2025).

Scientifically, the reported significance of PTM-Psi lies in converting a combinatorially difficult PTM-structure problem into a scalable, cloud-scheduled ensemble workflow. In the terms of the source paper, the system transforms the pipeline for thiol PTM analysis to achieve high throughput by leveraging cloud services, expands the scope and capability of PTM-Psi simulations beyond current limitations, and lowers entry barriers to structural interpretation of redox proteomics data (Samantray et al., 11 Jul 2025).