[dweindl]

PEtab v2 has no parameterScale. Converting a v1 parameterScaleNormal(μ, σ) prior on a log10-scaled parameter to log-normal(μ ln10, σ ln10) keeps the prior distribution, but adds a Jacobian term to the v2 MAP objective, which moves the optimum by −σ² ln10 decades. No v2 prior over the unscaled parameter can preserve both the distribution and the optimum.

petab1to2 and petab_files_1to2 get a reparametrize argument, which uses petab.v2.reparametrize_log (#560) to estimate log10_<id> (or log_<id>) instead of <id>:

• "none" (default): current behaviour, now with a warning for converted parameterScale* priors
• "priors": log-scaled parameters with parameterScale* priors
• "all": all estimated log-scaled parameters without priors on linear scale (i.e., without logNormal, uniform, ...); this also preserves the v1 default prior (uniform on parameter scale)

Log-scaled parameters sharing a placeholder with selected parameters are added. Such placeholders are substituted by 10^placeholder, so numeric overrides are log-transformed. Since overrides must be finite, 0 overrides are replaced by a new fixed parameter negative_infinity with nominal value -inf (assuming PEtab-dev/PEtab#687 is accepted). With "all", parameters without parameter-scale priors are skipped (with a warning) if their placeholder can't be log-transformed, i.e., if it is also overridden by negative numbers or by parameters that are not reparametrized. Parameters with lowerBound = 0 (allowed in v1 for log-scaled parameters with an initialization prior) get lowerBound = -inf on log scale (PEtab-dev/PEtab#682). They are skipped with a warning if their prior on log scale would be an improper uniform prior, i.e., the v1 default prior if other estimated parameters have priors.

Also fixes petab1to2 adding default uniform priors to non-estimated parameters, and to all parameters if the v1 parameter table has an objectivePriorType column, but no estimated parameter has a prior. Priors of non-estimated parameters are converted as before.

Non-estimated parameters are only reparametrized if they share a placeholder with selected parameters. A nominal value of 0 then becomes -inf, assuming PEtab-dev/PEtab#685 / PEtab-dev/PEtab#687 is accepted. Their parameterScale* priors are converted to log scale as well, unless they depend on missing bounds (then they are dropped with a warning).

Checked on the benchmark collection: all 35 problems convert and pass v2 linting with "all" (now also tested in CI); with "priors", 44 parameters are reparametrized in Bachmann, Isensee, Raimundez and Schwen.

Checked with AMICI (v1 importer vs. v2 PetabImporter, forward sensitivities) on 30 benchmark problems converted with "all" (5 large ones excluded), at the nominal parameters and at a shifted point: log-likelihoods agree to a relative difference of ≤ 2e-8, and gradients agree to ≤ 2e-5 of the largest gradient entry, except for Crauste at the nominal parameters (4e-4 at rtol/atol 1e-12/1e-16, decreasing with tighter tolerances; 5e-14 at the shifted point). The remaining deviations are due to integration tolerances. Log-priors are identical for Bachmann, Isensee and Raimundez. (Before the 0 overrides were supported, 6 log-scaled Bachmann parameters couldn't be reparametrized, and their v1 default prior became a linear uniform, which preserves the MAP, but changes the log-prior by a constant.)

The default is "none" for now, to keep petab1to2 uninvasive, i.e., to not change the parametrization unless requested. Open to change.

References Benchmarking-Initiative/Benchmark-Models-PEtab#333, PEtab-dev/PEtab#680, PEtab-dev/PEtab#683

🤖 Generated with Claude Code

[codecov-commenter]

Codecov Report

❌ Patch coverage is 97.56098% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 79.47%. Comparing base (ce80233) to head (b7133f4).

Files with missing lines	Patch %	Lines
petab/v2/petab1to2.py	97.34%	1 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #539      +/-   ##
==========================================
+ Coverage   79.06%   79.47%   +0.40%     
==========================================
  Files          70       70              
  Lines        8164     8278     +114     
  Branches     1463     1498      +35     
==========================================
+ Hits         6455     6579     +124     
+ Misses       1220     1209      -11     
- Partials      489      490       +1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[dilpath]

gradients agree to ≤ 4e-4 of the largest gradient entry

This error is potentially too large?

if their placeholder can't be log-transformed (e.g., Bachmann has 0 offsets)

What is the issue here? So, exp(log_offset) does not work for some reason?

For Bachmann, they differ by a constant

Will mean that e.g. a single metadata file in the benchmark collection is insufficient (...unless the metadata file has version-specific information).

[dweindl]

gradients agree to ≤ 4e-4 of the largest gradient entry

This error is potentially too large?

Yes, it is large, but this is only Crauste and it seems to be about integration errors at those specific nominal parameters, not conversion issues. At the shifted point, the deviation is several orders of magnitude smaller.

if their placeholder can't be log-transformed (e.g., Bachmann has 0 offsets)

What is the issue here? So, exp(log_offset) does not work for some reason?

The problem occurs if we have a observableFormula with a placeholder that is sometimes a log-scaled parameter, and sometimes a non-positive number. In this case, we'd have to split the observable into one version with base^placeholder, and one with just placeholder. Feasible, but not implemented here.

For Bachmann, they differ by a constant

Will mean that e.g. a single metadata file in the benchmark collection is insufficient (...unless the metadata file has version-specific information).

This is due to the missing observable splitting. This could be built on top, but I am not sure it's worth it.

Independently of that, we might have the version-specific-information problem also in the case truncation of the prior by the bounds. Depends on how we handle that for v1, where this was unspecified. But that's a discussion for https://github.com/Benchmarking-Initiative/Benchmark-Models-PEtab.

[dilpath]

gradients agree to ≤ 4e-4 of the largest gradient entry

This error is potentially too large?

Yes, it is large, but this is only Crauste and it seems to be about integration errors at those specific nominal parameters, not conversion issues. At the shifted point, the deviation is several orders of magnitude smaller.

👍

if their placeholder can't be log-transformed (e.g., Bachmann has 0 offsets)

What is the issue here? So, exp(log_offset) does not work for some reason?

The problem occurs if we have a observableFormula with a placeholder that is sometimes a log-scaled parameter, and sometimes a non-positive number. In this case, we'd have to split the observable into one version with base^placeholder, and one with just placeholder. Feasible, but not implemented here.

Why is 0 an issue? Since for v2 we define log(0)=-inf -- it's not explicitly there but I would therefore assume that exp(-inf)=0 -- so splitting would not be required?

For Bachmann, they differ by a constant

Will mean that e.g. a single metadata file in the benchmark collection is insufficient (...unless the metadata file has version-specific information).

This is due to the missing observable splitting. This could be built on top, but I am not sure it's worth it.

Independently of that, we might have the version-specific-information problem also in the case truncation of the prior by the bounds. Depends on how we handle that for v1, where this was unspecified. But that's a discussion for https://github.com/Benchmarking-Initiative/Benchmark-Models-PEtab.

Yes agreed, fine for me, was just pointing out.

[dweindl]

The problem occurs if we have a observableFormula with a placeholder that is sometimes a log-scaled parameter, and sometimes a non-positive number. In this case, we'd have to split the observable into one version with base^placeholder, and one with just placeholder. Feasible, but not implemented here.

Why is 0 an issue? Since for v2 we define log(0)=-inf -- it's not explicitly there but I would therefore assume that exp(-inf)=0 -- so splitting would not be required?

Same issue as PEtab-dev/PEtab#687 -- so far, placeholder overrides are restricted to finite values or parameters. Intentionally or not, not sure. I guess there could be use cases. Maybe drop a comment there if you think we should extend that to observableParameters and noiseParameters.

With PEtab-dev/PEtab#687 pretty much accepted, this can be circumvented by adding a fixed parameter negative_infinity = -inf. This doesn't address the negative values, but that seems to be an even more special use case. I can implement that.