Skip to main content
​
PDF reports for parameterized models, the data behind every plot, and dashboards that stay yours

​
PDF reports for parameterized models

A parameterized model’s page has a Report button that downloads a PDF of the model as it stands. Each function-valued parameter is plotted against its input (stoichiometry, state of charge, electrolyte concentration or temperature), with one curve at each of 0, 10, 25, 35 and 45 °C where temperature is an input. Where possible it is also written out as an equation, with a legend giving each referenced parameter’s name and value. A parameter that can’t be plotted is listed in a Not plotted table with the reason. Scalar parameters are tabulated in the same sections as the model’s parameter tabs, after a cover page listing the model type, thermal and ageing options, and description.

​
See and export the data behind a plot

Dashboard plots, and plots in the measurement plot drawer, have a View source data menu item. It opens one table of the data the plot is drawn from — with the measurement, cell and specification names alongside the values where the plot reads them — and the same table downloads as CSV. Values the plot calculates while drawing are not included, and the dialog says so.

​
Dashboards stay the way their creator left them

Only the person who created a dashboard can edit or delete it, its plots, or its agent drafts. Everyone else with access can still view it and change plot inputs for themselves (never saved). Anyone whose role can create dashboards (Project Admins and Contributors) can also make their own version of the whole dashboard, or copy a plot to a dashboard of their own. A duplicated dashboard shows where it came from (“Copied from X on 2026-10-11 15:52”). Trying to change someone else’s dashboard explains how to get an editable copy.

​
Repair a file whose time runs backwards

A raw file that fails the time-ordering check no longer leaves only Accept and continue or Discard this file. The review now shows the offending rows and offers just the repairs that fit the problem, recommended first: rebuild a continuous clock (when a per-step clock was exported instead of total elapsed time), sort rows by time, drop the out-of-order rows, or separate identical timestamps. A repair that doesn’t restore ordering is reported as still needing input rather than marked fixed.
Improvements
  • Choose the agent’s model. A picker under the chat input switches between Opus 5.5 (the default), Sonnet 5.5 and Haiku 5.5, and your browser remembers the choice.
  • Analysis plots read cleanly when a test repeats set-points. Points are drawn in x order as markers, with a line through each set-point’s mean, so a rate table run twice reads as one line instead of a sawtooth. This applies in the plot drawer, dashboards and the analysis page.
  • The protocol generator is faster and fails less often. It no longer gets stuck re-reading the same reference material until it gives up.
Fixes
  • An older export of a running test no longer closes it. A manually uploaded file whose data ended more than two days ago marked the test as finished, so the next, fuller export was refused as not fitting. Runs already closed this way are unchanged.
  • Reported metrics no longer show a misleading number when a threshold is never reached. A metric such as “Charge time (10–80% SOC)” on a charge that stalls before 80% now shows no value.
  • Stacked dashboard plots put the x axis under the bottom row instead of the top. Plots already on a dashboard pick this up when they are re-sent or edited.
  • Paging past the end of a list, for example after a filter shrinks it, returns an empty page on the pipelines list and most others, instead of a server error.
The metric examples below use the ionworkspipeline Python classes; in a pipeline config the same metrics are written as dicts, e.g. {"type": "Crossing", ...}.Improvements
  • A metric can span several steps. Any metric’s step accepts a list of consecutive steps, read as one, e.g. Minimum("Negative electrode potential [V]", step=[2, 3, 4]). Gaps, repeats and descending lists are rejected with a message pointing to ComposedMetric.
  • New Crossing metric, Crossing(variable, crossing_variable, value, step), reads variable at each point where crossing_variable crosses value. SOC and Voltage are now special cases of it, with their configs unchanged.
  • Crossing thresholds can be metrics. value accepts a metric evaluated on the whole solution, so a threshold can depend on an earlier step, e.g. the time for throughput to go from 10% to 80% of a step-0 capacity.
  • by_cycle(step={cycle: step}) reads a different step in each cycle, for a quantity logged at different positions in different cycles.
  • RelativeTime validates as a metric config, on its own, as a threshold, and in design optimizations.
  • DirectEntry references must be in the pipeline’s project. A pipeline_id or cell_spec_id from another project is refused with a permissions error that says how to fix it.
Fixes
  • Pipeline calculations that read a stored measurement (for example an OCP interpolant from a GITT measurement) no longer fail with an authentication error.
  • CycleAgeing no longer saves only a threshold’s cycles for a crossing searched over the whole solve; an unsliced crossing with a cycle-sliced threshold is now rejected.
  • A missing variable in SOC now gives a UserConfigurationError that names it, rather than a bare KeyError.
Fixes
  • Arbin LS_CHAN_* capacity and energy are read as the cumulative channel counters at the end of the previous step, matching the cycler. Protocols that read them after several steps without a counter reset (e.g. sizing GITT pulses from a two-part discharge) had used only the last step. Arbin energy counters now accumulate too.