PEtab-GUI: Interactive PEtab Editor

• PEtab-GUI is an open-source Python desktop application that provides an integrated interface for creating, editing, and validating PEtab parameter estimation problems.
• It employs a Model–View–Controller architecture with synchronized SBML/Antimony editing to simplify the management of complex, multi-file workflows in systems biology.
• The tool embeds live validation, simulation, and interactive visualization to reduce errors and lower the barrier to standardized parameter estimation.

Searching arXiv for the cited papers to ground the article in the latest records. PEtab-GUI is an open-source Python desktop application for building, editing, inspecting, and validating parameter estimation problems in the PEtab format within a graphical environment. It integrates all PEtab components—including the SBML model and the associated tabular files—into a single workspace with interactive table editors, synchronized SBML/Antimony editing, live validation against the PEtab standard, and embedded simulation and plotting. In the PEtab ecosystem, it functions as a front-end to the standard rather than as a replacement for it, addressing the practical difficulty of coordinating multiple interlinked files by hand and lowering the barrier to entry for standardized parameter-estimation workflows in systems biology (Jost et al., 14 Nov 2025).

1. Definition and relation to the PEtab standard

PEtab is a standardized, tool-independent format for describing parameter estimation problems for dynamical models in systems biology. It is organized around an SBML model and a set of TSV and YAML files that together specify experimental conditions, observables, measurements, parameters, visualization settings, and the overall problem definition. The core motivation of PEtab is reproducibility and reusability: information required for parameter estimation—such as observation models, noise models, parameter bounds, transformations, and priors—is not fully covered by SBML, CellML, BNGL, SED-ML, or SBRML alone, and fragmented tool-specific input formats impede switching between backends and reusing published estimation problems (Schmiester et al., 2020).

Within that framework, PEtab-GUI addresses the operational complexity of the PEtab specification. A PEtab problem is a coordinated set of files in which edits in one file often require synchronized updates in others. Observable identifiers affect measurements and visualization; condition definitions constrain simulation settings; parameter identifiers appear in observation formulas, noise specifications, and overrides. PEtab-GUI centralizes these components in a single interface, automates bookkeeping of inter-file links, provides context-aware editing through defaults and drop-down choices, and performs real-time consistency checks (Jost et al., 14 Nov 2025).

The software is therefore best understood as an interface layer over an existing community standard. It does not replace PEtab and does not alter the underlying semantics of the format. Instead, it makes PEtab’s multi-file structure manageable for users who do not wish to generate the files programmatically, while preserving the interoperable representation required by downstream simulators and estimation frameworks (Jost et al., 14 Nov 2025).

2. PEtab problem structure and parameter-estimation semantics

A PEtab problem comprises seven conceptual artifacts: an SBML model file; a condition file encoding experimental settings; an observable file mapping internal model quantities to measured readouts and specifying noise models; a measurement file containing the experimental data; a parameter file listing the parameters to estimate together with bounds, scales, and estimation flags; an optional visualization file; and a YAML problem file that links the entire specification (Schmiester et al., 2020).

The underlying mathematical structure is the standard systems-biology calibration setting. PEtab assumes a dynamical model such as

$$\frac{dx}{dt} = f(x(t), \theta), \quad x(t_0) = x_0(\theta),$$

with condition-specific overrides and optional pre-equilibration. Observables are defined by observation functions that map model states and parameters to measured quantities, and the observable file can specify normal or Laplace noise models as well as linear, logarithmic, or $\log_{10}$ transformations. In the Gaussian case, a typical objective can be written as

$$J(\theta) = \sum_i \left(\frac{y_i^{\text{data}} - y_i^{\text{model}}(\theta)}{\sigma_i}\right)^2,$$

which is equivalent, up to constants, to the negative log-likelihood (Schmiester et al., 2020).

PEtab-GUI does not implement optimizers itself. Its role is to construct these inputs correctly and consistently: the model through SBML, the mapping to observables and noise through the observable and parameter tables, and the data and condition assignments through the measurement and condition tables. This division of labor is central to its design. The software focuses on specification, inspection, and validation of the parameter estimation problem rather than on executing the estimation procedure (Jost et al., 14 Nov 2025).

