Skip to content
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

Please allow changing VectorContinuousCallback during affect! calls #1052

Open
evan-wehi opened this issue Sep 19, 2024 · 1 comment
Open
Assignees

Comments

@evan-wehi
Copy link

Is your feature request related to a problem? Please describe.

I’m modelling cell population dynamics. Cells die and divide so the size of system is always changing. Most of my state variables can trigger events (i.e. death or division) so it seems that VectorContinuousCallback is the way to go. Unfortunately, the constructor for VectorContinuousCallback requires the length of the returned vector which in my case will change frequently. I could specify a very large length and pad the return vector with non-zero values but that seems inelegant and inefficient.

Describe the solution you’d like

To able to change the length of the returned vector. Changing during a affect! call is adequate for my use case.

Describe alternatives you’ve considered
As suggested on the julialang forum: "a single ContinuousCallback that is the multiplication of conditions and then calculate which one had the crossing." I haven't tried this yet but seems like it should work.

Additional context

@evan-wehi
Copy link
Author

I've started looking at this. I'm happy to have a go at it (it is important for me).

Should I open an issue in OrdinaryDiffEq.jl?

@ChrisRackauckas suggested an approach here: https://discourse.julialang.org/t/changing-the-size-of-vectorcontinuouscallback/119534/7?u=evan-wehi. Perhaps I didn't understand but I'm not sure this will work. It seems to assume the size of the VectorContiniousCallback is the same size as the state vector which I think is not always true (it is not in my use case). Also, there may be more than one call back.

Would it be enough to provide a couple of functions:

function resize!(cb::VectorContiniousCallback, i::Int)
function deleteat!(cb::VectorContiniousCallback, i::Int)

where cb is the original callback. This would be used to find the correct callback in integrator.opts.callback. Is it then simply case of changing the len field. Do I need to do anything with the entries under integrator.callback_cache other than make sure they are long enough?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants