Docs: v1→v2 migration guide (incl. parameter scaling) and comparing objective values across tools
@dweindl arbeitet bereits daran.
Seit 14.10.2026.
Bewertung
Dieses Issue wurde noch nicht bewertet.
Beschreibung
I propose two non-normative documentation pages. Both come from problems we ran into while converting the benchmark collection to v2 (Benchmarking-Initiative/Benchmark-Models-PEtab#333).
1. Migration guide, "Upgrading from PEtab v1"
"Changes from PEtab 1.0.0" lists what changed, but not what a change means for an existing problem, or how to convert a problem so that it stays the same estimation problem. Parameter scaling is the main gap. The spec only says that parameterScale was removed because its "interaction with parameter priors was not well-defined", and that "the model parameters can be transformed in the model file".
Proposed content for parameter scaling:
- What v1 specified: bounds and nominal values on linear scale;
parameterScale*priors on the scaled parameter;parameterScaleUniformas the default, "equivalent to no prior". v1 left open whether other priors on a log-scaled parameter are densities overxor overlog10 x(#402). - How v1 tools implemented it:
- D2D and pyPESTO evaluate priors as densities over the scaled parameter, without a Jacobian (D2D
arCollectRes.m, pyPESTO). - libpetab's v1
Priorevaluates them as densities overx, with the Jacobian (priors.py). - Gradients are commonly reported with respect to the scaled parameters (e.g., AMICI, pyPESTO), and start points are sampled on the parameter scale.
- Other tools still to be surveyed.
- D2D and pyPESTO evaluate priors as densities over the scaled parameter, without a Jacobian (D2D
- Consequences: for log-scaled parameters with priors, objective values and optima differ between tools. Gradients differ by a factor of
x·ln(10)per parameter. - In v2: no parameter scale; priors are densities over the parameter as used in the model; the objective is fully defined.
- How to reproduce a v1 problem exactly: a step-by-step reparametrization. This covers a new parameter
log10_kwithk = 10^log10_k(e.g., an initial assignment), transformed bounds, nominal values and priors, and substitution in observable/noise formulas and overrides for parameters that don't appear in the model.- Options for defining
k = 10^log10_kin an SBML model: an initial assignment keepska constant entity (it can still be a condition target) and is sufficient, sincelog10_kis constant. An assignment rule also works, but makeskan algebraic entity, so it can no longer be a condition or event target; its only advantage is robustness in tools that don't re-evaluate initial assignments after changing parameter values. Substituting10^log10_kinto all model expressions and removingkloses its annotations and changes every kinetic law; settingkin the condition table for each experiment spreads the model definition over the experiments. - Measurement table overrides cannot be expressions, so
10^log10_kcannot be substituted there. Instead, the placeholder is transformed (ph→10^phin the observable/noise formula), and all overrides of that placeholder are log-transformed (k→log10_k, a numberc→log10(c)). - This fails if the same placeholder also receives non-positive numbers or parameters that stay on linear scale. Then, the observable should be split, so that each copy's placeholder only receives overrides that can be log-transformed, or none at all. This reproduces the v1 problem exactly. Keeping the parameter on linear scale instead is not recommended: it changes the parametrization, and, with a uniform prior, shifts the log-prior by a constant (uniform on linear scale instead of on log scale).
- Options for defining
- What
petab1to2does and what it preserves. ExplicitparameterScaleNormalpriors becomelog-normal(keeps the distribution, moves the optimum). Unspecified priors becomeuniform(lb, ub)(keeps the optimum, changes the distribution). PEtab-dev/libpetab-python#535, PEtab-dev/libpetab-python#536.
Other changes with numerical consequences that should be covered:
- the removal of
log10-normalnoise (rescale the noise parameters); - the removal of initialization priors;
- bounds now truncating priors;
- the default
uniform(lb, ub)prior, which adds a constant to the objective as soon as any parameter has a prior.
2. "Comparing objective values across tools"
For PEtab v1 and v2 alike: why the same problem gives different objective values in different tools, and how to convert between them. These mismatches are common in practice. AMICI's benchmark-model tests document, per problem, how the reference values of the original benchmark collection relate to the PEtab log-likelihood: a factor of 1/2 or −1/2, a sign, a log10 correction term, χ² instead of the log-likelihood, priors included, and one unexplained mismatch (Schwen_PONE2014). Draft outline:
| Effect | Typical causes |
|---|---|
| Constant offset | Normal noise: omitting 0.5·log(2π) per data point, or log σ for fixed σ (if σ is estimated, omitting log σ changes the optimum) · log-normal noise: omitting the Σ log y term of the measurements, and log(ln 10) per data point for log10 · prior normalization constants omitted or partly included (D2D adds log(2π) per prior but no log σ, arGetMerit.m) · priors truncated by the bounds but not renormalized · v2 default uniform(lb, ub) prior (Σ ln(ub − lb)) |
| Sign and factor | log L versus −log L · −2 log L (χ²-style, e.g., D2D) instead of −log L · residual sums of squares |
| Terms included | Likelihood only (ML) versus likelihood plus priors (MAP) · only the χ² part of the likelihood, without the σ-dependent terms |
| Parameter-dependent difference (moves the optimum) | v1 priors on log-scaled parameters read as densities over the scaled or the linear parameter (see above) |
| Derivatives | Gradient/Hessian with respect to scaled or linear parameters |
| Numerical | Integration and steady-state tolerances |
Each entry would give the conversion formula. A worked example (e.g., Boehm_JProteomeRes2014) would show the PEtab-defined value next to the values reported by major tools and the original reference value. I'd verify the tool-specific statements with the tool developers before publishing.
Relates to #402.
🤖 Drafted with AI assistance
- Vorherrschende Sprache
- Keine Sprachdaten
- Sterne
- 67
- Forks
- 16
- Ø Merge
- 1 T. 19 Std.
- Gemergte PRs (30 T.)
- 1
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Keine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus PEtab-dev/PEtab
-
Schwierigkeit 4/5 1-2 Tage Anfängerfreundlichkeit 55/100
-
v2
Schwierigkeit 4/5 1-2 Tage Anfängerfreundlichkeit 20/100
-
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 25/100
-
Poisson and negative binomial distributions for parameter priors and noise modelsEvtl. vergeben @dweindl hat das vor 325 Tagen übernommen. Offenv2
PEtab-dev/PEtab#653 · 3 Kommentare · 1 Reaktion · 1 zugewiesene Person ·
-
v2: Add how-tosOffendocumentation
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 25/100