Modia with Measurements gives promote_rule ambiguity

[MartinOtter]

Running Modia with Julia 1.8.0 gives an error, if Measurement is used as floating point type (error: promote_rule is ambiguous). The reason is most likely that a new version of DiffEqBase.jl (6.100.1) is used where newly introduced promote rules introduce this ambiguity (this error does not appear with DiffEqBase version 6.95.2). This issue can be reproduced with:

using Modia
include("$(Modia.path)/test/TestPendulum.jl")

resulting in the following output

[...]
Instantiating model PendulumWithUncertainties
  in module: Main.TestPendulum
  in file: home\.julia\dev\Modia\test\TestPendulum.jl:35
ERROR: LoadError: MethodError: promote_rule(::Type{Measurements.Measurement{Float64}}, ::Type{ForwardDiff.Dual{ForwardDiff.Tag{DiffEqBase.OrdinaryDiffEqTag, Measurements.Measurement{Float64}}, Measurements.Measurement{Float64}, 1}}) is ambiguous. Candidates:
  promote_rule(::Type{R}, ::Type{ForwardDiff.Dual{T, V, N}}) where {R<:Real, T, V, N} in ForwardDiff at home\.julia\packages\ForwardDiff\pDtsf\src\dual.jl:425
  promote_rule(::Type{Measurements.Measurement{T}}, ::Type{S}) where {T<:AbstractFloat, S<:Real} in Measurements at home\.julia\packages\Measurements\PwGjt\src\conversions.jl:58
Possible fix, define
  promote_rule(::Type{Measurements.Measurement{T}}, ::Type{ForwardDiff.Dual{T, V, N}}) where {T<:AbstractFloat, T, V, N}
