Dyad 3.0 slower Transient Analysis

Specific Domains Modelling & Simulations
1

Hi

I just got greeted in VSCode with a message that made me update to Dyad 3.0… After using the AI to update my models I now realized that the TransientAnalysis is now much slower that before. (5min instead of 3min maybe)

I am simulating a Vienna Rectifier that has some switches switching at 50kHz, so I am not expecting something super fast, but this feels easily double the time than before.

Honestly I am not sure how to get back to the previous Dyad Release, otherwise I would love to share some real numbers.

I published the code here if it helps: https://gitlab.com/gruemel/julia/dyad_vienna_afe There is a commit " Updated the model to Dyad 3.0" for the updated code

I tried setting optimize = OptimizationLevel.Basic(), and optimize = OptimizationLevel.Agressive(), but these are not working due to some errors.

Anything I can do to get more insights where this is coming from?

2

Tomorrow I will try again with a windows laptop still running the old version, to get some concrete values.

3

It’s not perfect since it is not the same machine, but I think it gives the picture:

Linux dyad 3.0: 239.544428 seconds (122.03 M allocations: 80.717 GiB, 10.04% gc time, 0.00% compilation time: 100% of which was recompilation)

Windows dyad 2.3: 14.381151 seconds (23.07M allocations: 4.706 GiB, 19.00% gc time, 0.00% compilation time)

4

Yup that’s gives a picture. We can look into it.

5

That was a quick reply! Thank you Chris!

If I can do anything to help debug, let me know.

6

Thanks for sharing these examples. I’m just adding a link to the circuit topology, since I didn’t know it:

I also find a schematic in your repo, but it’s not obvious is the same a the one on Wikipedia.

7

Figured out what it is. It looks like this is due to the enabling of inline linear SCC passes without the rest of the new compiler framework being released (the other part is scheduled for the upcoming 3.1.0 release).

We’d either need a 3.0.1 to allow for temporarily disabling inline linear SCCs or just wait for the 3.1.0 which includes the new compiler passes to make these non-allocating. The problem with disabling is that it can change the state selection, which in particular makes the model require a lot more guesses, so it would be a breaking change and a pretty bad quality of life thing to have this turned off. So the best thing to do for this model is probably to just have the regression fixed in the 3.1.0 with the new compiler codegen. That’s not the most ideal answer but since that is already scheduled for the very near future it’s almost as fast as a patch release would be, that is the way to do this that’s the most future-proofed.

In the meantime, if you’re willing to get a bit manual, you can get around this by disabling the linear SCC inlining by taking the mtkcompile command directly and doing:

ModelingToolkit.StructuralTransformations.DefaultReassembleAlgorithm(;
      inline_linear_sccs = true, analytical_linear_scc_limit = 1)
  sys = mtkcompile(model; additional_passes = passes, reassemble_alg)
8

Hi Chris,

since I am currently “just scratching an itch” and I need to also work around the maxiters topic, for me doing it manually is just fine.

You decide which solution is best from business/process point of view :wink:

BR
Johannes

9

Hi,

I just updated to 3.1.1 and it looks like the change made it in there. But now I am getting an issue concerning some derivatives.

I let the Agent figure it out for me (no credits for me) and have it create a bug report: BUGREPORT_inline_linear_sccs_init.md · 099f8bca88bc6c47fda1707679807645f05713a7 · gruemel / julia / Dyad_Vienna_AFE · GitLab

The commit fix issue with dummy derivatives and inline_linear_sccs = true (099f8bca) · Commits · gruemel / julia / Dyad_Vienna_AFE · GitLab fixes it for me, but I am sure this is not how it is supposed to be.
@ChrisRackauckas should I file a bug somewhere or is that already known?

10

Not previously known @cryptic.ax

11

Thanks for the bug report @gruemelmonster. This issue has already been fixed in newer versions of ModelingToolkit.

julia> prob = try_build(inline = true, limit = 1)
julia> sol = solve(prob)
retcode: Success
Interpolation: 3rd order Hermite
t: 52801-element Vector{Float64}:
12

Can you tell me which version of MTK has the fix?

I am not sure what the snippet is supposed to tell me, sorry.

13

Can you tell me which version of MTK has the fix?

ModelingToolkitTearing@1.14.1 fixed this. ModelingToolkitTearing is a dependency of ModelingToolkit.

I am not sure what the snippet is supposed to tell me, sorry.

I apologize, I should have been clearer. The snippet is copied from my REPL. It is meant to demonstrate that I managed to run try_build from your reproducer, got an ODEProblem out, and successfully solved it.