v2.5.8

This release closes the GUI to other machines and other sites, and fixes
results that 2.5.7 could get wrong without a warning. Off loopback the GUI
serves only the watched run's results, text from a study is shown as text, a
reply from the Agent alone no longer starts a run, and a page on another site
can no longer drive the GUI. A molecule away from the protein is measured in
its nearest periodic copy; the correlation time no longer misses a slow mode,
so standard errors and withheld verdicts can differ from 2.5.7's where frames
alternate; interaction rows are named by chain; a ligand's pose is matched
atom for atom; a stated cutoff is kept; and umbrella studies, which 2.5.7
refused, run again. Some studies that ran under 2.5.7 now stop with a reason:
a ligand whose net charge cannot be read, a ligand pose the structure holds and
cannot give, and an ion whose alternate locations tie. For services that run
FastMDXplora for other people, the GUI can be served behind a proxy that signs
people in, each release is published as a Docker image, and fastmdx resume
carries a stopped study on to its end. AmberTools is now a declared
dependency, and Windows is no longer supported.

fastmdx resume carries a stopped study on to its end

A study stopped part-way, by a restart, a time limit or a GPU taken back, is
finished by one command. fastmdx resume STUDY reads how far it got and does
what is left, once: nothing if it finished; the analyses and report if
production did; the rest of production from the last sealed checkpoint if it
had begun; the whole study again if it had not. It refuses a study still
running and one that stopped with a refusal, unless the refusal is marked worth
retrying, and it does not discard production it cannot continue. Running it
twice does the work once, so a service can run it whenever a job restarts;
--json prints the outcome for a program. The help for
checkpoint_interval_steps and the runner's notes no longer say there is no
resume.

A Docker image with each release

Each release is published as ghcr.io/aai-research-lab/fastmdxplora:<version>,
beside the Apptainer image on the release page, for services that run
FastMDXplora in containers. It is written from container/fastmdx.def by
container/docker_from_def.py, so the installation and the checks that fail a
bad build are the Apptainer image's own, and a study gives the same answer in
either. It runs as a user that is not root, with /workspace as its home and
working folder. See docs/hosting.md.

The GUI can be served to other people

fastmdx gui --hosted serves the GUI behind a proxy that signs people in.
It answers only requests carrying the proxy's secret (read from
FASTMDX_PROXY_SECRET), only under the names given with --allowed-host, and
only inside --workspace: every path a request names is read there, one
outside it is refused, and answers show paths as ~/..., never the server's
layout. It refuses to start without a secret, a name, or with the top of the
file system as its workspace. Nothing changes without --hosted. See
docs/hosting.md.

Python continues a study as the command line does

simulation.resume_from naming a study directory was a continuation only on
the command line. From Python the same config went to the batch layer, which
refused it for naming no system. FastMDXplora(config=...).explore() now
extends the study in place as fastmdx explore does, with duration_ns the
total and extra_ns an amount more, returns one result for the study, and a
dry run says what it would run. A segment that fails is reported as a failed
simulation rather than as a join that could not be made.

A ligand pose the structure holds and cannot give is refused

With ligand_pose: auto, a structure holding a residue of the ligand's name
whose pose could not be taken fell back to the supplied file's coordinates:
a different atom count, bonds that do not match, fewer copies than ligands,
or a structure that would not read. On a complex that starts the ligand away
from its site, the seventeen-Angstrom failure, with a log line to say so.
Setup now refuses (setup.ligand.pose_unavailable) and says to use
ligand_pose: file where the file's pose is the one meant. The file's pose
still stands where the structure holds no residue of that name, or where
there is no structure at all.

One segment number is one folder

segment-1 and segment-001 were both segment one. The join held
whichever listed later and a continuation resumed from whichever it met
first. Two readers also rebuilt a segment's folder from its number as
segment-NNN, so a folder named segment-1 was counted and never read: its
production was left out of what was done, and a killed one's frames were not
trimmed. Two folders with one number are refused
(simulation.resume.segment_named_twice) with both named, and every reader
uses the folder it found.

