# Mixing time-discrete and time-continuous systems in a simulation

**URL:** https://discourse.julialang.org/t/mixing-time-discrete-and-time-continuous-systems-in-a-simulation/74277
**Category:** Modelling & Simulations
**Tags:** question
**Created:** [January 9, 2022, 11:44am UTC](https://discourse.julialang.org/t/mixing-time-discrete-and-time-continuous-systems-in-a-simulation/74277 "2022-01-09T11:44:17Z")
**Posts on this page:** 3
**Page:** 2

<div class="post-metadata">

### Author: ![mzaffalon](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mzaffalon/32/214168_2.png) [@mzaffalon](https://discourse.julialang.org/u/mzaffalon)
#### Post date: [April 17, 2025, 8:23pm UTC](https://discourse.julialang.org/t/mixing-time-discrete-and-time-continuous-systems-in-a-simulation/74277/21 "2025-04-17T20:23:42Z")

</div>

Thank you for the pointer, @Ronis_BR. The [DifferentialEquations.jl](https://github.com/SciML/DifferentialEquations.jl) page even provides an [example](https://docs.sciml.ai/DiffEqDocs/stable/features/callback_functions/).

---

<div class="post-metadata">

### Author: ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)
#### Post date: [April 17, 2025, 8:45pm UTC](https://discourse.julialang.org/t/mixing-time-discrete-and-time-continuous-systems-in-a-simulation/74277/22 "2025-04-17T20:45:45Z")

</div>

> [@ufechner7](#):
>
> What stops you from using the integrator interface?

> [@Ronis\_BR](#):
>
> Sorry for the delay. I removed the tutorials because they use a feature that is now deprecated and I am not sure it is still working.

For reference, the deprecated feature was:

> **[GitHub - SciML/DEDataArrays.jl: A deprecated way of handling discrete data in...](https://github.com/SciML/DEDataArrays.jl)**
>
> A deprecated way of handling discrete data in continuous equations

The problem with DEDataArrays is that they store the discrete values in the array `u`. At first, this makes sense: `u[1], u[2], ...` are continuous, and you add `u.a = ...`. Then you update the `u.a` in the integrator interface. Cool.

The issue is that it ends up being very bug prone, and it’s not necessarily possible to fix all of the bugs. The bug deals with broadcast. Let’s say you have a DEDataArray with one discrete value, so:

```julia
u = DEDataArray([1.0,2.0], 1.0)
v = DEDataArray([3.0,4.0], 1.0)
u .+ dt .* v

```

How is `u .+ dt .* v` defined? Well this is happening as a continuous update step of the ODE solver, so if the `1.0` is a discrete-time updating quantity, then it shouldn’t be changing. So the definition is to keep the discrete value and do the broadcast on the continuous parts, i.e. `DEDataArray([4.0,6.0], 1.0)` is the solution. Great!

But what about

```julia
u = DEDataArray([1.0,2.0], 1.0)
v = DEDataArray([3.0,4.0], 2.0)
u .+ dt .* v

```

This can happen after you had a callback with an `affect!(integrator) = integrator.u.a = 2.0`, so you updated the value. But there’s other cache array in the integrator. What you want do to is update the value of the discrete time to the “new value”… but how do you know that `2.0` is the new value?

The implementation trick that was done for a bit was to have it dependent on broadcast ordering, so here if we define broadcast to take the discrete value of the last DEDataArray in a broadcast expression, then the answer is `DEDataArray([4.0,6.0], 2.0)` and perfect, you propagated the updated value!

But… this should sound… scary. What if someone does a PR to the ODE solver and reorders a few arrays? Yeah… the exact ordering of the arrays in the broadcast expressions was required and if that was messed up, oops the test now fails. If that sounds brittle that’s because it is.

Ultimately, we couldn’t find a solution to this that would make it robust. And “just make sure we test it well enough so that we put the arrays in the right order” isn’t a great answer, because it can mean the ODE solver works well, but then what if they put it in a machine learning library, or an optimizer… how do we teach the whole Julia ecosystem to do this correctly? So ultimately, it was just a bug-prone way to keep and propagate the information.

The real answer from this is the following phrase:

> Don’t mix implementation with representation.

You want to make it simple to represent a mixed discrete-continuous simulation where the discrete is part of the state that is being evolved, but that doesn’t mean you actually want to put the discrete values into the array that is being evolved! You want to make the representation easy, but the implementation can be different from the representation.

This of course leads to ModelingToolkit, which symbolically models the whole system to give a representation, but then it does codegen to do an optimal implementation, which may not match 1-1 the representation. For MTK, discrete values are stored inside of the parameters, because that’s the good way to implement, but not necessarily the best user-interface to the solver. So MTK hides the complexity.

Anyways, the answer of course then is that it was deprecated in favor of ModelingToolkit which can have interfaces here that are bug-free, or at least, any bugs are at least fixable in principle and so we keep being able to improve it 😅. Unlike DEDataArray which is fundamentally not able to solve that issue.

---

<div class="post-metadata">

### Author: ![tuckermcclure](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tuckermcclure/32/1187_2.png) [@tuckermcclure](https://discourse.julialang.org/u/tuckermcclure)
#### Post date: [September 11, 2026, 5:23pm UTC](https://discourse.julialang.org/t/mixing-time-discrete-and-time-continuous-systems-in-a-simulation/74277/23 "2026-09-11T17:23:15Z")

</div>

Hi @tqml. To mix a new package into the potential set of solutions here, I wonder if the following is useful for you for this kind of thing? It’s certainly designed for the use case you’re describing. Maybe helps?

> [@\[ANN\] SystemsOfSystems.jl, a simulation engine](https://discourse.julialang.org/t/ann-systemsofsystems-jl-a-simulation-engine/139359):
>
> Hi all. I’d like to announce a new package for simulating models that contain models that contain models, etc., where the models can have both continuous and discrete parts. I needed a system like this to work with modular components of control systems, and it has been working well for the teams I work with, so I hope it can be useful to the broader community. As a teaser, here is an extremely simple, one-model simulation: using SystemsOfSystems constants = (; mass = 1., kp = 8., # Pr…

[Previous page](https://discourse.julialang.org/t/mixing-time-discrete-and-time-continuous-systems-in-a-simulation/74277.md?page=1)
