RE: Re: dynamics: comment about MBdyn...

On Tue, 15 Jul 2003, Tiller, Michael (M.M.) wrote:

[...]
> In other words, the semantics
> defined in the Modelica specification define rules for transforming
> a given Modelica model into a set of hybrid DAEs.  

Ok, this sentence raises another question with me: what properties
must a system have to classify as "hybrid"? I have some definition
myself, but I must confess it is very preliminary and generated by my
software design way of looking at the problem: in my view a system
must/can be called hybrid if its "causality" or (inclusive "or")
its "connectivity" (topology) are changed. "Causality" means that the
computational order of the DAEs must be changed (because something
that was an "input" has become an "output" or vice versa.
"Connectivity" means that the system of DAEs changes. (It seems that
both sources of change appear together in most cases ...)

Why would I be so pleased if the above definition were valid? Well,
because that means that exactly the same software infrastructure could
be used for the simulation of complex dynamical systems, as for the
computation of complex "agent based" intelligent robot control
systems. (And not only robot control systems, of course.) The reason
is that these complex systems become tractable as soon as one has a
clearly detectable and easily monitored check on the system, based on
which the decision can be taken to "re-schedule" the execution of the
software components behind the system. The "connectivity" and
"causality" changes are easy to detect, _if_ the software designer has
done its job well, and separated these "configurational" things from
the calculation of the "functional" things.

> Modelica specification stops and the implementations begin.  The
> nice thing about having a tool to do the elaboration is not just
> that it gives you the hybrid DAEs, but it gives them to you in
> symbolic form so that it is easy to pick up where the semantic
> processing left off and continue on with any additional processing.  

Would what I described above (monitoring for "hybrid" events) classify
as "additional processing"?

> Believe it or not, getting at the equations isn't of much interest
> to me (at least at the moment).
I also have the feeling that this is the simplest part of the whole thing...

[...]
> The point is that once you elaborate the model (in Modelica, we call
> this instantiation but I'm using the more general term "elaboration"
> because I think it is more intuitive), you get a flattened model.
> This is normally available to a given tool as a set of internal data
> structures organized as a tree.  
As a tree?? I would have expected a graph structure... (due to the
connections between the elements).

[...]
> Here are a few interesting observations about the symbolic
> processing.  First, Dymola recognized that despite the fact that 49
> individual variables were declared, there were only 6 unique time
> varying signals.  Of those 6, two are states (the others are
> evaluated algebraicly).  Of the 49 variables, 19 were aliases for
> other variables.  

Ok, this is a good example. I _think_ that using an appropriate
software design (the Oject-Port-Connector pattern that we use in
several places in the real-time kernel already) the above "symbolic
reduction" is trivial, and is a result of "parsing" (= the activity of
the object Factory for dynamical systems).

What do I mean with this Factory? I mean that a system is built by
definining (instantiating) objects (resistors, rigid bodies, etc.) and
connecting them together. At _each_ connection action, consistency
checks are performed, and alias variables are recognized. 
The Modelica file format has a quite good and natural support for this
Factory "parsing".

> Finally, note that there was a 4x4 linear system
> of equations present after the BLT transformation but Dymola
> eliminated it (my guess is that they replaced it with an analytical
> solution).
This is what I would call _real_ symbolic processing: recognizing that
some sub-assemblies of the whole system can be replaced by more
efficient components. I call this "real symbolic", because it cannot
be done at each connection of two objects by the Factory.

> An interesting thing to note about the symbolic processing is that
> it doesn't include any domain specific knowledge about resistors or
> robots or anything.  It just looks at the Modelica code, applies the
> semantic rules for constructing the system of hybrid DAEs.
Well, what is the difference between checking whether the "type" of
two components match (= semantic rule checking) and using domain
knowledge (e.g., a resistor cannot be connected to a rigid body)?

> Now before you say "but that doesn't help open source users", keep
> in mind that I'm not trying to sell you a copy of Dymola.  

I know. But your examples and discussions _do_ help me (and hopefully
also others) to make everyhting more clear in my mind. And I _know_
that we will end up with complete agreement, because the physics we
want to model is unambiguous :-)

> of Dymola would be a great way to at least develop some intuition
> and understanding about what kinds of symbolic processing is
> possible.  I realize that you don't want to rely on closed-source
> tools for your project but *that doesn't mean you cannot learn
> something from them*.
Of course. But the problem is not that I don't have an idea about what
these tools can do; the problem is that we use diffferent words to
describe things. And that's the basis lesson I have learned from over
2 years of Orocos experience: terminology is _sooooooooo_ important if
one wants to cooperate with others.

[...]
> I'm not sure that they changed much in DASSL (I really don't know),
> but I can say that they probably benefit enormously from the
> symbolic pre-processing (especially index reduction) that can be
> done *BEFORE* you pass the problem off to a numerical solver.

I truly believe this is absolutely right: the better pre-processing a
software package has, the better quality is gives. (Of course,
pre-processing is not the only quality a package should have :-)

[...]
> P.S. - Here is the complete Modelica source for my example including
> graphical annotations:
> 
> model Circuit 
>   Modelica.Electrical.Analog.Basic.Ground g
>     annotation (extent=[-10, -40; 10, -20]);
This brings me to another thing that troubles me a bit: I have an
intuitive dislike of putting the "graphical rendering" into the same
file as the physical modelling... I think the modelling file should at
most contain (unique) names of the different physical components, and
that the rendering should be defined in other files. (Note: "files" in
plural, because it should be possible to give the same system
different visualisation "on the fly".) These "other files" can then
connect a visualisation to a _name_; or to a _type_.

Herman

-- 
  K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480