refactor: store discrete portion in BlockedArray for efficiency, better handle event variables

[AayushSabharwal]

Checklist

• Appropriate tests were added
• Any code changes were done in a way that does not break public API
• All documentation related to code changes were updated
• The new code follows the
  contributor guidelines, in particular the SciML Style Guide and
  COLPRAC.
• Any new documentation only uses public API

Additional context

Add any other context about the problem here.

[isaacsas]

This looks like a really great addition! I'm just wondering is there any simple way to control saving of the discrete values (and if so could you add it to your nice doc example)?

[AayushSabharwal]

What do you mean "control" saving?

[isaacsas]

My understanding is that the past values of parameters are now being saved if modified via a callbacks as shown in your doc example. Is there a way to disable such saving. (I.e. the current behavior where only the current value is stored.)

[AayushSabharwal]

I see. Yeah, if the parameter is not time-dependent. @parameters c instead of @parameters c(t), it won't be saved. I'll document that better.

[isaacsas]

Just to clarify, if I have a parameter c that I change in a DiscreteCallBack, even just once, with this PR its history will now get saved right (whereas previously no history was saved)? If so, what I was asking was if there could be a documented way to easily turn off this saving process.

[isaacsas]

The idea being that in things like jump problems memory allocations can have a performance impact, so one often wants to turn off all saving beyond what exactly is needed. (This may not seem critical at the level of one simulation, but it can add up when running hundreds of thousands of simulations or more for sampling purposes.)

[AayushSabharwal]

Only if it's declared to have a time dependency (@parameters c(t)). If it's declared as @parameters c, it won't be saved.

[isaacsas]

Got it, thanks for clarifying! My apologies for not understanding that.

[AayushSabharwal]

Right now I don't think anyone does this (please correct me if I'm wrong) so it shouldn't save by default for most simulations.

[isaacsas]

Correct, and setting it up to save only if you make it explicitly time-dependent seems like a nice way to handle this issue.

[isaacsas]

This example in Catalyst https://docs.sciml.ai/Catalyst/stable/model_simulation/examples/periodic_events_simulation/#periodic_event_simulation_plotting_light would actually be a perfect use case for the new functionality, so I'll update that tutorial once this is released.

[AayushSabharwal]

Requires JuliaSymbolics/SymbolicUtils.jl#634