3. Software architecture and implementation

PEtab-GUI is implemented in Python 3.11. Its graphical layer is built on PySide6, the official Qt bindings for Python. Simulation is performed through BasiCO, a simplified Python interface to COPASI, and validation is delegated to PEtab-compliant linting tools provided by the Python PEtab library (Jost et al., 14 Nov 2025).

The application uses a Model–View–Controller architecture. The model layer contains the internal representation of PEtab tables and the SBML model; the view layer consists of Qt widgets such as tables, text editors, and plots; and the controller layer coordinates user interactions and data updates. This design is applied hierarchically, so that major components such as individual tables or the SBML editor themselves follow MVC. The stated consequences are high modularity, easier maintenance, and extensibility to future PEtab versions or additional features (Jost et al., 14 Nov 2025).

SBML handling is presented through two synchronized representations: raw SBML XML and Antimony, a more human-readable model language. Conversion between these representations relies on existing SBML/Antimony tooling. This synchronized dual representation is significant because it allows direct editing at either the XML level or a higher-level textual level while keeping a single underlying model definition (Jost et al., 14 Nov 2025).

The architecture also defines the system’s boundaries. Optimization frameworks such as AMICI, pyPESTO, and PEtab.jl are not embedded directly. A plausible implication is that the software is intentionally positioned as an upstream authoring and inspection environment whose outputs are designed for immediate use by external PEtab-aware toolchains, rather than as a monolithic modeling platform (Jost et al., 14 Nov 2025).

4. Interactive workspace and editing workflow

The user interface unifies PEtab components into a single problem view. Each PEtab table—conditions, observables, measurements, parameters, and visualization—is displayed as a dock widget that is resizable, movable, hideable, and capable of being placed on separate screens. The SBML model appears in a dedicated tab with synchronized XML and Antimony views. Opening any PEtab component triggers automatic type detection, after which the file is inserted into the current problem (Jost et al., 14 Nov 2025).

Creation of a new PEtab problem follows a structured workflow. An existing SBML model can be imported, or a new model can be written directly in Antimony inside the application. Experimental data, which often arrive as matrices with rows corresponding to time or dose and columns corresponding to observables, can be imported and automatically converted into PEtab’s long-format measurement table. During that conversion, the software flattens the matrix into measurement rows and generates template entries in the observable and condition tables as needed (Jost et al., 14 Nov 2025).

The subsequent editing phase combines structured defaults with spreadsheet-like manipulation. New observables and conditions created from imported data receive customizable default values, such as a default noise model, and the parameter table can be populated using model-derived defaults such as initial parameter values and default bounds. Existing PEtab problems may be opened as complete or incomplete specifications, either from the YAML problem file or from any subset of tables, including by drag-and-drop. Standard operations include adding or deleting rows and columns, copying and pasting data, advanced filtering, and multi-cell editing within a column for repeated assignments such as the estimate flag or shared condition identifiers (Jost et al., 14 Nov 2025).

A distinctive feature is context-aware editing. Columns with predefined values use combo boxes; columns that reference identifiers defined elsewhere provide drop-down lists restricted to valid identifiers. If a new condition or observable is referenced in the measurement table, PEtab-GUI automatically generates the corresponding entry in the relevant table with default values. This directly addresses a common failure mode of manual PEtab editing, namely the omission of matching rows in linked tables (Jost et al., 14 Nov 2025).

5. Validation, visualization, and simulation

Validation is integrated into the editing loop rather than deferred to a separate export stage. At the cell level, edits trigger real-time plausibility checks through PEtab’s validation routines. These checks detect structural inconsistencies such as missing required columns or wrong types, references to non-existent identifiers such as undefined observables, and incomplete entries. Errors and warnings are displayed immediately in the graphical interface, for example through cell highlighting and message panels, and users can additionally run global checks over the entire problem to ensure full PEtab compliance before export (Jost et al., 14 Nov 2025).