The Agent is told one thing, whichever way it is asked

• Attempts. The command line gave the Agent three attempts in all and
  its help called them corrections, which would be four; the browser and
  Python gave four. It is three in all, the first included, everywhere.
• Continuing a study. The prompt told the Agent to continue a study by
  naming it in resume_from, with duration_ns the total production it
  should end with. The browser's run status handed it the raw checkpoint
  form instead, with duration_ns the amount more, which ran as a separate
  study and joined nothing. The browser now offers the study form. A config
  continuing a study is run inside that study, its segments joined and its
  analyses rerun, and the GUI watches the study while it does: it had
  watched a new, empty folder and marked the run failed. The config is kept
  under the workspace's continuations/, so the study's own record of how
  it was started is not replaced.

The records and pages say what happened

• The methods said each heterogen decision was recorded in
  setup_parameters.json; it was only logged. The decisions, with their
  reasons and copies, are now written there as heterogen_decisions, and the
  sentence appears only where they are.
• The report's settings list said "Production MD was performed" of a study
  that ran none (duration_ns: 0).
• The GUI showed studies that finished as failed. Every study was held to
  a prepared system in its own setup/ and a finished simulation, so an
  analysis of a supplied trajectory, a setup-only study, a run given
  setup_from and a study of several runs failed on exit; a run the GUI
  adopted was judged by a Manifest status that does not exist. A study is
  now held to the phases it recorded, and a failure names the phase or the
  runs that failed.
• A slide deck that could not be written was said at debug level and
  recorded nowhere. It is recorded in not_produced.json beside a missing
  PDF, each entry with the code report.format.unavailable.

Each sugar and each ion is judged by its own bonds

A free sugar was discarded as a glycan when another copy of its name was on
an asparagine. Whether a sugar belonged to a glycan was decided per residue
name, and an inner sugar counted as glycan whenever the structure was
glycosylated anywhere, so a NAG in an active site beside a glycosylated
asparagine, or a lactose bonded only to itself, was removed without a
question. The glycan is now followed from the protein, sugar by sugar,
through the LINK records; a component with glycan copies and free copies
stops and names both. An ion LINKed only to a water was kept as
"coordinated by the protein", 30 A from it: a LINK now counts only to a
partner that stays in the system, and the reason names it. An NMR entry's
heterogens were counted once per model, so a zinc read as twenty atoms and
setup asked for an SDF; only the first model, the one prepared, is read.
Present in 2.5.6 and 2.5.7.

A moved study still finds the system it simulated, and only that one

A run given setup_from recorded the prepared system by path alone, as it
was typed. Moving or copying the study, or fetching it to another machine,
left re-analysis, the report and replica comparison unable to find it, and a
different prepared system at the old path was used without a word: its
ligand chemistry and atom count described atoms the run never simulated. The
run now records the system as given, as resolved, relative to itself and by
the SHA-256 of its system.xml, finds it relative to the run first, and
refuses a system whose content differs (analysis.data.not_this_system). A
campaign's manifest lists members relative to the campaign, and aggregation
and the comparison report read them that way. The GUI and the cross-tool
comparison read the setup record of the system a run simulated rather than
the run's own setup/, which a run given setup_from does not have. Present
in 2.5.6 and 2.5.7.

A ligand's pose is taken atom for atom

With the pose taken from the structure, the supplied file's heavy atoms took
the crystal positions in the order the two files happened to list them. Only
the count was checked, so two files listing the atoms differently put atoms
on each other's places: a C-C bond of 1.5 A came out at 3.0 and 4.5 A with no
error, since the clash check measures the ligand against the protein, not
against itself. Each atom now goes to the crystal atom of the same element
bonded to the same neighbours, the crystal's bonds read from its geometry;
where symmetry allows more than one answer, the one that fits the supplied
geometry best is taken. A residue whose atoms cannot be matched that way is
not used as the pose: ligand_pose: structure refuses, auto keeps the
file's coordinates and says why. Present in 2.5.6 and 2.5.7.

