Hi, throwing out a Hail Mary here as I have no idea what I am doing. We had/have a working ModelingToolkit model, then suddenly last night it stopped working as the DifferentialEquations.jl package wouldn’t precompile (throwing up errors in nonlinearsolver).
I totally deleted Julia from my computer, reinstalled it, created a new environment, add the packages and all now precompile.
The problem is that my ODESystem now takes 90+ s to form when I run prob=ODEProblem() on my structurally simplified model. I have made no changes to my code and before I reinstalled everything it took about 1 second. It still solves in about 3 seconds, but it’s the forming that takes ages. What’s probably going wrong and how can I fix, delete everything and do a fresh reinstall again?
You could try downgrading ModelingToolkit versions until you find a version where it is fast again. That could help to assess if it is related to some change in MTK.
And if you do find a specific point where it becomes slow it would probably make sense to open an issue on ModelingToolkit with a minimum example that experiences the slow down when changing releases.
Do you have a manifest from before and after, or code to show? I can take a look if you share some code.
We also saw a huge slow down and could fix it by adding this line to Project.toml:
SymbolicUtils = "~3.25"
First, add SymbolicUtils to your project. MTK itself is not the problem.
And if you have code that works well, ALWAYS make a backup of your Manifest.toml file.
If I had to throw a guess out there, do you splat a giant tuple? If so then maybe fix: tuples and arrays of `Symbols` should not be considered symbolic in codegen by AayushSabharwal · Pull Request #735 · JuliaSymbolics/SymbolicUtils.jl · GitHub actually using tuples means that “doing the right thing” (i.e. respecting that you chose to use a tuple) is bad (i.e. giant tuples are really bad for compilation performance, so you probably don’t want to do that, but if you tell us you want a tuple of 100 things we now appropriately respect that).
If you could give us a flamegraph that would be very helpful.
I’ve run into the same issue I suspect. The size of our model is about 1800 unknowns in its initial form and about 260 after structural simplification.
Today I tried updating our packages and suddenly the construction of the ODEProblem takes a very long time (structural_simplify doesn’t seem to have big changes). In the end I just killed my terminal because I did not get any results.
Here you can find the manifests from before and after the update:
Manifest before update.toml (123.2 KB)
Manifest after update.toml (122.0 KB)
Regarding the comment of @ufechner7, SymbolicUtils was 3.7 before the update and after the update it’s 3.27 so that might have something to do with it.
Our repo is currently still private, but I could try to create a flamegraph, or give you access to the repo to check out the issue?
I’ll need an example that can run.
Hello, as I have been running into similar issues, here is a flamegraph for possible utility:
My problem involves many array-valued variables that I have scalarized the initial condition and initial guesses for, passing dictionaries of pairs of the scalarized variable and its Float64 value.
@cryptic.ax why is reorder parameters so slow?
It needs to scalarize array parameters in the tunables. I imagine that gets expensive if you have enough. I’ll look into using a lazily concatenated array or something.
