-
-
Notifications
You must be signed in to change notification settings - Fork 37
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
Provide integrator interface for getting aliased u with ExtendedJumpArrays #229
Comments
Try integrator.u.u .= [1.0,1.0] so you aren't trying to actually change the array but just changing its values. @ChrisRackauckas is there a standard interface to get |
I've updated the I'll leave this issue open as we should also update the main tutorial and/or FAQ to explain a bit about this. |
We might be able to overload |
That would be breaking though right, since |
Reflecting about it more, I think we should add a |
@isaacsas Thanks for your help! Changing it to |
Looking at this, it may be hard to support because the solvers always do |
Which I guess would break the whole purpose of the Otherwise, the solvers shouldn't really be making use of the |
@ttolppanen at this point I have to turn it over to @ChrisRackauckas as this is getting too much into the weeds of the general way that integrators and solution objects work across all of SciML, which is not something I'm particularly familiar with. Hopefully Chris has a suggestion for the @ChrisRackauckas just out of curiosity, would |
They just work fine. The issue is that they don't "hide" the extra pieces from the users. ExtendedJumpArray tries to omit the extra stuff every time you save or print one, which is what causes the issues. We may want to just go with the ComponentArray and just make it more explicit what transformation was done. |
What about dropping the ExtendedJumpArrays, and instead building a functor with internal state for the |
it needs to act like an array for linear algebra to work. |
I meant that the state in integrators and solution objects is just the user’s type. The functor is a wrapper that serves as the ODE’s internal rhs function, and the callbacks’ condition/affects, while storing the jump_u’s. Essentially a VariableJumpAggregation. |
Then how does it participate in the broadcast and all of that in the ODE solving? |
Ahh, got it. Right, the intensities won’t get automatically integrated by that approach. |
Here is the code:
And the error:
If I change the type of the jump to
ConstantRateJump
and print the type ofintegrator.u
in the functionaffect!
, I getVector{Float64}
, but if the type of the jump isVariableRateJump
, then the type ofintergrator.u
isExtendedJumpArray{Float64, 1, Vector{Float64}, Vector{Float64}}
. Is this intented?The text was updated successfully, but these errors were encountered: