MTK v11 release blog post

[ChrisRackauckas]

This post fully explains the licensing changes

[AayushSabharwal]

Mostly just grammatical/phrasing changes.

[AayushSabharwal]

80% seems a little over the top 😅 considering we still need tensor calculus. We also need to update StateSelection.jl's core data structures to support array equations, which it remains (rather blissfully) unaware of.

[ChrisRackauckas]

what's a better guestimate?

[AayushSabharwal]

Uhm. I'd say around 60% best case.

[isaacsas]

This feels very premature to me. We need to make a community post explaining the situation on Discourse and solicit feedback before proceeding here. The community may have a strong feeling that the proposed split of MTK is not something they support, and they would prefer to just continue with an MIT MTK 10 as the SciML version (note, I'm not saying I'd personally advocate this direction).

[ChrisRackauckas]

I talked with quite a few people and the issue with that is that it gives a false sense of choice. Continuing with the MIT MTK v10 version as the SciML version just isn't really on the docket. It's either we make it the project, in which case to compensate for the loses we need to get a private donor (because both EU and US sources have already been fully checked) of ~$15mil + 2 people who will leave their jobs to go full time on maintenance that are not part of that funding, or we do this route. The first is such a ridiculous ask that it sounds more like a satire, but we have all come to terms with that being the reality of the project by now, as explained in the post. I don't think the community will just find something to satisfy that in the next week or two, especially after we've had open calls for donations and maintainers since the start of the project. So it's either we leave the repo dead and abandoned, which still would need to probably find some compensation because that too can be a downside to further grant reviews, or we do this approach. At the end of the day, it's a false sense of choice unless some miracle happens. There are grants to submit for the next iteration of all entities, including MIT, and they all have had this requirement for years.

And of course we can always merge backports to v10 (and v9) if anyone does show up with commits.

[isaacsas]

edit: I have edited this as I thought the post had been merged and was not still open for comments. My apologies.

[isaacsas]

At least for me, I would not vote to make this post / official announcement without providing an opportunity for community feedback. Even if the feedback post states that this is the only way to realistically continue MTK development.

[ChrisRackauckas]

What do you think is the best way to share it? A link to this PR?

[odow]

Let's see if this makes the best version of the open source ecosystem.

Is this the best way to end such a blog post? It sounds a bit of a downer to my kiwi-lang. I'd either remove and end with "reach out", or something more positive.

[ViralBShah]

I think it would be valuable to have some before/after timings for the loading times from the type stability and the refactoring work.

A thought - it would be good to have a separate licensing blog post rather than having everything in the MTK V11 release post.

[ChrisRackauckas]

I think it would be valuable to have some before/after timings for the loading times from the type stability and the refactoring work.

@AayushSabharwal you have some of those?

[AayushSabharwal]

Before

Script

import REPL
using ModelingToolkit
using ModelingToolkit: t_nounits as t, D_nounits as D

@variables x(t) = 1 y(t)
@parameters k f = 2.3
eqs = [D(x) ~ x * k + y, y ~ 2x + t]
dvs = Num[x, y]
ps = Num[k, f]
defs= Dict{Num, Float64}()
defs[y] = 2.3
print(Val(:z))
println("System")
@timev System(eqs, t, dvs, ps; defaults = defs, guesses = defs, name = :sys)
# print(Val(:a))
sys = System(eqs, t, dvs, ps; defaults = defs, guesses = defs, name = :sys)
print(Val(:a))
println("Complete")
@timev complete(sys)
print(Val(:b))
println("TearingState")
@timev TearingState(sys)
print(Val(:c))
println("mtkcompile")
@timev mtkcompile(sys)

On Julia 1.11.7 with [email protected], with the command

julia --check-bounds=yes -O 3 --project=@. --startup-file=no --trace-compile=bad.jl workload.jl

Timings

System construction:

  0.243758 seconds (563.80 k allocations: 30.613 MiB, 99.48% compilation time: 3% of which was recompilation)
