Display of systems not copyable

[baggepinnen]

I find that the printing of types from MTK sometimes adds friction because they are printed in a way that does not allow copy-paste of code. The example below illustrates the problem. Is there any particular reason to print the ₊ instead of a .?

julia> fb
Model fb with 13 equations
States (13):
  u(t)
  loopgain₊y(t)
  loopgain₊u(t)
  y(t)
  loopgain₊C₊u(t)
  loopgain₊C₊y(t)
  loopgain₊nonlinear_P₊u(t)
  loopgain₊nonlinear_P₊y(t)
  loopgain₊C₊x₁(t) [defaults to 0.0]
  loopgain₊C₊x₂(t) [defaults to 0.0]
  loopgain₊nonlinear_P₊P₊u(t)
  loopgain₊nonlinear_P₊P₊y(t)
⋮
Parameters (0):

julia> loopgain₊C₊u
ERROR: UndefVarError: loopgain₊C₊u not defined

julia> loopgain.C.u
loopgain₊C₊u(t)

[YingboMa]

There's a reason to print ₊.

What exactly do you want to achieve? Do you want to just copy-paste or to serialize the model.

[baggepinnen]

It's related to my post here
https://discourse.julialang.org/t/accessing-variables-in-a-modelingtoolkit-system/57249/8?u=baggepinnen
basically, when I try to figure out how to supply initial conditions for a sub system deeply nested in a structure like

julia> states(fb)
13-element Vector{Term{Real, Nothing}}:
 u(t)
 loopgain₊y(t)
 loopgain₊u(t)
 y(t)
 loopgain₊C₊u(t)
 loopgain₊C₊y(t)
 loopgain₊nonlinear_P₊u(t)
 loopgain₊nonlinear_P₊y(t)
 loopgain₊C₊x₁(t)
 loopgain₊C₊x₂(t)
 loopgain₊nonlinear_P₊P₊u(t)
 loopgain₊nonlinear_P₊P₊y(t)
 loopgain₊nonlinear_P₊P₊x₁(t)

it would be convenient if I could copy the line loopgain₊nonlinear_P₊P₊x₁ to my code. Even better would be if I could just supply the initial condition for P.x₁ without knowing the exact structure of the bigger system P is a part of.

[YingboMa]

Right, but you could just search and replace ₊ to ..

[YingboMa]

Also, be aware that the pretty printing of the system will be truncated if you have too many states. I am not sure printing . in the system pretty printing is what you actually want.

[baggepinnen]

Right, but you could just search and replace ₊ to ..

I can, but this is friction. There are two problems here really, one problem is pretty printing in a way that differs from code, having the printed representation be valid code for something, e.g., reconstructing the type

julia> show(randn(3))
[-0.3272905809691419, -0.5926805287286862, -0.4503637884755196]

is generally useful. The other problem is that I find it hard to access states in hierarchical systems, maybe because I haven't found the smooth way of doing this, or because there's room for improvements on this front.

[ChrisRackauckas]

We should follow the Julia convention. I think the two argument show should round trip IIRC?

[YingboMa]

Instead of printing, I think this should be handled by adding default values in the metadata. #846

[baggepinnen]

The default values do not really solve the problem of accessing states of subsystems
#874 (comment)
puts it in another way.
In simulink, I would double-click a block to provide the initial conditions in a graphical interface. In the absence of such an interface, I must somehow be able to reach into the internals of a model, even if it was created by some unknown function with another author and handed to me. Right now, the "clicking the block and providing the initial conditions" feels harder than it has to be. The printing issue might seem trivial to you, but right now I can't think of any other strategy than to print all the states to the terminal to figure out how to address them. That I can't copy the printed text certainly adds a bit extra friction to the usage. Of course, this would be somewhat less of an issue if it was easier to reach into the model to address exactly the component I need to address.

The fact that vector states use unicode subscripts

julia> @variables x[1:3]
(Num[x₁, x₂, x₃],)

