JuliaCon2020 Dynamical Modelling BoF summary

Specific Domains Modelling & Simulations
1

Hi everyone, below you will find the summary of the BoF session of JuliaCon2020. I’ve tried to make everything sensible, feel free to correct me in the comments!

Our working definition of “dynamical modelling” is:

Modelling natural (physics/chemistry/biology), engineering, economic or social systems that evolve in time

What does Julia have in terms of dynamical modelling?

  • DifferentialEquations.jl
  • RigidBodyDynamics.jl, DiffEqBiological.jl, Pumas.jl, NetworkDynamics.jl (and many more that derive from DifferentialEquations.jl)
  • DynamicalSystems.jl (it doesn’t actually model anything, but further analyzes)
  • Modia and Modia3D.jl (Modelica implementation in Julia)
  • CLiMA (https://clima.caltech.edu/) – global climate model in Julia
  • Stochastic models of chemical reactions: Catalyst.jl ReactionMechanismSimulator.jl
  • Agents.jl : socio-economic systems, agent based modelling, discrete & categorical state spaces
  • Spiking neural networks – WaspNet.jl
  • DynamicalBilliards.jl, HardSphereDynamics.jl
  • Rigorous ODE solutions: TaylorModels.jl and JuliaReach org
  • Molly.jl and NBodySImulator.jl for molecular simulation
  • Spin-flip models for statistical physics and phase transitions (packages?)
  • Optimal control (real-time feedback on model parameters) DiffEqFlux.jl
  • Differential-algebraic equations (ODEs with constraints) (https://diffeq.sciml.ai/latest/solvers/dae_solve/)

you will see that some fields do not have packages listed. please let us know whether what you’ve typed is a “request” or something that actually exists

What were the key discussion points?

  • A lot of packages exist, and many new come. How do we organize this information?
    • Over-arching website for “Dynamical modelling in Julia”? Suggestion: perhaps use the existing “ecosystem” page in the official Julia website?
    • Document all the different packages and how they are similar / different
  • Should we be helping/motivating new packages join established orgs?
  • What is the best way to compare software for modelling in Julia with alternatives in other languages? How to make them fair but also highlight performance?
    • How to compare “code complexity”?
    • How to better expose concrete (performance) benchmarks?
    • How would you compare your “paradigm shifts”?
    • There are lots of standard benchmarks around
    • Work out what other packages are out there and how to install them for CI
  • Trying to come up with examples of how and why Julia is different (e.g. Can you throw in a fundamentally different type?) can lead to not only exposing why doing dynamic modelling in Julia is great, but also lead to new research directions.
  • How do we incorporate standardized file formats into the ecosystem? (ie how can we export models for sharing and simulation in other tools? See: Functional Mockup Interface https://fmi-standard.org)
  • How do we invite more people to join us (from other languages)?
    • Make good tutorials! From people that are actively working on the subjects!
    • Make good comparisons (but also as objective as possible) that expose with “facts” why it is a good idea to join us.
  • Tutorial sprints/hackathons - coordinate with JuliaStreamers/julialang.live
  • Can we do Hybrid dynamical systems (mixing continuous evolution with discrete events) better?

What do we want to have done until next JuliaCon?

  • Tips to write code that is good for Julia, doesn’t allocate, but also how to make it work on the GPU / compatible with Zygote. Currently run into the “Two implementation problem” (One non-allocating CPU facing implementation, and a separate GPU/differentiable facing implementation)
    • Ege DiffEqBase.@.. (see Chris’ post)
    • Related: KernelAbstractions.jl (write code once and run on CPU, threaded, and GPU)
  • More comparisons with other software (“competitors”) in the talks and package-docs
  • Perhaps a “tutorial-thon”?!
  • Highlight interplay between Julia packages (e.g. how one can make Agents.jl work with OpenStreetMapX.jl, DynamicalBilliards.jl work with Makie.jl, or OrdinaryDiffEq.jl work with pretty much anything from the huge list of packages in the SciML ecosystem)

“Leftovers”

Here I provide, almost verbatim, various scattered sentences that did not have much thematic connection to where they originally were. As always, feel free to correct, I’ll edit the post as we go along.

Co-simulation

Symbolic transformations on models as compiler passes

  • E.g. model-order reduction (lossy)
  • Using ModelingToolkit.jl

Data-driven approaches

thanks everyone for joining and providing so many useful points!

10 Likes
2

Here are my personal two cents from the BoF.

I was the one that brought up the topic “should we motivate packages to join established orgs”? My personal take on this, which might be an outlier, is a resounding “yes”, perhaps because of the different way JuliaDynamics operates. Although a GitHub organization on paper, what brings us together is not at all package management (which is the actual goal of an GitHub organization). Rather, it is a common will to understand dynamical systems as well as the common will to make high quality scientific software to help this understanding. In addition (and maybe this is not true for everyone), I believe an established org brings trust to the eyes of a user, and the exact same package can be viewed as more trustworthy when under an org.

Thus, (at least I) will be continuing to invite people, and the risk of an “abandoned” package ending in the org is something we’ll have to deal with once it happens. So far my experience with inviting people (and they joining, because of course declining is just as natural and has happened already) has been extremely positive (see this post and this post). The joining packages got a increase in exposure as well as contributions and (when necessary) enhancement of documentation. Especially the last part, is something “we” (the established org) can help a lot a new developer, since we are in some sense “seniors” in this area, even if we are not directly familiar. And striving to make the joining package have the “quality standard” of the org when it comes down to the docs can be a motivating force.

For me the other important part of the BoF is that (I believe) we need to invite more people into dynamical modelling in Julia from other languages because (I believe) we do have some of the best packages out there. My current direction on making this possible is comparisons with other existing software, and trying to give “factual reasons” on why someone using e.g. Python should consider switching to Julia. We are currently underway finalizing such a comparison for Agents.jl, which we will share once it is finished.

That BoF was a pleasure for me, and extremely helpful for the community as a whole I believe :slight_smile:

5 Likes
3

Filling in a few points here.

Catalyst.jl
ReactionMechanismSimulator.jl

Or for the common CTMC Catalyst.jl

Fully nonlinear is part of DiffEqFlux (https://diffeqflux.sciml.ai/dev/examples/optimal_control/), and we plan to add a nicer interface over this usecase soon for visibility.

https://diffeq.sciml.ai/latest/tutorials/dae_example/
https://diffeq.sciml.ai/latest/solvers/dae_solve/

And NBodySimulator.jl, but what @SebastianM-C is trying to do as part of GSoC is get Molly on-par with NBodySimulator and hopefully get around to making a Ewald implementation so we can get something complete there.

SciML is creating a unified documentation page for all of its packages and the relevant other packages, so I plan to make sure things like NetworkDyanmics.jl and ComponentArrays.jl are included as part of that documented ecosystem. That should help discoverability.

It’s DiffEqBase.@.., and it’s a fully non-allocating broadcast that assumes no-aliasing to get the full LLVM optimization. For whomever was wondering about GPU support, that’s the piece that gets you the same as looping via broadcast.

We plan to use ModelingToolkit.jl as the symbolic centerpiece of the SciML organization and link to things like FMI, SBML, etc. all through that.

Yes. Dynamical modeling, moreso than disciplines like data science or ML, is especially good for Julia since it relies on user defined models (functions) and requires high performance, so you cannot just optimize some kernels up front and you can’t rely on users not caring about performance. Together, Julia has a huge advantage and when you look at for example my JuliaCon talk on automatic optimizations, we’re seeing 50x over SciPy and then another 1000x over bad implementations of Julia models, and so automatic optimization on a new user’s code is literally hitting 10,000x (this is an example 36,000x speedup in the wild). With those kinds of differences, in the next year I plan to be putting ModelingToolkit and AutoOptimize much more in the limelight and really demonstrating how the simplest Julia code vs the simplest Python has a massive difference, and would like to have some other pieces like Agents.jl demonstrating similar results and sharing those along side this.

BTW, if anyone has any speedups they’d like to share, I’d love to start sharing your work as part of my slide decks. So just get in contact and let me know what kind of scientific problems were being answered and how much of a difference the Julia tools made, and we can start to share your science along with our talks about tools (get more publicity for both :slight_smile:).

7 Likes
4

Not sure if someone is following this thread, but here is the Agents.jl 4.0 announcement which includes a comparison with other software: Agents.jl 4.0 + Comparison with competitors

It really took us a lot of effort to make the comparison, especially the numeric one. However I believe it is useful to highlight performance gains in the same table that compares features.

1 Like
5

Hi @Datseris,

I saw the item mentioned “Rigorous ODE solutions: TaylorModels.jl and JuliaReach org”; unfortunately I wasn’t able to participate. Do you think there will be a similar session this year?

6

Yeap we should set up another BoF for this. Although the BoF is like an informal discussion, you should submit an abstract for a normal talk if you want to present your work

2 Likes