-
-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add stats to ensemble solution #512
Conversation
src/ensemble/basic_ensemble_solve.jl
Outdated
function merge_stats(us) | ||
mapreduce(x -> x.stats, merge, us) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not safe for if stats is nothing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, this merge is not defined for most stats types?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh no... there are more stats types? Well of course there are. Tbh the hardest part of adding Ensemble statistics is figuring out where all the stuff lives. Do you have a better idea to provide Ensemble stats, or do I just need to hunt down every stats object in the SciML ecosystem and implement a merge method for it? Or can I just handle the nothing case and catch the case where merge isn't defined and if some obscure type of system wants Ensemble stats they can go and add it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think what we should do is just move the diffeq stats object to SciMLBase and then add the merge function here. That would put it more inline with how the other bits are developing, like https://github.com/SciML/SciMLBase.jl/blob/master/src/solutions/nonlinear_solutions.jl#L2-L18. Since it doesn't require downstream functionality and is instead part of the general interface, it's a bit weird that Stats (which should be DEStats) is not in SciMLBase but is instead in DiffEqBase. That's just an organizational mistake. Can you make that swap as part of this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That seems quite a delicate dance of breaking changes and version bumps/pins all over SciML that I'm not sure I'm the right person to make.
https://github.com/search?q=org%3ASciML+%22DiffEqBase.Stats%22&type=code
Handling the nothing case and method error is done though.
Rebase? |
darn I thought I could quickly do it from the web interface but it did a merge. Something for tomorrow I guess. |
It occurred to me that the move might be simpler than I thought.
From there packages can slowly transition, no need for me to try to transition the entire ecosystem in one go |
d1c0a8d
to
fe2f12b
Compare
Made a start: |
Codecov Report
@@ Coverage Diff @@
## master #512 +/- ##
==========================================
+ Coverage 47.36% 55.07% +7.71%
==========================================
Files 53 54 +1
Lines 3921 3980 +59
==========================================
+ Hits 1857 2192 +335
+ Misses 2064 1788 -276
... and 23 files with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
Needs to import printf |
counterpoint: just use |
Derp sorry |
looks like reduction options aren't handled: https://github.com/SciML/SciMLBase.jl/actions/runs/6477667738/job/17588215082?pr=512#step:6:989 |
Is there an easy way to run some relevant set of tests to avoid a bunch more round trips like this 🙈 |
I think I managed to run tests with just doing I'm not sure if I'm totally happy with how I handled reductions now. It makes sense that if you're doing custom reduction there isn't much to merge. Another option would be to just try and fail. Another option would be to try and do the check at the type level so the compiler has a better chance to figure out type stability. |
I guess if we want to do it absolutely breakage-free I should split up the move into a separate PR, so we can do
[edit] oh nvm I see you handled that in https://github.com/SciML/DiffEqBase.jl/pull/949/files#diff-4707ffacbf76401dc918e8bfac5bf57023ff087628a2b6d2b741f943d972fa1cR1 |
@oscardssmith did this happen because of one of your recent changes? Can you investigate this breakage? https://github.com/SciML/SciMLBase.jl/actions/runs/6479781338/job/17731840088?pr=512#step:6:1003 |
Looks like there's still downstream breakage: https://github.com/SciML/SciMLBase.jl/actions/runs/6531788842/job/17734231446?pr=512#step:6:1470 |
I'd still like to know how I can run a useful set of test locally because I did run the "Downstream" testset which didn't catch this. I'll have a closer look tomorrow what is causing this, yet another case of custom output function it seems. Will this ever end haha |
It should just be the same as running the downstream tests? No different locally, nothing crazy. But you maybe had some extra things dev'd that fixed it. |
Turns out it was the Downstream tests of DiffEqBase that failed while I was running the Downstream tests of SciMLBase only. |
@ChrisRackauckas Is this good to merge now? |
No there's still ensemble tests failing from this. |
It's completely opaque to me which of these CI things are actually relevant and what they mean. I think I saw some errors about enzyme complaining about if statements and a random one I pressed just now complained about a missing adjoint. Feels like I need a math PhD and grok the entire sciml ecosystem to add a field to a struct. |
This change is at a very low level and is effecting an interface used by tens of thousands of people for many diverse reasons. It should be taken seriously. Uniformity in interfaces requires that interface changes are thought through with a global view. Otherwise the ODEs won't work the same as the nonlinear solvers and the jump problems and then SciML loses its ease of use. So yes, changing the core interface isn't and shouldn't be easy to do. For this case, we can't just merge when tests are saying automatic differentiation is failing. Ask for help if you need it, I'm always willing to help, but we're not going to push something through that breaks AD |
Sorry yes it makes sense it's just hard to make sense of the CI output as a relative outsider to much of sciml. |
Hurray tysm! |
This is based on SciML/DiffEqBase.jl#938
Example