[ANN] Jusdl.jl v0.1.0 - Julia Based System Description Language

I would like to announce the first release of Jusdl (Julia-Based System Description Language) that focusses on effective system simulations together with online and offline data analysis. In Jusdl, it is possible to simulate discrete-time and continuous-time, static or dynamical systems. In particular, with the help of DifferentialEquations.jl, it is possible to simulate dynamical systems modeled by different types of differential equations such as ODE (Ordinary Differential Equation), Random Ordinary Differential Equation (RODE), SDE (Stochastic Differential Equation), DDE (Delay Differential Equation) and DAE (Differential-Algebraic Equation), and discrete difference equations. During the simulation, the data flowing through the links of the model can be processed online and specialized analyzes can be performed. These analyses can also be enriched with plugins that can easily be defined using the standard Julia library or various Julia packages. The simulation is performed by evolving the components of the model individually and in parallel in sampling time intervals. The individual evolution of the components allows the simulation of the models including the components that are represented by different kinds of mathematical equations.

Key features of Jusdl includes

  • Simulation of a large class of systems:
    • Static systems (whose input, output relation is represented by a functional relation)
    • Dynamical systems (whose input, state and output relation is represented by difference or differential equations).
      • Dynamical systems modelled by continuous time differential equations: ODE, DAE, RODE, SDE, DDE.
      • Dynamical systems modelled by discrete time difference equations.
  • Simulation of models consisting of components that are represented by different type mathematical equations.
  • Individual construction and evolution of components, no need to construct a unique equation representing the whole model.
  • Online data analysis through plugins
  • Flexibility to enrich the data analysis scope through user-defined plugins.

Currently, Jusdl is in its development phase and any form of contribution–bug reports, bug fixes, feature requests, new ideas and suggestions–are all welcome.


Based on browsing the code and docs for a couple minutes this looks like an impressive piece of work.

In case you aren’t aware, by convention, Julia packages typically don’t include a derivative of “julia” in the name. You might want to consider changing the name. The obvious counter example is the python world, which is by any measure thriving. But, “py” often works as an unambiguous, distinctive syllable. For Julia, its not clear if one should take “j”, “ju”, “jul”, … And then there is how to pronounce it: JUHS-DUHL, JOO-ES-DEE-EL, etc… (hmmm I guess its only by convention that we know to call “pysdl” PIE-ES-DEE-EL rather than PIST-DUHL) But, even more I think it’s a matter of exercising restraint in not letting your enthusiasm for the implementation language intrude into the name of the project.


I second this comment, this looks like a lot of work. But you should definitely consider a better name.

Also, I’d like to link this in the website of JuliaDynamics (under related software), but I will need a better “1 sentence description”. I had to read quite a bit of this post to get an idea of what “System Description Language” means in your context.

Do you think you could help me by providing a small description of the package?


Echoing @jlapeyre, consider renaming your package. Every package could be named “Julia based _”, and that is unhelpful – one reason for the naming guideline.


Thank you for your comments @jlapeyre, @Datseris @JeffreySarnoff.

I see that the name of the package seems to be the problem. Inspired by hardware description language (hdl) in which the structure of the electronic circuits is described, I named the package as Jusdl in which the structure of the model to be simulated is described by constructing its components(i.e. systems) and specifying how they are connected to each other. This is where the name Jusdl comes from. Anyway, I will think about renaming the package.


I have always admired your work in JuliaDynamics and I would be really happy if you link Jusdl as a related software under JuliaDynamics. For now, the small description you may use while linking Jusdl may be

Jusdl - for interconnected systems simulations and online data analysis.

I will let you know when the package is renamed.

The name “system description language” comes from the fact that the models are not constructed at once as a whole, but are described by constructing its components and describing the way they are connected to each other.

I certainly wouldn’t say its the problem, maybe not even a problem. I was a bit reluctant to make my post because the bikeshedding effect magnifies the importance of naming. The bar for ability to write an opinion is really low.


I definitely see your point.

Thank you

I like what I’ve seen of the package so far. I just one comment:

The model = Model(component1, component2,...) call seems unnecessary. If each component has a reference to its connected components, shouldn’t you be able to pass, say, just a Writer block to the simulate() call and have it build up the Model automatically by traversing through the connections? Since these are causal models, this seems like it would be especially easy to do. Even if they were acausal, each component already has a unique identifier, so it wouldn’t be too hard. So I guess the interface would be something like:

sim = simulate(writer, tinit, tsample, tfinal)


writers = [writer1, writer2, writer3,...]
sim = simulate(writers, tinit, tsample, tfinal)
1 Like

Thank you for your suggestion @jonniedie . Given a single component, building the whole model from that component by traversing through the connections is possible and a good idea. This approach can particularly be useful when the number of components is huge. That is, instead of specifying a long list of component arguments to the Model constructor, we can construct the model by specifying a single arbitrarily chosen component. Thus, I will definitely give a try to your suggestion.

Furthermore, I think the model can be defined by specifying the components in a kind of file (like a .json or .toml file). Something like

    name = "Model1"
        tinit = 0.0
        tsample = 0.01
        tfinal = 100.0


            name = "gen"
            amplitude = 1
            frequency = 2

            name = "adder"
            numinput = 2
            signs = "(+ ,-)"

            name = "ds"
            numinput = 1
            numoutput = 2
            statefunc = "(dx, x, u, t) -> (dx = -x)"
            outputfunc = "(x, u, t) -> (dx = -x)"
            state = [1]
            t = 0

        src = "gen.output"
        dst = "adder.input[1]"

        src = "adder.output"
        dst = "ds.input"

        src = "ds.output"
        dst = "adder.input[2]"

Note that the file is similar to a netlist file of SPICE, that is, the file completely describes the model. Then, this file can be parsed and be processed to construct the model.

An alternative approach to above one may be using metaprogramming. In that case, we can define a model as follows.

model = @model begin 
        SinewaveGenerator => (amplitude=1, frequency=1., name="gen")
        Adder => (numinput=2, signs=(+,-), name="adder")
        ODESystem => (numinput=0, numoutput=1, statefunc=(dx, x, u, t) -> (dx .= -x), outputfunc(x,u,t) -> x, state=[1.], t=0., name="ds")
        gen.output => adder.input[1]
        adder.output => ds.input
        ds.output => adder.input[2]

One final note is that both of these approaches(the file content and the metaprogramming syntax) are just thought as they are and have not been tried yet.