duration_ns: 0 equilibrates and stops

duration_ns is the production length, so zero now means no production: the
study is set ...

v2.5.7

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 simulat...

v2.5.6

A pull and its umbrella windows now come from one configuration, and a study
can be written from a sentence. Those are the two reasons this release exists.

A study can be written from a sentence

fastmdx agent "trypsin with benzamidine, 100 ns, umbrella along the
               unbinding coordinate" -o study.yml

Two providers by name and a third taking any OpenAI-compatible base URL, which
covers DeepSeek, vLLM, Ollama, OpenRouter and most local servers. What the
Agent writes goes through the same validate_config, by the same code, with
the same refusals, as a config typed by hand — when the validator refuses, the
refusal goes back and the Agent repairs. agent_model records which model
wrote a study, because an alias is not a version.

fastmdx agent with no request opens the Agent in the browser: a conversation
that can see the config, the run and the results, edits rather than restarts,
and when told to, runs, stops with a confirmation, and opens pages. It never
acts unasked.

A study is designed and priced before it spends anything

design_from_a_pilot reads the free-energy gradient off a handful of briefly
run windows and solves the spacing and the force constant together. On the
trypsin–benzamidine coordinate it gives 0.0344 nm at 12,970 kJ/mol/nm², against
the 0.0344 nm at 13,000 that study reached by hand over two days.

--autonomous runs in two stages with an estimate between them: setup settles
the solvated particle count, the estimate comes from that count on this
machine, and the simulation starts only if it fits --budget-hours. It refuses
without one, because a default allowance would be a number nobody chose
deciding how much of somebody's card to spend.

A cone on the angle, and the room it took out of the bulk added back

A flat-bottomed wall confines the ligand to a cap of solid angle
Ω = 2π(1 − cos θ), and binding_free_energy adds kT ln(4π/Ω) back. Both
numbers are reported. The half of that derivation which can fail is the bound
state, so every window writes the wall's own bias beside its coordinate and the
binding free energy is refused above a tenth of RT.

The rest

• Every refusal says which refusal it is — a stable name a program can act
  on, at all 437 raise sites, with a new uncoded one failing the suite.
  "Not enough data" is a refusal too, and says how much short.
• Drift is told from scatter — a permutation test on the segment ordering,
  because a pooled mean over a system that is still moving is a confident
  number for a quantity that does not exist.
• A study may be split, and says when it may not — metadynamics and steered
  pulls refuse, because a checkpoint does not restore the biasing state.
  A finished run seals its checkpoint, since a truncated one loads silently.
• The machine learns its own cost model from the runs it has finished.
• Four analyses — coordination_number, pair_distance, end_to_end,
  moments_of_inertia.
• Bounds on what a quantity cannot be — pH 25, a negative duration and a
  temperature below absolute zero all validated until now.
• figure_colours: colour, greyscale, or both, from any interface.
• "Settled" becomes "equilibrated" or "converged", which are different
  claims and are the field's words for them.
• The documentation is a set — six components, six new pages, and eleven
  claims that described behaviour the code does not have, corrected.
• Eight defects from an audit, and four more that finding them turned up.

The full entry is in [CHANGELOG.md](CHANGELOG.md).

Install

conda create -n fastmdxplora -c conda-forge fastmdxplora

fastmdx info lists every backend and how to get anything missing.

v2.5.5

A ligand is followed across the boundary

v2.5.4

One analysis does not disturb another

v2.5.3

Measurements the software can be checked against

v2.5.2

The workers start clean

FastMDXplora v2.1.0

FastMDXplora 2.1.0

A graphical interface, publication-ready figures, and Python 3.13 support.
An exploration can now be designed, launched, watched, and reviewed from a
browser, and the figures it produces are drawn for print.

