@mtkmodel-ize LimPI

Specific Domains Modelling & Simulations
1

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 :slight_smile:

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:

dc_motor_discretecontrol.jl (3.7 KB)

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…

Thank you for your help!

2

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.

@ven-k

3

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.

I’m using this environment:

julia> Pkg.status()
Status `C:\Users\Asus\.julia\environments\msl\Project.toml`
  [0c46a032] DifferentialEquations v7.13.0
  [961ee093] ModelingToolkit v9.19.0
  [16a59e39] ModelingToolkitStandardLibrary v2.7.2
  [295af30f] Revise v3.5.14
4

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 =#
5

For @mtkmodel (and generally for macros), using @macroexpand1 can be useful to see if generated code is as expected.

6

I updated my packages and indeed now this issue is gone.
image

Now I am getting a different error now which is confusing me:

image
image1410Ă—506 24.3 KB

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 :slight_smile:

7

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

8

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.

9

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).