elapsed time (ns):  2.43757958e8
gc time (ns):       0
bytes allocated:    32099616
pool allocs:        563137
non-pool GC allocs: 16
malloc() calls:     651
free() calls:       0
minor collections:  0
full collections:   0

complete:

  1.795140 seconds (9.76 M allocations: 506.143 MiB, 2.67% gc time, 99.75% compilation time: 71% of which was recompilation)
elapsed time (ns):  1.795140083e9
gc time (ns):       47998414
bytes allocated:    530729216
pool allocs:        9747214
non-pool GC allocs: 111
malloc() calls:     10566
free() calls:       8069
minor collections:  5
full collections:   1

TearingState construction:

  0.374312 seconds (527.01 k allocations: 32.318 MiB, 24.13% gc time, 99.60% compilation time: 85% of which was recompilation)
elapsed time (ns):  3.74312e8
gc time (ns):       90318708
bytes allocated:    33888248
pool allocs:        526440
non-pool GC allocs: 11
malloc() calls:     555
free() calls:       2923
minor collections:  1
full collections:   0

mtkcompile:

  1.772756 seconds (3.81 M allocations: 206.068 MiB, 0.63% gc time, 99.71% compilation time: 71% of which was recompilation)
elapsed time (ns):  1.772755875e9
gc time (ns):       11162292
bytes allocated:    216077752
pool allocs:        3808615
non-pool GC allocs: 61
malloc() calls:     4877
free() calls:       4844
minor collections:  2
full collections:   0

After

Script

import REPL
using ModelingToolkit
using ModelingToolkit: t_nounits as t, D_nounits as D
using Symbolics: SymbolicT

@variables x(t) = 1 y(t)
@parameters k f = 2.3
eqs = [D(x) ~ x * k + y, y ~ 2x + t]
dvs = Num[x, y]
ps = Num[k, f]
ics = Dict{SymbolicT, SymbolicT}()
ics[y] = 2.3

println("System")
print(Val(:z))
@timev System(eqs, t, dvs, ps; initial_conditions = ics, guesses = ics, name = :sys)
print(Val(:zz))
# print(Val(:a))
sys = System(eqs, t, dvs, ps; initial_conditions = ics, guesses = ics, name = :sys)
println("Complete")
print(Val(:a))
@timev complete(sys)
print(Val(:aa))
println("TearingState")
print(Val(:b))
@timev TearingState(sys)
print(Val(:bb))
println("mtkcompile")
print(Val(:c))
@timev mtkcompile(sys)
print(Val(:cc))

On Julia 1.11.7 with SciML/ModelingToolkit.jl#4044 with the command

julia --check-bounds=yes -O 3 --project=@. --startup-file=no --trace-compile=bad.jl workload.jl

Timings

System construction:

  0.000670 seconds (217 allocations: 10.641 KiB)
elapsed time (ns):  669875.0
gc time (ns):       0
bytes allocated:    10896
pool allocs:        217
non-pool GC allocs: 0
minor collections:  0
full collections:   0

complete:

  0.001191 seconds (1.08 k allocations: 2.554 MiB)
elapsed time (ns):  1.190625e6
gc time (ns):       0
bytes allocated:    2678088
pool allocs:        1077
non-pool GC allocs: 0
malloc() calls:     3
free() calls:       0
minor collections:  0
full collections:   0

TearingState:

  0.014592 seconds (3.96 k allocations: 4.456 MiB, 92.30% compilation time)
elapsed time (ns):  1.4592042e7
gc time (ns):       0
bytes allocated:    4672936
pool allocs:        3955
non-pool GC allocs: 0
malloc() calls:     4
free() calls:       0
minor collections:  0
full collections:   0

mtkcompile:

  0.018629 seconds (20.74 k allocations: 932.062 KiB, 89.89% compilation time)
elapsed time (ns):  1.8628542e7
gc time (ns):       0
bytes allocated:    954432
pool allocs:        20727
non-pool GC allocs: 0
malloc() calls:     13
free() calls:       0
minor collections:  0
full collections:   0