Stacktrace:
  [1] promote_type(#unused#::Type{Measurements.Measurement{Float64}}, #unused#::Type{ForwardDiff.Dual{ForwardDiff.Tag{DiffEqBase.OrdinaryDiffEqTag, Measurements.Measurement{Float64}}, Measurements.Measurement{Float64}, 1}})
    @ Base .\promotion.jl:298
  [2] promote_eltype(#unused#::Type{Vector{Measurements.Measurement{Float64}}}, #unused#::Type{ForwardDiff.Dual{ForwardDiff.Tag{DiffEqBase.OrdinaryDiffEqTag, Measurements.Measurement{Float64}}, Measurements.Measurement{Float64}, 1}})
    @ ArrayInterfaceCore home\.julia\packages\ArrayInterfaceCore\j22dF\src\ArrayInterfaceCore.jl:143
  [3] wrapfun_iip(ff::Any, inputs::Tuple{Vector{Measurements.Measurement{Float64}}, Vector{Measurements.Measurement{Float64}}, SimulationModel{Measurements.Measurement{Float64}, Float64}, Float64})
    @ DiffEqBase home\.julia\packages\DiffEqBase\iK5G7\src\norecompile.jl:58
  [4] promote_f(f::ODEFunction{true, SciMLBase.AutoSpecialize, typeof(Modia.derivatives!), LinearAlgebra.UniformScaling{Bool}, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, typeof(SciMLBase.DEFAULT_OBSERVED), Nothing, Nothing}, #unused#::Val{SciMLBase.AutoSpecialize}, u0::Vector{Measurements.Measurement{Float64}}, p::SimulationModel{Measurements.Measurement{Float64}, Float64}, t::Float64)
    @ DiffEqBase home\.julia\packages\DiffEqBase\iK5G7\src\solve.jl:974
  [5] get_concrete_problem(prob::ODEProblem{Vector{Measurements.Measurement{Float64}}, Tuple{Float64, Float64}, true, SimulationModel{Measurements.Measurement{Float64}, Float64}, ODEFunction{true, SciMLBase.AutoSpecialize, typeof(Modia.derivatives!), LinearAlgebra.UniformScaling{Bool}, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, typeof(SciMLBase.DEFAULT_OBSERVED), Nothing, Nothing}, Base.Pairs{Symbol, Union{}, Tuple{}, NamedTuple{(), Tuple{}}}, SciMLBase.StandardODEProblem}, isadapt::Bool; kwargs::Base.Pairs{Symbol, Any, NTuple{13, Symbol}, NamedTuple{(:u0, :p, :reltol, :abstol, :save_everystep, :callback, :adaptive, :saveat, :dt, :dtmax, :maxiters, :tstops, :initializealg), Tuple{Vector{Measurements.Measurement{Float64}}, SimulationModel{Measurements.Measurement{Float64}, Float64}, Float64, Float64, Bool, CallbackSet{Tuple{}, Tuple{DiscreteCallback{DiffEqCallbacks.var"#27#28", DiffEqCallbacks.FunctionCallingAffect{typeof(Modia.outputs!), DataStructures.BinaryMinHeap{Float64}, Vector{Float64}}, typeof(DiffEqCallbacks.functioncalling_initialize), typeof(SciMLBase.FINALIZE_DEFAULT)}, DiscreteCallback{typeof(Modia.timeEventCondition!), typeof(Modia.affectTimeEvent!), typeof(SciMLBase.INITIALIZE_DEFAULT), typeof(SciMLBase.FINALIZE_DEFAULT)}}}, Bool, StepRangeLen{Float64, Base.TwicePrecision{Float64}, Base.TwicePrecision{Float64}, Int64}, Float64, Float64, Int64, Tuple{Float64}, NoInit}}})
    @ DiffEqBase home\.julia\packages\DiffEqBase\iK5G7\src\solve.jl:907
  [6] solve_up(prob::ODEProblem{Vector{Measurements.Measurement{Float64}}, Tuple{Float64, Float64}, true, SimulationModel{Measurements.Measurement{Float64}, Float64}, ODEFunction{true, SciMLBase.AutoSpecialize, typeof(Modia.derivatives!), LinearAlgebra.UniformScaling{Bool}, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, typeof(SciMLBase.DEFAULT_OBSERVED), Nothing, Nothing}, Base.Pairs{Symbol, Union{}, Tuple{}, NamedTuple{(), Tuple{}}}, SciMLBase.StandardODEProblem}, sensealg::Nothing, u0::Vector{Measurements.Measurement{Float64}}, p::SimulationModel{Measurements.Measurement{Float64}, Float64}, args::Tsit5{typeof(OrdinaryDiffEq.trivial_limiter!), typeof(OrdinaryDiffEq.trivial_limiter!), Static.False}; kwargs::Base.Pairs{Symbol, Any, NTuple{11, Symbol}, NamedTuple{(:reltol, :abstol, :save_everystep, :callback, :adaptive, :saveat, :dt, :dtmax, :maxiters, :tstops, :initializealg), Tuple{Float64, Float64, Bool, CallbackSet{Tuple{}, Tuple{DiscreteCallback{DiffEqCallbacks.var"#27#28", DiffEqCallbacks.FunctionCallingAffect{typeof(Modia.outputs!), DataStructures.BinaryMinHeap{Float64}, Vector{Float64}}, typeof(DiffEqCallbacks.functioncalling_initialize), typeof(SciMLBase.FINALIZE_DEFAULT)}, DiscreteCallback{typeof(Modia.timeEventCondition!), typeof(Modia.affectTimeEvent!), typeof(SciMLBase.INITIALIZE_DEFAULT), typeof(SciMLBase.FINALIZE_DEFAULT)}}}, Bool, StepRangeLen{Float64, Base.TwicePrecision{Float64}, Base.TwicePrecision{Float64}, Int64}, Float64, Float64, Int64, Tuple{Float64}, NoInit}}})
    @ DiffEqBase home\.julia\packages\DiffEqBase\iK5G7\src\solve.jl:822
  [7] solve(prob::ODEProblem{Vector{Measurements.Measurement{Float64}}, Tuple{Float64, Float64}, true, SimulationModel{Measurements.Measurement{Float64}, Float64}, ODEFunction{true, SciMLBase.AutoSpecialize, typeof(Modia.derivatives!), LinearAlgebra.UniformScaling{Bool}, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, Nothing, typeof(SciMLBase.DEFAULT_OBSERVED), Nothing, Nothing}, Base.Pairs{Symbol, Union{}, Tuple{}, NamedTuple{(), Tuple{}}}, SciMLBase.StandardODEProblem}, args::Tsit5{typeof(OrdinaryDiffEq.trivial_limiter!), typeof(OrdinaryDiffEq.trivial_limiter!), Static.False}; sensealg::Nothing, u0::Nothing, p::Nothing, kwargs::Base.Pairs{Symbol, Any, NTuple{11, Symbol}, NamedTuple{(:reltol, :abstol, :save_everystep, :callback, :adaptive, :saveat, :dt, :dtmax, :maxiters, :tstops, :initializealg), Tuple{Float64, Float64, Bool, CallbackSet{Tuple{}, Tuple{DiscreteCallback{DiffEqCallbacks.var"#27#28", DiffEqCallbacks.FunctionCallingAffect{typeof(Modia.outputs!), DataStructures.BinaryMinHeap{Float64}, Vector{Float64}}, typeof(DiffEqCallbacks.functioncalling_initialize), typeof(SciMLBase.FINALIZE_DEFAULT)}, DiscreteCallback{typeof(Modia.timeEventCondition!), typeof(Modia.affectTimeEvent!), typeof(SciMLBase.INITIALIZE_DEFAULT), typeof(SciMLBase.FINALIZE_DEFAULT)}}}, Bool, StepRangeLen{Float64, Base.TwicePrecision{Float64}, Base.TwicePrecision{Float64}, Int64}, Float64, Float64, Int64, Tuple{Float64}, NoInit}}})
    @ DiffEqBase home\.julia\packages\DiffEqBase\iK5G7\src\solve.jl:795
  [8] macro expansion
    @ home\.julia\packages\TimerOutputs\4yHI4\src\TimerOutput.jl:237 [inlined]
  [9] simulateSegment!(m::SimulationModel{Measurements.Measurement{Float64}, Float64}, algorithm::Tsit5{typeof(OrdinaryDiffEq.trivial_limiter!), typeof(OrdinaryDiffEq.trivial_limiter!), Static.False}; kwargs::Base.Pairs{Symbol, Quantity{Float64, 𝐓, Unitful.FreeUnits{(s,), 𝐓, nothing}}, Tuple{Symbol}, NamedTuple{(:st  opTime,), Tuple{Quantity{Float64, 𝐓, Unitful.FreeUnits
{(s,), 𝐓, nothing}}}}} )
    @ Modia home\.julia\dev\Modia\src\SimulateAndPlot.jl:549
 [10] macro expansion
    @ home\.julia\dev\Modia\src\SimulateAndPlot.jl:235 [inlined]
 [11] macro expansion
    @ home\.julia\packages\TimerOutputs\4yHI4\src\TimerOutput.jl:237 [inlined]
 [12] simulate!(m::SimulationModel{Measurements.Measurement{Float64}, Float64}, algorithm::Tsit5{typeof(OrdinaryDiffEq.trivial_limiter!), typeof(OrdinaryDiffEq.trivial_limiter!), Static.False}; merge::Nothing, kwargs::Base.Pairs{Symbol, Quantity{Float64, 𝐓, Unitful.FreeUnits{(s,), 𝐓, nothing}}, Tuple{Symbol}, NamedTuple{(:st  opTime,), Tuple{Quantity{Float64, 𝐓, Unitful.
FreeUnits{(s,), 𝐓, nothing}}}}} )
    @ Modia home\.julia\dev\Modia\src\SimulateAndPlot.jl:234
 [13] top-level scope
    @ home\.julia\dev\Modia\test\TestPendulum.jl:38
 [14] include(fname::String)
    @ Base.MainInclude .\client.jl:476
 [15] top-level scope
    @ REPL[11]:1
in expression starting at home\.julia\dev\Modia\test\TestPendulum.jl:1

The advice given in the error message

Possible fix, define
  promote_rule(::Type{Measurements.Measurement{T}}, ::Type{ForwardDiff.Dual{T, V, N}}) where {T<:AbstractFloat, T, V, N}

does not fix this issue.

Help is appreciated.

[MartinOtter]

I just checked: When using DiffEqBase version 6.99.0, this promote_rule error does not appear.

[ChrisRackauckas]

How did this code work in the first place? Without the promotion rule, no arithmetic would work:

using ForwardDiff, Measurements
x = 1.0 ± 0.0
y = ForwardDiff.Dual(1.0,(0.01))
x + y

ERROR: MethodError: +(::Measurement{Float64}, ::ForwardDiff.Dual{Nothing, Float64, 1}) is ambiguous. Candidates:
  +(x::AbstractFloat, y::ForwardDiff.Dual{Ty}) where Ty in ForwardDiff at C:\Users\accou\.julia\packages\ForwardDiff\pDtsf\src\dual.jl:145
  +(x::Real, y::ForwardDiff.Dual{Ty}) where Ty in ForwardDiff at C:\Users\accou\.julia\packages\ForwardDiff\pDtsf\src\dual.jl:145
  +(a::Measurement, b::Real) in Measurements at C:\Users\accou\.julia\packages\Measurements\PwGjt\src\math.jl:179
Possible fix, define
  +(::Measurement, ::ForwardDiff.Dual{Ty}) where Ty
Stacktrace:
 [1] top-level scope
   @ c:\Users\accou\OneDrive\Computer\Desktop\test.jl:75

so we could add a safeguard on if the promotion rule exists, but my first inclination would be to just throw a more informative error on the incompatibility of the element types. I would assume then that solve(prob,Rodas5()) doesn't work and only solve(prob,Rodas5(autodiff=false)) works on this code then?

[ChrisRackauckas]

The advice given in the error message
Possible fix, define
promote_rule(::Type{Measurements.Measurement{T}}, ::Type{ForwardDiff.Dual{T, V, N}}) where {T<:AbstractFloat, T, V, N}
does not fix this issue.

I think you'd need to define a few promotion rules to have ForwardDiff mix with Measurements, and a conversion rule. Then it should work. Though that's a separate matter, I'm curious to figure out how this exists in the first place to put a proper safeguard on it.

[MartinOtter]

I would assume then that solve(prob,Rodas5()) doesn't work and only solve(prob,Rodas5(autodiff=false)) works on this code then?

Yes, this is correct (Modia only works with autodiff=false).
I once tried to get autodiff=true to work, but after some time I gave up, and worked on higher priority issues of Modia

[MartinOtter]

I think you'd need to define a few promotion rules to have ForwardDiff mix with Measurements, and a conversion rule. Then it should work. Though that's a separate matter, I'm curious to figure out how this exists in the first place to put a proper safeguard on it.

Modia has a linearization function to linearize at the stopTime of the simulation and return a linear model at the stopTime (e.g. Modia/test/TestFirstOrder2.jl). This function has the option to linearize numerically or analytically with ForwardDiff. With a new version of ForwardDiff, this suddenly did no longer work. I spend a day or so to fix this, but did not manage and therefore de-activated analytic linearization. Also before this case, there have been some Modia models, where ForwardDiff failed, since there are so many restrictions for automatic differentiation. I first wanted to have a reasonable stable version of Modia, before looking into this issue again.

I think you'd need to define a few promotion rules to have ForwardDiff mix with Measurements, and a conversion rule.

My past experience shows that I have currently not enough knowledge to formulate such promotion and conversion rules.

I wonder why this anyway happens, since analytic differentiation is not used (e.g. the used Tsit5 integrator, does not use analytic differentiation). Is it eventually possible to switch off the promotion rules if automatic differentiation is not used.

[ChrisRackauckas]

This should be fixed in #824. Though it sounds like you maybe want the full specialization behavior, in which case I'd recommend just doing ODEProblem{true, SciMLBase.FullSpecialize}(...). Of course, this will opt-out of the full precompilation solution mentioned in https://twitter.com/ChrisRackauckas/status/1561278092043325440, but for now what I did in #824 is just did a lazy opt-out for models that don't support automatic differentiation (since the full precompilation assumes strict type support on an extended type set). As mentioned in the PR, that can be relaxed in the near future, but for now that is a safety fix to get any case like this back to the old behavior.

[MartinOtter]

I made some experiments (always starting with a new Julia session):

Julia 1.8, DiffEqBase: v6.103.0, ODEProblem{true}(...)

julia> @time using Modia
 27.661304 seconds (64.71 M allocations: 4.617 GiB, 4.70% gc time, 10.26% compilation time: 52% of which was recompilation)

julia> @time include("$(Modia.path)/test/TestFirstOrder.jl")
136.783586 seconds (254.76 M allocations: 22.886 GiB, 3.49% gc time, 95.25% compilation time: 2% of which was recompilation)

julia> @time include("$(Modia.path)/test/TestTwoInertiasAndIdealGear.jl")
 49.026137 seconds (74.12 M allocations: 8.075 GiB, 3.58% gc time, 97.98% compilation time: 7% of which was recompilation)

julia> @time include("$(Modia.path)/test/TestFirstOrder.jl")
  0.217823 seconds (115.55 k allocations: 6.061 MiB, 35.05% compilation time)

julia> @time include("$(Modia.path)/test/TestTwoInertiasAndIdealGear.jl")
  0.450801 seconds (278.48 k allocations: 15.118 MiB, 31.89% compilation time)

Julia 1.8, DiffEqBase: v6.103.0, ODEProblem{true, SciMLBase.FullSpecialize}(...)

julia> @time using Modia
 27.976623 seconds (64.71 M allocations: 4.616 GiB, 5.16% gc time, 11.51% compilation time: 51% of which was recompilation)

julia> @time include("$(Modia.path)/test/TestFirstOrder.jl")
138.220676 seconds (248.60 M allocations: 22.419 GiB, 3.57% gc time, 98.30% compilation time: 2% of which was recompilation)

julia> @time include("$(Modia.path)/test/TestTwoInertiasAndIdealGear.jl")
 42.587183 seconds (71.82 M allocations: 7.959 GiB, 3.81% gc time, 97.78% compilation time: 8% of which was recompilation)

julia> @time include("$(Modia.path)/test/TestFirstOrder.jl")
 16.765308 seconds (31.49 M allocations: 3.036 GiB, 5.14% gc time, 98.46% compilation time: 88% of which was recompilation)
Main.TestFirstOrder

julia> @time include("$(Modia.path)/test/TestTwoInertiasAndIdealGear.jl")
 14.790407 seconds (20.24 M allocations: 3.014 GiB, 4.53% gc time, 96.98% compilation time: 88% of which was recompilation)

julia> @time include("$(Modia.path)/test/TestFirstOrder.jl")
  0.217103 seconds (115.53 k allocations: 6.060 MiB, 36.29% compilation time)

julia> @time include("$(Modia.path)/test/TestTwoInertiasAndIdealGear.jl")
  0.482178 seconds (278.48 k allocations: 15.116 MiB, 31.19% compilation time)

Conclusion

ODEProblem{true}(...) seems to better as ODEProblem{true, SciMLBase.FullSpecialize}(...), because at the second run of Modia model the simulation is fast, whereas in the latter case a fast simulation is only achieved in the third run.

I then tried (with ODEProblem{true}(...))

@time using Modia
@time include("$(Modia.path)/test/runtests.jl")

After about one hour, I stopped (needs usually 10 minutes).
The reason was model TestTwoInertiasAndIdealGearWithMonteCarlo.jl.
Running this separately, indeed shows that simulation takes forever:

@time using Modia
@time include("$(Modia.path)/test/TestTwoInertiasAndIdealGearWithMonteCarlo.jl")

After about 25 minutes, I stopped this.

Please, give advice what to do.

[MartinOtter]

Some further experiments (all with ODEProblem{true}(...))

Julia 1.8.0, DiffEqBase: v6.99.0

julia> @time using Modia
 24.335084 seconds (64.68 M allocations: 4.614 GiB, 5.36% gc time, 11.81% compilation time: 53% of which was recompilation)

julia> @time include("$(Modia.path)/test/TestFirstOrder.jl")
141.347746 seconds (253.24 M allocations: 22.811 GiB, 3.59% gc time, 98.16% compilation time: 2% of which was recompilation)

julia> @time include("$(Modia.path)/test/TestTwoInertiasAndIdealGear.jl")
 43.969008 seconds (74.08 M allocations: 8.073 GiB, 3.63% gc time, 98.42% compilation time: 7% of which was recompilation)

julia> @time include("$(Modia.path)/test/TestFirstOrder.jl")
  0.225871 seconds (115.53 k allocations: 6.059 MiB, 34.60% compilation time)

julia> @time include("$(Modia.path)/test/TestTwoInertiasAndIdealGear.jl")
  0.491862 seconds (278.42 k allocations: 15.121 MiB, 31.13% compilation time)

Julia 1.7.3, DiffEqBase: v6.95.2

julia> @time using Modia
 19.219514 seconds (44.73 M allocations: 3.334 GiB, 7.32% gc time, 10.17% compilation time)

julia> @time include("$(Modia.path)/test/TestFirstOrder.jl")
 92.356161 seconds (165.52 M allocations: 14.046 GiB, 4.91% gc time, 97.88% compilation time)

julia> @time include("$(Modia.path)/test/TestTwoInertiasAndIdealGear.jl")
 30.315695 seconds (51.16 M allocations: 4.992 GiB, 3.89% gc time, 96.18% compilation time)

julia> @time include("$(Modia.path)/test/TestFirstOrder.jl")
  0.227736 seconds (120.34 k allocations: 6.773 MiB, 33.52% compilation time)

julia> @time include("$(Modia.path)/test/TestTwoInertiasAndIdealGear.jl")
  0.465846 seconds (298.34 k allocations: 16.618 MiB, 32.43% compilation time)

Conclusion

using Modia and then simulate two different Modia models:

• Best Julia 1.8.0 version: 24.3s, 136s, 42s.
• Julia 1.7.3 version: 19.2s, 92s, 30.s.

Julia 1.7.3 and DiffEqBase: v6.95.2 has much better startup time for Modia. Therefore, for the moment stay with Julia 1.7.3.

[ChrisRackauckas]

ODEProblem{true}(...) seems to better as ODEProblem{true, SciMLBase.FullSpecialize}(...), because at the second run of Modia model the simulation is fast, whereas in the latter case a fast simulation is only achieved in the third run.

And it's only the second run because the precompile for your specific parameter type you're using doesn't have precompile snooping. If you setup precompile snooping, then that will completely change. You want to snoop a standard solve call.

Julia 1.7.3 and DiffEqBase: v6.95.2 has much better startup time for Modia. Therefore, for the moment stay with Julia 1.7.3.

Without precompile snooping, Julia v1.8.2 will be required to undue some of the compile time regressions of v1.8. v1.8.1 has some of the compilation regression fixes but not all.

[MartinOtter]

For DiffEqBase 6.103.2 and 6.99.0 (with Julia 1.8.1), Modia models that use MonteCarloMeasurements as floating point hang. Especially:

using Modia
include("$(Modia.path)/test/TestTwoInertiasAndIdealGearWithMonteCarlo.jl")

problem = ... is successful, but solve(problem, ...) hangs (terminated after 30 minutes).

Using DiffEqBase 6.95.5, precompiling Modia fails:

WARNING: could not import DiffEqBase.OrdinaryDiffEqTag into OrdinaryDiffEq
ERROR: LoadError: UndefVarError: OrdinaryDiffEqTag not defined

Also DiffEqBase 6.95.2 failed (although it worked previously).
Added OrdinaryDiffEq to the Project.toml file and changed from version 6.25.0 to 6.24.4. Gave the same error.
Changed OrdinaryDiffEq to 6.20.0. For this version, the OrdinaryDiffEqTag error did no longe appear and models with Measurements (TestPendulum) and MonteCarloMeasurements (TestTwoInertiasAndIdealGearWithMonteCarlo.jl) simulate.

I changed the Project.toml file of Modia to restrict DiffEqBase version to be 6.95.5 or smaller and OrdinaryDiffEq to 6.20.0 or smaller due to the occuring issues.

Since precompiling Modia is successful and TestTwoInertiasAndIdealGearWithMonteCarlo.jl simulates (does no longer hang),
all this seem to be issues with DiffEqBase and OrdinaryDiffEq and most likely need to be fixed in these packages.

And it's only the second run because the precompile for your specific parameter type you're using doesn't have precompile snooping. If you setup precompile snooping, then that will completely change. You want to snoop a standard solve call.

Thanks for this hint. I tried (with DiffEqBase 6.95.5 and OrdinaryDiffEq 6.20.0).
The five numbers in the item lists below are using Modia, include of TestFirstOrder.jl, TestTwoInertiasAndIdealGear.jl, TestPendulum.jl (uses Measurements), TestTwoInertiasAndIdealGearWithMonteCarlo.jl (uses MonteCarloMeasurements):

• Julia 1.8.1 with snoop precompile of one Modia model: 37.9s, 50.8s, 25.7s, 27.6s, 54.9s
• Julia 1.7.3 with snoop precompile of one Modia model: 17.0, 80.6, 30.2s. 36.4s, 68.4s

So, startup-time for models is reduced with snoop precompile and simulation is fast when called the second time. However, using Modia time is doubled (from 17s to 38s). Still, best approach so far both for Julia 1.7.3 an 1.8.1. The difference between the two Julia versions is not as large as I hoped.