The significance of this design lies in when errors are surfaced. By front-loading error detection into the model-construction stage, the software reduces downstream failures in simulators or optimizers. In PEtab workflows, where a single malformed identifier or inconsistent override can invalidate an otherwise complete specification, immediate feedback materially changes the practical reliability of problem authoring (Jost et al., 14 Nov 2025).

PEtab-GUI also couples tabular editing to visual inspection. It plots both measurement data and simulated trajectories, organizing displays by condition, observable, or the visualization table. The plots support bidirectional highlighting: selecting a data point in a plot highlights the corresponding measurement-table row, and selecting a row highlights the corresponding marker in the plot. This creates a direct link between the formal PEtab encoding and the empirical record represented by individual measurements (Jost et al., 14 Nov 2025).

Simulation is available from within the interface through BasiCO/COPASI. With a single click, the current model can be simulated using the current parameter values, and the result is automatically overlaid on the measurement data. The intended use cases include quick sanity checks, preliminary manual calibration, and validation of model structure. Reported performance characteristics indicate that medium-sized problems of approximately 50 parameters and approximately 300 measurements can be plotted, filtered, edited, and error-checked without noticeable lag, whereas larger problems with tables containing several thousand rows remain usable but exhibit slower plotting and live filtering; hiding the plotting widget can improve responsiveness (Jost et al., 14 Nov 2025).

6. Interoperability, use cases, limitations, and availability

PEtab-GUI is explicitly positioned upstream of estimation tools. Once a complete and validated PEtab problem has been authored, it can be passed to pyPESTO for gradient-based parameter estimation and uncertainty quantification, to AMICI or other simulators for efficient ODE evaluation, to COPASI via COMBINE archive or direct SBML/TSV import, to PEtab.jl for Julia-based workflows, and to other PEtab-compliant tools such as Data2Dynamics or pyABC wrappers. Because PEtab is a standard, the same problem definition can be consumed by multiple independent backends (Jost et al., 14 Nov 2025).

Its import and export capabilities reinforce that role. The application can import any single PEtab table, partial or complete PEtab problems, and experimental data matrices that are converted into PEtab measurement format. It can export individual TSV tables and the SBML model, the full PEtab problem as a directory of files, or a COMBINE archive in .omex format. This supports reproducible modeling and convenient exchange of models, data, and configuration in collaborative settings (Jost et al., 14 Nov 2025).

The software is also intended as an accessible entry point for education and interdisciplinary work. The authors identify teaching dynamic modeling and parameter estimation, as well as collaboration with experimental biologists who need to inspect data, models, and fits without writing code, as particularly relevant settings. Testing was performed on problems of various sizes from the PEtab-Benchmark collection: all benchmark problems could be opened, medium-sized problems were handled without noticeable lag, and larger problems remained usable despite slower live plotting and filtering (Jost et al., 14 Nov 2025).

Several limitations are explicit. The GUI’s reactivity is computationally expensive for large models and very large measurement tables. Highly specialized or non-standard workflows may still be better served by script-based manipulation of PEtab and SBML. Most importantly, parameter estimation itself is not yet integrated as a graphical workflow: the current emphasis is on problem specification, inspection, and basic simulation, not on running optimizations, advanced inference, or cluster-based jobs. Planned future directions include support for running parameter estimation, selection of optimizers and simulators, handling cost-intensive optimization runs including offloading to clusters, and maintaining compatibility with future PEtab versions and PEtab-related standards such as PEtab Select (Jost et al., 14 Nov 2025).

PEtab-GUI is distributed as open-source software under a 3-Clause BSD license, with source code hosted on GitHub and installation available from PyPI. It requires Python 3.11, and cross-platform support is provided through PySide6/Qt for Linux, macOS, and Windows. In the broader systems-biology context, its principal significance is not to redefine parameter estimation, but to convert the abstract, multi-file PEtab specification into an interactive authoring environment that preserves standardization, reproducibility, and interoperability while reducing the practical burden of constructing PEtab problems (Jost et al., 14 Nov 2025).