Added

• Graphical interface. fastmdx gui opens a local browser interface with
  sections for building an exploration, starting it, watching it run, viewing
  the structure and trajectory, browsing analyses, and reaching the report.
• Config files from the GUI. The builder can save its selection as a
  FastMDXplora .yml file instead of starting a run, so an exploration
  designed in the browser can be submitted anywhere, including on a cluster
  where the GUI cannot run. The GUI guide documents the rsync pattern for
  watching a cluster job from a workstation.
• Live telemetry. A dependency-free localhost server that watches an
  output directory while an exploration is in progress: phase progress, live
  trajectory frames, an interactive 3D molecular viewer with playback, and
  per-analysis charts. It observes and starts explorations; it does not
  reimplement any phase science.
• Report content in the GUI. Summary cards, per-phase progress including
  phases that did not run, trajectory statistics with means and standard
  deviations, categorised analysis sections, and quick-action links. These are
  computed once and shown identically in the browser and in the report.
• v1 analysis compatibility profile (--compat v1): reproduces the
  scope, selection, stride, analysis set, and per-analysis options of the
  published BPTI case study from FastMDXplora version 1.
• PDB smoke campaign (scripts/run_pdb_smoke_campaign.py) for exercising
  the pipeline across many structures.
• Report additions: region highlights and a single-figure run summary.
• Python 3.13 support across the whole supported range (3.9 to 3.13).
• Documentation: a beginner's guide, a CLI reference, a GUI guide, a
  production-run guide, region-highlight and smoke-campaign pages, and a
  substantially expanded installation guide.

Changed

• Publication-ready figures. The palette is now Okabe-Ito, which stays
  distinguishable under common colour vision deficiencies and in greyscale;
  the previous palette's red and green converged in both. Axes are closed with
  inward major and minor ticks, and tick density adapts to each panel's
  physical size, so long trajectories no longer crowd their axes. Legends get
  a translucent backing and headroom so they stay readable over dense data.
• One interface module. All user-interface code now lives in
  fastmdxplora.gui: the localhost server, the browser application and its
  assets, and the static dashboard written into a report. Both surfaces share
  one set of design tokens and display the same figures.
