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

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


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

I know that, no problem :-)

> 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!
"constitutive relationships" in Bond Graph parlance :-)

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

I don't fully agree! Sensors and acutators are sources with a natural
and fixed causality. But in many complex systems, the
simulation/control software must determine an _ordering_ of the
calculation to perform. That's also called "causality", and that's
what changes in a "hybrid" transition,

In theory, you can just throw
> all the equations into a general purpose DAE solver and it really doesn't
> care about the causality.  
It does! But it does this blindly, and tons of papers have been
written about how to solve "stiff" systems! Most algebraic constraints
in the DAE are just approximations for poor modelling; e.g., each
contact between mechanical objects _has_ impedance, but it is much
easier not to model it. The result is that the DAE solver must
introduce "impedance" in the constraints; it would be much better if
phsyically relevant impedances could be used. FOr example, when
modelling a body-body contact with an algebraic constraint, knowing
that it is a body-body contact is useful to determine in what
"directions" the DAE can be made "less stiff". And introducing these
impedances implies choosing a "causality". So, instead of letting the
DAE solver work blindly with all constraints, a symbolic preprocessor
(again :-) could help out a lot, obeying the real physics.


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

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

It's not about me being happy or not about it :-) It's just very
involved and advanced to work with hybrid systems, so probably not
enough people have felt the need to have it into the Modelica specs.

[...]
> > Would what I described above (monitoring for "hybrid" events) classify
> > as "additional processing"?
> 
> Precisely.  This is beyond the scope of the Modelica specification.  

I've seen a couple of mentions about introducing hybrid models in
Modelica. Here for example:
 <http://www.modelica.org/papers/IEEE_P.pdf>
(And this corroborates my previous suggestion that having events and
FSMs is sufficient. In fact, event alone are sufficient, because also
FSM can be implemented with them.)

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

I know. And I think we are talking about the same things, after all.
These discrete variables are most often representations of a different
"configuration" of the system, corresponding to another model, i.e., a
change in connectivity or causality. At least, that's my understanding
of it. That understanding is given by seeing way too many people use
discrete variable in Simulink when they really want to model
different states of theirs system. (It's worthwhile to read about
the State Software Pattern: it's exactly what I (try to) explain above
:-)

[...]
> 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.
I am quite sure it would _not be sufficient_! But it would cover an
important part of the aliases and other "identities" already early in
the processing. I think that the "problem" in Modelica lies with the
fact that the connection information is decoupled (erroneously so!)
from the constitutive relationships and/or the constraints of the
objects. And the processing afterwards to correct for this decoupled
information is (moderately) costly.

[...]
> Note that while the factories can do some stuff, they cannot do everything.
Absolutely so. The "real symbolic processing" is (by definition)
beyond their scope.

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

> Annotations are semantically different than the mathematical representation
> of the model so it is easy to separate them.  

That separation is not the problem. The real problem is that Modelica
makes a coupling with _one particular_ representation, and that is
very inflexible. What do you do if you want to visualise a system in
two ways: one iconic diagram, and a second 3D visualisation? Embed
both in annotations? And then adding more annotations to give
information about when to use what graphical representation?
No thanks! This annotation "solution" is nothing more than a poor
version of a pointer: you can put anything in annotations, so it has
not structure at all that can really be used to make the processing of
the model more scalable or more maintainable or more efficient.
I really think the annotation was the result of the Modelica
desingners being at their wits end how to put more semantics in the
models, so they introduced this "void pointer solution" :-)

> In fact, you don't need to include them at all.  
A good sign that nobody knows what they really mean. So leave them out
:-)

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

Annotations are really nothing better than a void pointer. And these
do most certainly _not_ scale in complex systems. (Complexity is
meaning more than having many components: it's also about having your
system change on line, being distributed, being accessed from multiple
places and by users with different needs. 
In software terms: Modelica is C, I am looking for Java or C++ :-)
(But they should use C where possible behind the screens, when
efficiency matters :-)

Herman

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