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

> -----Original Message-----
> From: Herman Bruyninckx [mailto:[email protected]]
> Sent: Tuesday, July 15, 2003 3:31 PM
> Cc: '[email protected]'; Open RObot COntrol Software
> Subject: RE: [Orocos] 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"?

The meaning is completely different than what you describe...I'll get to
that in a minute.  First, let me address what you describe...

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

The single most important aspect of physical modeling is the idea that
component models should not be developed under specific causality
assumptions.  In the Modelica group, we call this acausal modeling.  The
idea is that when you develop a component you should only describe the
relationship between information available at the connectors of a component.
The way I usually describe this to engineers is that you build a component
model the same way you build a "free body diagram" or a "control volume".
You relate all external influences to either the states in the component or
to each other.  No specific causality is implied!

Two important caveats:

1) You can specify causality *if you want to*.
2) What I said applies to physical modeling, not control systems.

I mention these last two caveats because people (for reasons I do not
understand) assume that Modelica is only good for physical modeling or that
if they wanted to do control system modeling they wouldn't be able to
develop models using causal formalisms and this is not correct.

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

I think of causality in terms of sensors and actuators (i.e. at a physical
level) not in terms of the solution method.  In theory, you can just throw
all the equations into a general purpose DAE solver and it really doesn't
care about the causality.  By analogy, you can throw a lower triangular
matrix into a dense matrix solver and it will solve it.  It won't make
clever use of the structure but it doesn't have to.  So I don't quite agree
with "the computational order of the DAEs *must* be changed".

> "Connectivity" means that the system of DAEs changes. (It seems that
> both sources of change appear together in most cases ...)

OK.  Now this is the more fundamental point.  If I understand correctly, you
mean hybrid as changing form dynamically.  As I said, this is not what it
means in Modelica.  You will probably not be happy to learn that the
semantics of the Modelica language are built around the principle that for a
given system, the causality and connectivity (as you have defined them) must
be fixed and known.

But all is not lost.  There is nothing in Modelica that discusses or even
concerns itself with co-simulation of two entities that have the same
input/output pattern but different internal causalities and connectivities.
By the same token though, it doesn't define how one would be initialized by
the other.

In summary, at first this may seem overly restrictive to you, but keep in
mind that the assumption only holds over the semantics in the Modelica
specification (about processing a Modelica file into a set of equations) and
doesn't restrict how you use the generated representation.

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

I think I understand what you want to do.  I don't claim to have much
experience with such things.  I do not see these kinds of issues in my work
so I won't comment.

> > 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"?

Precisely.  This is beyond the scope of the Modelica specification.  The
semantic rules apply to any particular configuration but you could use
several in parallel if you wanted.  That is part of the implementation and
solution.

Now, lets address another terminology issue.  When Modelica says "hybrid"
what that means is that the underlying DAE may include both continuous and
discrete variables.  There are certain semantics for describing discrete
changes in values and iterations over discrete systems of equations.  I'm
not that familiar with them, but you will find them in an Appendix of the
specification.  So hybrid equals "mixed systems of continuous and discrete
variables".

As an example, for a seminar recently I built a model using a Petri Nets
library in Modelica.  While you may think of Petri Nets as being full of
imperative semantics, it was quite interesting to note that the Modelica
model was fully declarative.  All the discrete states were described purely
in terms of equations.  That wasn't necessary, but it was interesting to
note that it could be formulated that way.

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

Keep in mind that the identification of aliases is (generally) done once the
complete system is assembled, not on the fly.  I'm not familiar enough with
the semantics to know whether on-the-fly would be sufficient.

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

Yes, and there is plenty of it.  A great example (from my line of work) is
in computing properties of fluid flows.  Two or more components may be
looking at a fluid that has identical states.  Each computes the enthalpy by
"real symbolic" processing can recognize that the calculation of the
properties is based strictly on pressure, temperature and composition of the
flow and it can eliminate redundant calls to the property routines.

Note that while the factories can do some stuff, they cannot do everything.
If you want to do the "real" symbolic stuff, why not do the factory stuff at
the same time.  That compresses two layers or passes down to one.

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

This is an area where I think the status quo is to rely mainly on numerical
techniques.  One of the things that really impressed me about Modelica was
how the semantics protect for lots of symbolic optimizations.

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

I used to think so too.  VHDL-AMS took this approach.  I'm now quite
convinced that embedding the information in the models is "A Good Thing".
Annotations are semantically different than the mathematical representation
of the model so it is easy to separate them.  In fact, you don't need to
include them at all.  For me, having them standardized and bundled is much
better in a practical sense (although I suppose from a theoretical
perspective it would seem cluttered).

> Herman

--
Mike