Resolve original condition ids in reinit - #3230
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3230 +/- ##
==========================================
- Coverage 78.59% 78.52% -0.07%
==========================================
Files 318 318
Lines 21106 21122 +16
Branches 1487 1488 +1
==========================================
- Hits 16589 16587 -2
- Misses 4509 4527 +18
Partials 8 8
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
45e3dde to
5aed7ce
Compare
|
@dweindl does this look good to you? |
dweindl
left a comment
There was a problem hiding this comment.
Thanks, looks good to me.
I was just wondering whether it might not be easier to just store the mapping during import instead of reverse engineering it later, but fine as is.
I tried this out but found it didn't simplify the code much (or speed it up). I think it's slightly easier to follow if all the resolution is done together. |
Updating the function
_condition_reinit_target_valueto resolve conditions ids in the same way as_eval_nndoes, while preserving gradient tracing.The context in which I noticed this bug was a JAXProblem built from a PetabImporter instance. The underlying petab problem contained conditions which modified a model state variable. The PetabImporter changes the names of conditions and condition targets as part of import which is why
_eval_nnneeds to resolve current condition ids to originals, and why_condition_reinit_target_valueshould do the same.