is another thing that may look nice, but shouldn't really be part of the exposed interface since many people simply aren't able to type the name of such a variable. Indeed, I myself cannot type x₁ in the web browser. If my colleagues hands me this system for me to simulate

julia> states(loopgain)
11-element Vector{Term{Real, Nothing}}:
 u(t)
 C₊u(t)
 C₊y(t)
 nonlinear_P₊u(t)
 y(t)
 nonlinear_P₊y(t)
 C₊x₁(t)
 C₊x₂(t)
 nonlinear_P₊P₊u(t)
 nonlinear_P₊P₊y(t)
 nonlinear_P₊P₊x₁(t)

and I cannot type x₁, I'm left with having to copy-paste the variable name from the terminal.

I'm still a new and inexperienced user of MTK, all my previous attempts at experimenting with it have ended with feeling that simple things are too hard to accomplish compared to the established alternatives like simulink or modelica. I of course see and appreciate the enormous potential and I would really like it to improve its usability, hence my rapid fire in opening new issues, I hope you bear with me. MTK has a lot to prove next to modelica, especially here in Lund ;) I'm sure you have all looked at Modia and TinyModia both once and twice before, and I think that there are a lot to learn from Hilding and Martin Otter. There is no toying around in the Modia examples, it's straight for servo control with motor models, PI controllers and sensors
https://github.com/ModiaSim/TinyModia.jl/blob/main/examples/ServoSystem.jl
or 6-axis robots with full control systems and interaction with the environment
https://github.com/ModiaSim/Modia3D.jl/blob/master/examples/collisions/Simulate_YouBot.jl
I actually find this approach with providing actual realistic models as examples very instructive, and in doing so, you press the interface not only with unit tests, but also from a usability perspective.

[YingboMa]

@ChrisRackauckas and I talked a bit about handling array variables by storing them separately in a system. I will implement that soon.

[YingboMa]

Ah, I replied to the wrong issue.

Alright, I will change the printing to .. I don't think this solves the core issue, though. loopgain.u gives a name-spaced variable, so you still have to do @nonamespace loopgain.u in the initialization. But maybe this is just how things are without a GUI.

Be warned that @nonamespace is an experimental API, so it's subject to change. We are still trying to design friendly APIs together with the users, so do expect some changes down the line. If something is not explicitly documented, it may be changed in the future. Since MTK is still at its early stage, I don't want to fully commit to the current APIs yet. I will put depwarns should there's a minor breaking change though, so don't be too scared.

BTW, I am working on the state-selection pass at the moment, so we'll be able to show some of the basic multibody dynamics modeling capability soon.

[asprionj]

Three ideas come to my mind:

1. Have a "print_system" function. This would just output the model hierarchy, as a tree view, as text. All nodes would be (optionally?) written out with the entire path through the model hierarchy, to copy-paste it. Could this already help?
2. A bit nicer to look at: visualize the model hierarchy as a graph. Work would be minimal, just map the model structure to a di-graph in any graph library and have it plotted.
3. Much cooler, but a ton of work: spin up a live web-server, serve a visual representation (as a web-page) of the model. One could interact with this model as with e.g. Simulink, and possibly even copy to the clipboard the "paths" of selected systems, state variables, parameters, ...

Should we have a separate issue about "Visual model representation and interaction"?

Edit: Point 1 above I implemented for a very basic component-based modelling framework I implemented in Julia. Exemplary output of that framework's print_model_tree function:

overall (assembly, 3 children)
|-> gainOneAsbly (assembly, 2 children)
|   |-> avgTwoPT1 (assembly, 2 children)
|   |   |-> twoPT1 (dynamic, nx = 2)
|   |   |-> avgTwo (algebraic, ny = 1)
|   |
|   |-> prod2 (algebraic, ny = 1)
|
|-> singlePT1 (dynamic, nx = 1)
|-> timesTwo (algebraic, ny = 1)

[ChrisRackauckas]

Should we have a separate issue about "Visual model representation and interaction"?

Yes.