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.
I went back here just to leave feedback for anyone who needs it. I will split it into two parts. Firstly I will talk about how Julia tends to solve problems. In the second part, I will talk about signal processing in Julia.
If you are an Electrical/Electronics/Communications Engineer and are trying to migrate from Matlab to Julia, you will probably seek a nice Simulink-like platform to work with. It turns out you won’t find I feel that Julia has much more mathematicians and computer scientists than Engineers, which naturally leads to fewer tools for us or, at least, tools whose approach significantly differs from ours. Hence, they focus much more on equation-based modelling frameworks instead of input-output and isolated systems. A nice example is the RC Circuit, where you start from the specification differential-algebraic equation. This approach is probably quite weird for engineers who are used to working only with resistances, capacitances, and voltages, as we would do if we were using some Electronic Design Automation. Despite the computational efficiency or any other motivation, it’s how the Julia’s packages were built (at least the ones I saw). So you either get used to working with DAE, ODE, and SDE to simulate your systems or you will not fit well.
However, Julia has a lot of potential to fill this gap in signal processing. The best package I found for it is DSP.jl. There, you can find indispensable tools such as convolution, spectrogram, FFT, filter design, power spectral density, etc… I could make and analyze relatively complex digital filters in Julia. It worked like a charm! However, this package still lacks fundamental functionalities, such as the Matlab’s zplane function and other methods. The main disadvantage is that it is hard to handle complex models, such as multirate or MIMO systems, since the code gets extensive and you do not have a visual insight of your model.
That is platform- and user-dependent. Indeed, compared to line code, it is harder to version control diagram-like models. But the systems do not necessarily get tangled as you make it more complex. It depends on the user experience and the platform. I’ve already done complex but organized system models on Simulink using grouping and masking.
When characterizing the equation-based modeling offered by ModelingToolkit (with all their DAEs and stuff) as science-friendly rather than engineering-friendly, you use an example of an RC circuit. I am afraid that it is not the best example because the engineering domain of circuit modeling and simulation is actually primarily DAE-based, isn’t it? Just consider the good old SPICE language and simulator(s) and have a look at the following SPICE model (aka list) for an RLC circuit (by the way, you can run it using the free LTSpice, unless you have access to another tool)
Every line (except for the first and the last two here) defines an equation, differential or algebraic (although the math formulas are hidden behind the symbols for the element types and a syntax for the interconnection of terminals). Obviously, an everyday engineering tool such as (a) SPICE simulator(s) must be able to handle this DAE.
In this regard, tools like Modelica-based tools and ModelingToolkit are kinda developing further the SPICE approach to modeling – the equation-based modeling. Very much engineering-oriented endeavor.
What you have perhaps in mind is the difference between modeling (and simulating and optimizing) the physics of the engineering system and modeling the algorithms for signal processing (including those used in control systems). Here (in the latter) I agree that Simulink has hardly a competitor right now.
Under the hood, yes. Any electrical circuit with passive components that stores energy (capacitors in the electrical charge or inductors in the magnetic field) leads to a differential algebraic equation, and the DAE’s solution is what we get as system output.
Exactly, that is my point, and that is why I used the RC circuit as an example. In LTSpice you only need to set the values of the passive components and, when needed, declare the initial values of state variables (capacitor voltage and inductor current). So, LTSpice works without you having to worry about declaring the mathematical function that governs that system. It is important to point out that this is not a Julia weakness though. It actually has a good side since it makes you more aware of how the systems behave mathematically. It is just a different approach.
Well, I might be biased I bet there are Engineers who are acquainted with working on DAE and stuff like that.
So, I am afraid to agree. I’m actually quite new to Julia, so I could (and hope) be wrong. But I feel that Simulink’s biggest triumph over Julia is that the former has a signal flow perspective, which is quite convenient when you try to model a communication system, for example, where you have a lot of input-output signals that can feedback the system or go elsewhere, making the line of code much more confusing. Furthermore, Simulink allows multirate systems to work together, and the GUI makes visual inspection of the sampling rate quite simple as it uses colors to differentiate between them:
A GUI platform that aggregates these kinds of visual conveniences and signals flow perspective with mathematical tools would be an exciting competitor to Simulink. It is actually what I was looking for.
Yet another recent inspiration can be found in the pysimCoder project. Although it is oriented towards code generation rather then simulation, it does have some simulation capabilities too.
It’s also worth mentioning that there are interface layers that are built on top of ModellingToolkit to make things much simpler for the end user (so they don’t need to worry about the actual equations). Take for example Catalyst.jl, which allows users to enter chemical reaction networks in a more natural form than directly writing ODEs/SDEs. Conductor.jl is another for neural dynamics (a work in progress). I’ve seen another on power networks (I can’t remember where - it was in very early development).
So work is happening to make life simpler for end users but MTK is still quite young and MATLAB/Simulink still has a strong hold over many engineers (and my colleagues unfortunately).
As for causal versus acausal, I’m not sure it’s completely clear cut. For many application areas, acausal works very well, however, when you are building models that represent electronic systems the flow based approach of causal can be much easier (particularly dealing with things like different clock rates for different components).
