I am playing around to get some motor control simulations running with modeling toolkit. Last time I did that it was 2y ago so the syntax has changed (and got more simple to read).

While trying to implement a timediscrete PI controller I started to copy LimPI from the ModelingToolkitStandardLibrary. Since I thought it would be good idea I modified it to use the @mtkmodel syntax

But for some reason I am not able to get it to run. I am trying to debug why, but I have no success.

The error I am getting is:

ERROR: MethodError: Cannot `convert` an object of type SymbolicUtils.BasicSymbolic{Real} to an object of type Float64

Plus the stacktrace. Here is the file I am working with:

If you could point me in the direction why/what is failing, it woudl be great. But even better would be if you could point me in a direction to learn how to better debug these.

I have tried to inspect the equations and parameters, between the working version (with function LimPI(â€¦) ) and the non working version, but I really miss the know how how to even properly compare the modelsâ€¦

This actually seems to be a bug in Limiter in that it has fake parameters u_start and y_start that canâ€™t be set, but they only exist due to a macro bug.

I tried the dc_motor_discretecontrol.jl script, the error no longer appears. @gruemelmonster can you retry and confirm if you are still facing this issue.

Types are not added to the args of subcomponents. Thatâ€™s why they accept any type â€“ even symbolic values. Iâ€™m not sure why that error came, but for this reason they donâ€™t appear now.

Although not the case here, I noticed that for top level parameters/variables, types are added (here: a1_val::Union{Nothing, Real}) ; and that should include symbolic types (here it should become: a1_val::Union{Nothing, Real, Num, Symbolic.BasicSymbolic})
Iâ€™ll make this change.

julia> @mtkmodel A begin
@parameters begin
a = 1
end
end
julia> @macroexpand1 @mtkmodel A2 begin
@parameters begin
a1_val
end
@components begin
a1 = A(a1_var = a1_val)
end
end
:(A2 = (ModelingToolkit.Model)($(Expr(:(=), :(__A2__(; name, a1_val::Union{Nothing, Real} = nothing, a1__a1_var = nothing)), quote
#= C:\Users\Asus\.julia\dev\ModelingToolkit.jl\src\systems\model_parsing.jl:132 =#

As you can see model is 4 equations with 4 unknowns.

But when I give it to ODEProblem it warns that the system is overdetermined 10 equations and 0 unknownâ€¦
Not sure the error following is related to the observation above or not.

P.S.: Looking forward to your talks at JuliaCon, I am currently looking for Hotels

Itâ€™s not, itâ€™s related to the initialization. So you might have given a ton of initial conditions, even for the algebraic variables, which makes it overconstrained. For example, if you have a differential variable x, y equal x as an algebraic equation, and give an initial condition for x and y, then your initialization is overconstrained. Thereâ€™s three equations, two for matching the initial conditions and one for x equals y, and it needs to numerically prove that those 3 equations can be simultaneously satisfied which it will do via a least squares solve. But it will warn you because likely the best thing to do is make the system correctly constrained, which in this case is deleting one of the initial conditions since giving both and x equals y is redundant information.

See the initialization tutorial for more details.

What youâ€™re seeing the warning for is a form of that. If it is consistent it will still run though

The problem here might come from the standard library, there hasnâ€™t been a new release in a while so the latest version might still have a lot of defaults that introduce additional equations in the initialization system.

Thank you! Even though the warning is saying exactly what you explained I did not see that there is a difference between the equations of the model and the â€śInitialization Systemâ€ť.

So in the end, I can see that the original LimPI from Standard lib has exactly the same 10 equations for 0 unknonws and it is running fine.
I was just jumping at the warning because the errror does not tell me anything.

Since the error occurs only with my @mtkmodelized version, I tried to compare Blocks.LimPI to my version (by copying their model output from the repl into a file and trying to make a diff, which of course is not possible). I really feel like a complete nuub, since I am sure there must be a better way to debug this, but I am just lacking the skills to do it. â€“ I guess I have to learn quite a bit moreâ€¦

Again if you could point me in a direction on how to figure out whats going on during â€ścompilationâ€ť I would be happy to debug it myself (and learn).