[dweindl]

Adds petab.v2.Problem.get_unused_id(base, *, exclude=()), which returns base if it is unused, otherwise the first unused base_1, base_2, .... It treats an ID as used if it is any of the following:

• a PEtab entity ID (parameter, observable, condition, experiment, mapping)
• a condition target
• a model entity ID
• a symbol in an observable or noise formula, a condition target value or a measurement override

assignments_to_experiments now uses it for its new cond_<n> conditions. Before, it only checked condition IDs, so it could create a condition with the ID of, for example, a parameter.

exclude is for choosing several IDs before adding the corresponding entities to the problem.

🤖 Generated with Claude Code

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 78.19%. Comparing base (da74567) to head (eb3c412).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #561      +/-   ##
==========================================
+ Coverage   78.07%   78.19%   +0.11%     
==========================================
  Files          68       68              
  Lines        7823     7842      +19     
  Branches     1399     1400       +1     
==========================================
+ Hits         6108     6132      +24     
+ Misses       1227     1224       -3     
+ Partials      488      486       -2     

☔ 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]

Thanks!

[dilpath]

Is this necessary? If it's to account for SBML model IDs, isn't that already done above, specifically:

or any(m.has_entity_with_id(id_) for m in self.models)

targetId must be a reference in the condition table (I assume), and therefore redundant here.

[dweindl]

Technically you are right. If the PEtab problem is valid, this would be covered. If not – for example, if the target ID is not defined in the model yet – a newly added entity with the just checked ID might make it valid and unintentionally cover up the initial error. It's a bit hypothetical, but I guess I'd just leave it in there unless it turns out to be a performance bottleneck.