With more improvements to come.

[asinghvi17]

Suggested change

	ModelingToolkitBase.jl is thus an MIT-licensed package with no Julia GPL dependencies and contains all
	of the core functionality of ModelingToolkit.jl. This for example includes the utilities for building
	`System`s, generating code for ODEs, SDEs, etc., and the main symbolic compiler pipeline.
	ModelingToolkitBase.jl is thus a fully functional symbolic modeling compiler which can take symbolic
	descriptions of systems and generate performant Julia code for them as-is.
	A new package **ModelingToolkitBase.jl** will be split out of what is now MTK, as an MIT-licensed package with no Julia GPL dependencies and contains all
	of the core functionality of ModelingToolkit.jl. This for example includes the utilities for building
	`System`s, generating code for ODEs, SDEs, etc., and the main symbolic compiler pipeline.
	ModelingToolkitBase.jl is thus a fully functional symbolic modeling compiler which can take symbolic
	descriptions of systems and generate performant Julia code for them as-is.

[ChrisRackauckas]

It's not really a split though, since it's basically ModelingToolkit of today. It's like 99% of what MTK is today.

[TorkelE]

This is good to go right, can we publish now? @isaacsas @devmotion @AayushSabharwal @ChrisRackauckas? Or is there something more we want to go through first?

[isaacsas]

To be honest, I haven't read it yet. I'll give it a read this afternoon and leave comments if I have any (or just give an approval).

[isaacsas]

I've read up to the discussion blaming funders for this change. I think this post is somewhat misleading to readers in attributing that as the only reason the change is necessary. It is clear that the immediate reason, as we stated in the Discourse post, was the behavior of JuliaHub competitors making it such that JuliaHub can not continue to fund a fully MIT MTK library. The funding issue is a complementary problem in that if we had sufficient grant funding developers could be hired outside of JuliaHub to carry out the work, but the immediate change is due to the competitors behavior and JuliaHub's response to it. (And indeed, when we edited the Discourse post JuliaHub removed most of the discussion about grant funding from the first draft I believe.) The behavior of competitors was also the reason that was initially given to the Steering Council in our discussions.

So let's be transparent here and make sure we fully explain the reasons, in line with the Discourse post (if this post is going to give reasons for the change). People had no issue with it there, so I don't think it needs to be avoided here.

[isaacsas]

This is not being fully honest about the situation in my opinion. The post on Discourse, and the comments when it was reviewed by JuliaHub, made clear that the primary motivator here is concerns about the behavior of JuliaHub competitors (as we said in that post). The grant funding issue was not something that anyone else from JuliaHub commented on (and even significantly cut down from the original draft Discourse post). While I agree that having grant funding to carry out this work outside of JuliaHub would make MTK sustainable on its own, it was not the immediate reason for this change (or even the first reason presented to the SciML council for why this change was necessary).

[ViralBShah]

I would say it is "all of the above" - but I do agree that this is better off not being in here.

[isaacsas]

Cutting it out of the post and just linking the Discourse thread for details on why the split is happening would be fine with me.

[TorkelE]

I am happy with Sam's updates, but I do think it would make sense to have this published relatively soon now.

[ChrisRackauckas]

Everyone approve?

[ChrisRackauckas]

I just wanted to add that having this supported in structural_simplify in MTKBase would indeed be important for SBML importers (and I suspect importers of other formats like CellML, BioNetGen) but also for parameter estimation workflows. As Chris mentioned, in SBML we frequently have models with so-called assignment rules, i.e. expressions of the form x ~ ... in addition to differential expressions of the form D(x) ~ .... Being able to send expressions like x ~ ... into observables simplifies SBML model import and also benefit parameter estimation, since these assignment rules are often used directly as observables in parameter estimation.

@sebapersson this is supported in the basic tearing pass of MTKBase as of release, and it should actually be a lot faster because the basic tearing pass has a much reduced complexity.