• Explorer nomenclature throughout. An exploration is started rather than a
  job launched: Start Exploration in the interface, /api/explore/*
  endpoints, fastmdxplora.gui.exploration in the Python API, and exploration
  wording in the terminal.
• Each analysis has its own section. Sections used to be merged when they
  held three figures or fewer, so an analysis appeared under its own name or a
  catch-all depending on how many plots that run produced.
• The startup banner is one left-aligned block; info carries the version,
  authors, DOI, phase availability, and backend status.
• CI runs on Python 3.9 through 3.13 across Linux, macOS, and Windows, with
  actions updated to Node 24 compatible versions.
• STRUCTURE.md rewritten to match the current tree.

Fixed

• Simulation robustness, with clearer diagnostics when an integration step
  produces a NaN.
• Batch early-stop behaviour when an exploration fails.
• Report-only invocation and phase validation.
• Windows: path comparison, server port reuse, and platform-specific commands.
• The CLI degrades cleanly when the chemistry backends are absent rather than
  failing mid-phase.
• The startup banner printed twice, and advertised a GUI address even when no
  GUI was running.
• Figures were listed twice, once for the PNG and once for the SVG of the same
  plot.
• CLI tests asserted the exit code of a machine without OpenMM, so they passed
  in CI and failed on a working install.
• Documentation examples are covered by drift tests so they cannot go stale.

Removed

• The bundled installer and repository doctor. Installation now follows
  standard routes: pip for analysis and reporting, pip plus conda-forge for the
  full chemistry stack, or a clone with the bundled environment.yml.
• The dashboard subcommand; fastmdx gui --output DIR opens the same
  interface pointed at an existing run.
• The curated chart pipeline, which redrew 17 figures in a second style that
  nothing displayed once both surfaces settled on the analysis figures.
• The live pressure metric. OpenMM's StateDataReporter cannot supply it, so
  the card could only ever read zero; the barostat setpoint remains in the run
  summary.
• driftmd_workbench, a separate package that duplicated the analysis and
  report pipeline without using it.

Install

pip install fastmdxplora

For the full four-phase workflow you also need the chemistry stack:

conda install -c conda-forge openmm pdbfixer openmmforcefields

See the installation guide.

Links

• Documentation: https://fastmdxplora.readthedocs.io
• PyPI: https://pypi.org/project/fastmdxplora/
• Full changelog: https://github.com/aai-research-lab/FastMDXplora/blob/main/CHANGELOG.md

Citation

Aina, A.; Kwan, D. FastMDAnalysis: Software for Automated Analysis of Molecular Dynamics Trajectories. J. Comput. Chem. 2026, 47, e70350. DOI: 10.1002/jcc.70350

FastMDXplora v2.0.0

FastMDXplora 2.0.0

Fully Automated SysTem for Molecular Dynamics eXploration.

FastMDXplora explores a protein's behavior end-to-end from a single command. Given a structure (or just a PDB ID), it performs molecular dynamics exploration all the way through setup, simulation, analysis, and reporting, then hands back publication-ready results.

setup  ->  simulation  ->  analysis  ->  report

Highlights

• Single-command exploration across all four phases: setup, simulation, analysis, and reporting
• Protein-ligand support with automatic OpenFF ligand parameterization and ligand-aware analyses (pose stability, contacts, protein-ligand hydrogen bonds)
• Enhanced sampling built in via PLUMED (metadynamics, umbrella sampling, steered MD)
• Scales from a single protein to large parallel campaigns, driven the same way from the CLI or the Python API

Install

pip install fastmdxplora      # or the short alias: pip install fastmdx

The full setup and simulation phases use the OpenMM stack (best installed via conda-forge); see the installation docs for the complete environment.

Links

• Documentation: https://fastmdxplora.readthedocs.io
• PyPI: https://pypi.org/project/fastmdxplora/

Citation

Aina, A.; Kwan, D. FastMDAnalysis: Software for Automated Analysis of Molecular Dynamics Trajectories. J. Comput. Chem. 2026, 47, e70350. DOI: 10.1002/jcc.70350

v1.1.0

Highlights

• Added Dihedral analysis with Ramachandran plots (including error bars and per-residue frame plots) and improved CLI support (e.g., --residues handling and aliases). (#16, #18, #19, #20)
• Added Fraction of Native Contacts (Q-value) analysis module. (Q-Value module + test discovery update)
• Improved MDS dimensionality reduction to robustly detect and adapt to scikit-learn API differences, avoiding deprecated parameters and handling multiple versions cleanly.

Analysis & plotting improvements

• Enhanced time-series/statistical reporting with compute_stat summaries; refined plot bounds and visual defaults. (#21)
• Improved clustering visualizations (layout/whitespace, dendrogram x-axis cleanup, label styling).
• Added adaptive plotting helpers for slide-ready figures and expanded plotting regression coverage (including slide style helpers).

Reliability & compatibility

• Major scikit-learn compatibility work for MDS: exhaustive parameter fallbacks, warning suppression, and version-robust behavior.
• Filtered pyparsing deprecation warnings originating from MDTraj; fixed pytest warning filtering to avoid failures across pyparsing versions.
• Increased test coverage across analyze helpers, plotting, options forwarding/passthrough, and specific analysis modules.

CLI & workflow

• Fixed CLI -o/--output flag issue. (#7)
• Added permissive options passthrough and test coverage for the options forwarder.

Documentation & metadata

• Documentation updates for plotting and outputs.
• Added CODE_OF_CONDUCT.md.
• Updated Zenodo DOI metadata (pyproject.toml, CITATION, README).