I am an experienced-Simulink user who is trying to move to Julia. My goal is to develop discrete-time(probably stochastic) systems. As a former Simulink user, I always think in terms of block diagrams and signal flows. Recently I discovered that this kind of “time-based” thinking is called causal or assignment-based design. Another approach used by programs such as Modelica is a noncasual or equation-based design, with which I have no experience.
I found that Causal.jl would be the perfect package for me. However, even though some claim that ModelingToolkit.jl focuses solely on the noncasual approach, its documentation states that it is possible to implement both casual and noncasual models.
Which one should I use? Casual or noncasual? Causal.jl or ModelingToolkit.jl? the latter has a larger community, but its documentation examples use approaches I am not used to.
Acausal modeling is a strict generalization of causal modeling. Acausal modeling where you only link inputs to outputs is causal modeling. But, in order to support acausal models, one needs to be able to compiler transformations to the code in order to reduce the index of the DAEs. Because of this, acausal modeling systems need to have a system for doing a lot of optimizations to the global system, which is what generally makes them fast.
But, causal modeling systems live in a much restricted space, so they do not require this more general compilation system. This means every box can be treated in isolation, and can even be solved in isolation instead of in the whole. This is what is then seen in causal modeling frameworks, where they both don’t include an optimizing compiler but allow for integers in a per block mode. This makes them generally slow, but flexible: you can have an SDE in one block and an ODE in another.
Technically if you look globally, an ODE with one stochastic term is a stochastic differential equation. Acausal systems, which have one global solve, would need to use an SDE solver for the whole system, whole causal modeling systems can use an SDE solver in one part and an ODE solver in another. That is technically incorrect due to regularity, but you can do it easily.
So anyways, Causal.jl can do stochasticity more easily by having stochastic blocks mix with normal blocks, and then just solve. But technically this will lead to order loss in the ODE solver because every time point is non differentiable. ModelingToolkit can handle SDEs with SDESystem but currently the acausal simplifications for this case are WIP (with an open PR). This should keep improving, but doing it “right” is a very big task. That’s continuous stochasticity. For discrete, it’s numerically easy with acausal modeling but not easy to do in MTK right now because we need to extend the interface.
But anyways, acausal modeling is important for many reasons and so we have a strong focus on it, so you will find much more of a community and a push around it.
@ChrisRackauckas I appreciate your thorough answer, but your answer was quite complex and not helpful in deciding which one to use in which situation. My question is not “how causal and acausal modelling works”, but “Which one should I use?”. I bet both frameworks are pretty complex with many mathematical issues, but I hope not to need to understand all of it to start using Julia for the field I just mentioned. Mathematical modelling is not my field of expertise. For me, it is just a tool that I use to validate my systems.
If you’re happy with Simulink, chances are the acausal/causal distinction won’t matter for you. MTK has a lot of potential to do much more than Simulink, but you probably don’t care about mixing up input-output relationships. What MTK does not currrently have is an easy way to assemble systems by drawing a bunch of blocks in a GUI, with mix of discrete & continuous time indicated by clicking & dragging. It also doesn’t have a way to automatically generate C code and download to an embedded controller. OTOH the GUI block diagrams quickly become spaghetti and (historically) hard to do version control.
Depends on your application whether MTK will work for you, but for now everything needs to be code, not diagram.
@artkuo Nice contribution. I do not care about using GUI or drag&drop diagram blocks, although it makes it easy despite the drawbacks in version control… The biggest advantage for me (and the part I got most used to) is the time-based system approach. I do not know about you all, but I am from the signals and systems realm, and Simulink offers a processing model based on temporal support that is rather effective for discrete-time signal processing: at each instance, a sample inputs the system, and a sample outputs it. Every once in a while, in a multi-rate task, one can have different sampling rates in the same system (which is easily identified on Simulink by different colors). I wish to move to Julia because I am an enthusiastic about this language, but I need to admit that the Simulink approach is very effective, especially for signal processing. That’s what I care about.
At first glance, Causal.jl seems to fit better on my requisites as its README.md file focus on the time-based system design, but I am afraid of getting a wrong feeling about ModelingToolkit.jl since it is quite broad and somehow generic. ModelingToolkit.jl can even have more functionalities than Causal.jl since it has a larger community.
In general, I like buying into the SciML packages because they are consistent, so learning one is kind of learning them all. Also they are ambitious in scope, and activly developed.
But the examples from Causal.jl looked nice. I would say that you should make a small example problem of the type of thing you want to do, implement it in both packages, and listen to your gut feeling about which is best. You then have a feeling for speed, syntax, the documentation etc for both packages.
It is ultimatily up to what YOU like, so the answer you will find yourself will be better than what some random person on the internet will tell you to do.
If you do this, feel free to post your experiences here
Yes, do whatever you feel is appropriate, that’s the main tl;dr. Though if you haven’t read it yet, there is a nice survey of acausal vs causal modeling, where there is a big push in the area to go towards “everything should be acausal modeling”, but it’s more complex so the tools take longer to get developed.
But tl;dr, ModelingToolkit has a large community and the SciML group involved so you’ll see a lot more movement and if you ask questions someone is pretty much guaranteed to respond (at least I will or I will forward it to the right person). But acausal modeling is more complex so getting MTK to “its final form” will take a big chunk of work: it’s very useful today, but it’s not quite “there” yet.