FastMDXplora: Fully Automated SysTem for Molecular Dynamics eXploration

This release is for running a study where the compute is, and for carrying on one that has already run. fastmdx remote inspects a machine over your own ssh, installs there once you confirm, sends a study and brings it back, and a study can now be resumed or extended in place and stay one study, joined and reanalysed over its whole length. Structures are read as their authors deposited them: the biological assembly from REMARK 350, mmCIF as mmCIF, and each residue named by its chain and insertion code. The GUI holds more than one study, lets a run outlive the server, and keeps the Agent's conversations with the study they are about. Several defects in 2.5.6 that changed what was simulated or reported are fixed, the most consequential being coordinated metal ions missing from the prepared system, and a network exposure in two GUI routes added during this cycle is closed before release. Off loopback, the dashboard answers only what it lists A dashboard bound beyond loopback (fastmdx gui --host, or --dashboard-host on explore) has no login, so what it answers there is the whole of its security. It refused a list of POST routes and answered the rest, and /api/explore/switch, added with Load study, was not on the list. Anyone who could reach the port could re-root the server onto any folder on the host shaped like a study, after which that folder's files were served through /artifacts/ and /api/file-text; the route's two error messages also said whether a path existed. Stored Agent conversations could be read through GET /api/agent/conversation and /api/agent/conversations. Off loopback every POST is now refused unless it is listed as open, so a route added later is refused by default. The list holds only /api/config, which builds a config from the posted form and reads no file. The conversation reads are refused there too. Neither route is in 2.5.6, so no release was exposed, only installs of the development branch between those routes and this fix. A dashboard on loopback, the default 127.0.0.1, was never affected. A coordinated ion reaches the prepared system 2.5.6 prepared structures with coordinated metal ions without them. Under the default heterogens: auto, a lone ion the classifier decided to keep, a catalytic zinc or the structural calcium of trypsin, was logged as kept and then removed by PDBFixer with every other heterogen, because the filtered structure that carries kept components to PDBFixer was never written for it. The prepared system lacked the ion, and the study simulated an empty site. With the ligand supplied as a file, the structure's ions were not considered at all and went the same way, unreported. The filtered structure is now written before anything can return, holding exactly the copies the decisions keep (and crystallographic water, where asked for), and the setup record lists the ions kept. A supplied ligand file no longer changes this: its path decides the ions by the same rules, refuses an ion the structure does not determine as the auto path does, and reports what the filter left out. Trypsin keeps its calcium beside a benzamidine file as it does without one. Split ion sites are decided site by site. An ion modelled at alternate locations within one residue is one ion, at its location of highest occupancy, and no longer asks for an SDF. Copies in separate residues were put into one group whenever any two of the same element lay within 1.5 A, so two split zincs 20 A apart were refused as one four-copy site or lost a site, and a site that resolved kept the copy first in the file while the log named the copy of higher occupancy. Copies now form sites by connectivity, each site keeps its copy of highest occupancy or stops on a tie, and only that copy reaches PDBFixer. A placed ligand's hydrogens turn with it When a ligand's pose is taken from the structure, the heavy atoms of the supplied SDF or MOL2 are moved onto the crystal coordinates. The hydrogens were then shifted by the displacement of the first heavy atom alone, with no rotation, so wherever the file's frame differed from the crystal's the X-H bonds came out several angstroms long. Ligands placed this way in 2.5.6 began minimisation with their hydrogens misplaced. Each hydrogen is now placed from the heavy atom it is bonded to (the nearest heavy atom where the file has no bonds), turned by the Kabsch rotation that fits the file's heavy atoms onto the structure's. A named prepared system is the one simulated, and is checked A run given simulation.setup_from still ran setup when setup was in its plan. Each run of a replica sweep solvated a box it never simulated, and the setup record beside it described those atoms rather than the ones simulated. With setup excluded, the analyses and the report found no setup record at all, so the protein-ligand interactions perceived the ligand's chemistry from its coordinates instead of reading it from the file it was prepared from. The formal charge was among what was perceived, and it decides every salt bridge, so interaction tables from such runs can change. Setup is now dropped from the plan when setup_from names a prepared system. The log says so, and the manifest records the setup phase as skipped, with taken_from naming the system simulated. The analyses, the report and the Agent's staged run read that system's setup record, and the interaction record carries the formal charge it was judged with. A study whose runs share one prepared system reused it whenever one existed, so a re-run asking for pH 5.0 simulated every window in the pH 7.4 system prepared before while its resolved config said 5.0. What the shared system was prepared from is now recorded beside it. A mismatch is refused as setup.prepared.mismatch, naming the settings that differ, and --force-overwrite prepares it again. A shared system prepared before this release has no record, and is reused with a warning. Splits and reports follow the ensemble production ran in Whether production has a barostat decides the caveat a study split into segments carries, since the barostat's adaptive move size is not in a checkpoint and re-adapts after every join, and it decides what the report says was simulated. In 2.5.6 both read the wrong evidence. The split verdict read pressure_bar and pressure_atm from the config. A default study names neither and produces at constant pressure, so a default study split into segments joined with no qualification, while a resolved config always carries a pressure, so a constant-volume continuation was qualified. The verdict now asks the resolver the runner uses, and a queued study records the caveat only when it is split. The report's settings list gave the ensemble as None, and the methods paragraph and the slides described production as NPT at a pressure whether or not a barostat ran, so an NVT production was reported as NPT. The runner now records the ensemble production ran in under resolved, and the settings list, the methods text and the slides read it, stating a pressure only where a barostat ran. Restraints are released in stages whether or not the run is watched With simulation.restrain set and live_telemetry: false, NVT and NPT equilibration ran through a stage runner that took no progress callback. The restraints were held at full strength through both stages and released all at once as production began, rather than stepped down through restraint_release during equilibration. Runs made that way in 2.5.6 started production from a solute let go in one step. Both stage runners now drive the release ladder. Studies run on other machines fastmdx remote reaches a workstation or a cluster with your own ssh and ~/.ssh/config. A study's Config never names a machine; the records are kept with your other settings. fastmdx remote --machine NAME inspects and records what the machine has: GPUs and the CUDA version its driver supports, conda and every environment holding FastMDXplora (under the base, ~/.conda/envs, envs_dirs in ~/.condarc and CONDA_ENVS_PATH), Apptainer, SLURM partitions, scratch, free space and internet access. It asks the installation matching this computer's code what it can load, through the new fastmdx info --json. A release matches by version; a checkout matches only by commit, with no uncommitted changes on either side. Inspecting changes nothing on the machine. Where the machine is not ready, it prints the plan: a conda-forge install with cuda-version pinned to what the driver supports, a checkout brought to this computer's commit with git fetch and merge --ff-only, or a backend added to an environment that cannot load it. remote install runs that plan once you answer yes at the terminal. There is no flag to skip the question. remote send -c study.yml checks the Config here, refuses a machine not holding this computer's code, copies the Config and every file it names, and starts fastmdx explore there: as a detached process group on a workstation, or as an sbatch job asking for a GPU on SLURM (--partition, --time). --dry-run shows what would be sent. remote status gives each job's exit code, scheduler state, stage, share of its planned steps, and the last lines of its log. remote fetch refuses a job still waiting or running, brings the run folder back without trajectories and checkpoints unless --with-trajectory is given, and checks that the manifest names the code that sent it. remote cancel stops a job and leaves its folder; remote forget removes a machine's record; fastmdx remote alone lists machines and jobs without connecting. A structure is simulated as its biological assembly A structure given without chains may now simulate different chains from those 2.5.6 simulated. A deposited entry holds the asymmetric unit, which is what the crystal repeated rather than what the molecule is. Every deposited chain was simulated whatever REMARK 350 said, so 1AKE ran as two copies of a monomer, 1HHO as half a haemoglobin and 1STP as a quarter of streptavidin.