Skip to content

Is it normal for v10 to create System 10x bigger than v9.xx #3694

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
RobbesU opened this issue Jun 4, 2025 · 9 comments
Closed

Is it normal for v10 to create System 10x bigger than v9.xx #3694

RobbesU opened this issue Jun 4, 2025 · 9 comments
Labels
question Further information is requested

Comments

@RobbesU
Copy link

RobbesU commented Jun 4, 2025

I am testing the breaking v10 with my 3D multi-body MTK (ODE)System.
Code required minimal adjustment and, eventually, leads to the same results. So far so good.

However, I noticed the mtkcompile() (formerly structural_simplify()) runs a little faster (20s -> 14s), but the ODEProblem(sys, op, tspan) creation (formerly ODEProblem(sys, u0, tspan, p0)) takes massively longer (120s -> 3000+s) and creates a ~10x larger problem (120M -> 1.6G allocations).

I have reduced the test system right down to a very basic 2-bodies connected with an elastic spring (f=0 for delta_l<0), so not exactly complex.

ODEProblem with uType Vector{Float64} and tType Float64. In-place: true
Initialization status: FULLY_DETERMINED
Non-trivial mass matrix: false
timespan: (0.0, 1.0)
u0: 24-element Vector{Float64}:
...

Is that expected behaviour for v10 as result of the new System definition?

@RobbesU RobbesU added the question Further information is requested label Jun 4, 2025
@RobbesU
Copy link
Author

RobbesU commented Jun 4, 2025

Ah. Setting the inter-body link from 'elastic' to a normal 'spring' (f=k*delta_l) roughly halves the size the Problem whilst in v9.xx that didn't make a difference, so I take it the new System generates a full tree for each settings branch?

@ChrisRackauckas
Copy link
Member

@AayushSabharwal does #3693 fix this case?

@SebastianM-C
Copy link
Contributor

what was the exact MTK@v9 version?

@RobbesU
Copy link
Author

RobbesU commented Jun 5, 2025

I fixed at v9.72 due to #3662 throwing the system off-balance in structural_simplify from 9.73 onward.
Julia v11.5

@ChrisRackauckas
Copy link
Member

You probably want to fix that. The initialization system got better at reporting unbalanced systems with that release, so you probably want to figure out why not just turn the warning off.

@RobbesU
Copy link
Author

RobbesU commented Jun 5, 2025

Updating v9 environment to 9.80.3 now and will see how goes. Thanks!

@AayushSabharwal
Copy link
Member

Yes, this is fixed in #3693

@RobbesU
Copy link
Author

RobbesU commented Jun 5, 2025

9.80.3 ... works! Not sure if I fixed the issue or MTK? Similar times and sizes as 9.72

        @time "body_prop: " body_prop = ODEProblem(body_sys, body_sys_u0, (0.0, 1.0), body_sys_p0)

@ named() : 108s
structural_simplify(): 115s
body_prop: : 273.953518 seconds (271.89 M allocations: 9.650 GiB, 1.89% gc time, 43.61% compilation time: 16% of which was recompilation)

Copied exact code changing only to MTK10.1 syntax for compile() and problem() again ...

	body_sys_op = merge(body_sys_u0, body_sys_p0)
	@time "body_prop: " body_prop = ODEProblem(body_sys, body_sys_op, (0.0, 1.0))

@ named() : 53.1s
mtkcompile: 18.0s
body_prop: 1748.505661 seconds (3.06 G allocations: 99.028 GiB, 3.16% gc time, 11.15% compilation time: 4% of which was recompilation)

Pkg.status:

Status `....\Env_MTK980\Project.toml`
  [5ae59095] Colors v0.13.1
  [a93c6f00] DataFrames v1.7.0
  [82cc6244] DataInterpolations v8.0.1
  [864edb3b] DataStructures v0.18.22
  [0c46a032] DifferentialEquations v7.16.1
⌅ [f6369f11] ForwardDiff v0.10.38
  [f7f18e0c] GLFW v3.4.4
⌃ [e9467ef8] GLMakie v0.11.8
  [5c1252a2] GeometryBasics v0.5.9
  [b964fa9f] LaTeXStrings v1.4.0
⌅ [961ee093] ModelingToolkit v9.80.3
⌃ [16a59e39] ModelingToolkitStandardLibrary v2.21.1
  [510215fc] Observables v0.5.5
⌃ [1dea7af3] OrdinaryDiffEq v6.97.0
⌃ [127b3ac7] OrdinaryDiffEqNonlinearSolve v1.9.0
  [91a5bcdd] Plots v1.40.13
  [7f904dfe] PlutoUI v0.7.62
  [94ee1d12] Quaternions v0.7.6
  [6038ab10] Rotations v1.7.1
⌃ [0bca4576] SciMLBase v2.95.0
  [5c889d49] SkewLinearAlgebra v1.0.0
  [90137ffa] StaticArrays v1.9.13
  [10745b16] Statistics v1.11.1
  [de0858da] Printf v1.11.0
Status `....\Env_MTK10\Project.toml`
  [5ae59095] Colors v0.13.1
  [a93c6f00] DataFrames v1.7.0
  [82cc6244] DataInterpolations v8.0.1
  [864edb3b] DataStructures v0.18.22
  [0c46a032] DifferentialEquations v7.16.1
⌅ [f6369f11] ForwardDiff v0.10.38
  [f7f18e0c] GLFW v3.4.4
  [e9467ef8] GLMakie v0.11.11
  [5c1252a2] GeometryBasics v0.5.9
  [b964fa9f] LaTeXStrings v1.4.0
  [961ee093] ModelingToolkit v10.1.0
  [16a59e39] ModelingToolkitStandardLibrary v2.22.0
  [510215fc] Observables v0.5.5
  [1dea7af3] OrdinaryDiffEq v6.98.0
  [127b3ac7] OrdinaryDiffEqNonlinearSolve v1.10.0
  [91a5bcdd] Plots v1.40.13
  [7f904dfe] PlutoUI v0.7.62
  [94ee1d12] Quaternions v0.7.6
  [6038ab10] Rotations v1.7.1
  [0bca4576] SciMLBase v2.96.0
  [5c889d49] SkewLinearAlgebra v1.0.0
  [90137ffa] StaticArrays v1.9.13
  [10745b16] Statistics v1.11.1
  [de0858da] Printf v1.11.0

(need to run but can try create a MWE next few days if that helps)

@AayushSabharwal
Copy link
Member

Yeah, 9.80.3 fixes the compile time blowup issue for v9 but also accidentally introduces a few bugs which are fixed in 9.80.4 (currently being tagged). The same fix is ported to v10 in #3693 and will be released soon.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants