Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

PEtab export ignores the postprocess key, so a job whose fit scores script-transformed simulations exports as a problem that scores the raw ones, without an error

Open Beginner friendly
#899 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
76/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
python
Domain
backend, data

Research direction

Read the prediction-transform refusal checks in pybnf/petab/export.py:188-190 and compare them with how conf['postprocess'] is loaded in pybnf/config.py:4235. Reproduce with the edition-2 demo configuration and confirm that export currently completes without a warning. Done means export refuses jobs using postprocessing, consistently with the documented PEtab v2 boundary in docs/petab.rst.

Written by the indexing model from the issue text.

Description

bug silent-incorrectness

PEtab export ignores the postprocess key, so a job whose fit scores script-transformed simulations exports as a problem that scores the raw ones, without an error

export_job refuses the PyBNF prediction transforms that PEtab cannot express: _reject_cumulative, _reject_time_error and _reject_normalization (pybnf/petab/export.py:188-190). It never reads conf['postprocess'], and nothing under pybnf/petab/ mentions the key.

The fitter does apply the script:

  • Configuration._load_postprocessing (pybnf/config.py:4235) maps each (model, suffix) to the script. Under edition 2 the experiment name serves as the suffix.
  • Result.postprocess_data (pybnf/algorithms/core.py:84-110) then replaces the simulation with postprocess(data) before it is scored.

A user script is an arbitrary transform of the prediction, and PEtab has no way to represent one. Normalization is refused for the same reason. The export instead writes the bare model column as the observableFormula. The problem it emits has a different objective and a different optimum from the fit, and nothing warns about it. That breaks the contract in docs/petab.rst: anything PEtab v2 cannot express raises NotImplementedError naming the boundary, and nothing is dropped quietly.

Failure scenario

Take the edition-2 demo job (examples/demo/demo_bng_v2.conf) and add postprocess = pp.py par1, where pp.py multiplies the simulated y column by 10.

  • At the model's values (v1, v2, v3) = (0.5, 1, 3), the fitter's chi_sq is 645387.75. The exported problem gives 0 there.
  • At (0.05, 0.1, 0.3), the fitter's exact optimum (1.07e-33), the exported problem gives 6453.88.
  • export_job completes with no exception and no warning. observables.tsv has func_y y ... normal with no transform, and no output file mentions the script.

Reproduction

In an empty directory, with PyBNF installed and BNGPATH set, copy examples/demo/parabola_v2.bngl and examples/demo/par1.exp from the repository and create these files.

pp.py:

def postprocess(data):
    data.data[:, data.cols['y']] *= 10
    return data

check.conf:

edition = 2
model: parabola_v2.bngl
job_type = check
objective = chi_sq
experiment: par1, data: par1.exp
postprocess = pp.py par1
output_dir = out_check

fit.conf (the demo job plus the postprocess line):

edition = 2
model: parabola_v2.bngl
job_type = de
objective = chi_sq
experiment: par1, data: par1.exp
uniform_var = v1 0 10
uniform_var = v2 0 10
uniform_var = v3 0 10
population_size = 20
max_iterations = 30
postprocess = pp.py par1
output_dir = out_fit
  1. pybnf -c check.conf prints Objective value is 645387.75. With the postprocess line deleted, it prints Objective value is 1.0650618739334988e-33. With the postprocess line kept and the model's values changed to v1 0.05, v2 0.1, v3 0.3 in parabola_v2.bngl, it prints Objective value is 1.0650618739334988e-33.
  2. Run this export:
    import warnings
    from pybnf.petab.export import export_job
    with warnings.catch_warnings(record=True) as w:
        warnings.simplefilter('always')
        export_job('fit.conf', 'petab_out')
    print(w)
    
    It prints []. The func_y row of petab_out/observables.tsv is func_y y noiseParameter1_func_y normal noiseParameter1_func_y.
  3. Score the exported tables by hand. For this model, y = v1 x^2 + v2 x + v3 with x = t - 10:
    import csv
    rows = list(csv.DictReader(open('petab_out/measurements.tsv'), delimiter='\t'))
    def chi_sq(v1, v2, v3, y_scale=1):
        tot = 0.0
        for r in rows:
            x = float(r['time']) - 10
            pred = x if r['observableId'] == 'obs_x' else y_scale * (v1*x*x + v2*x + v3)
            tot += (float(r['measurement']) - pred)**2 / (2 * float(r['noiseParameters'])**2)
        return tot
    print(chi_sq(0.5, 1, 3), chi_sq(0.5, 1, 3, y_scale=10), chi_sq(0.05, 0.1, 0.3))
    
    It prints 0.0 645387.75 6453.8775000000005. The middle value puts the script's ×10 back into the formula, and it equals the fitter's 645387.75 exactly. So the exported problem is the job without its postprocess script.
    • Its optimum is (0.5, 1, 3), where the fitter scores 645387.75.
    • The fitter's optimum is (0.05, 0.1, 0.3), where the exported problem scores 6453.88.

The correct behaviour is to refuse the export, the same way a normalization is refused. That is what docs/petab.rst promises for anything PEtab v2 cannot express.

Reachability

This affects any edition-2 job that uses the documented postprocess key (docs/config_keys.rst, docs/advanced.rst) and is exported through pybnf.petab.export_job. The example script in docs/advanced.rst mean-centres an observable. That is the same kind of whole-trajectory reduction as the built-in normalizations, which _reject_normalization refuses.

Nothing upstream stops the export:

  • parse.py:208 accepts postprocess as a multi-string key.
  • config.py:165 whitelists it.
  • The exporter's refusals match only cumulative, time_error and normalization/analytic_scale.

The earlier exporter audit behind #736 and #738 walked the structural tuple keys. postprocess is a plain list key, so the audit did not cover it.

A _reject_postprocess refusal beside _reject_normalization would close this.

Where

  • pybnf/petab/export.py:188-190: the prediction-transform refusals, with no postprocess counterpart
  • pybnf/config.py:4235: _load_postprocessing
  • pybnf/algorithms/core.py:84: Result.postprocess_data, called from pybnf/algorithms/core.py:394, pybnf/algorithms/base.py:934, pybnf/algorithms/base.py:2223 and pybnf/algorithms/model_check.py:84

Related: #851, #912, #842, #898, #900, #901, #896, #894.

Found in a whole-codebase audit for silently wrong results (2026-09-23); the reproduction above was re-run independently of the original finding.

Dominant language
Python
Stars
25
Forks
25
Avg merge
2h 26m
Merged PRs (30d)
83

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from lanl/PyBNF

All issues in lanl/PyBNF

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.