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

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

> > 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,
> 
> Fair enough.  You are talking more about things like ideal diodes or
> clutches then right?  We call those multi-modal models.  
Aha, another term for our glossary :-) Just using the term "state"
instead of "mode" would have been much more meaningful :-)

[...]
> Interesting, we have already talked (within the Modelica design
> group) about the possibility of supporting impulses.  

Seems to be easy: since there is no real good model of mechanical
impulse, any approach will do :-) I've seen real-time simulation of
humanoid robots with tens of degrees of freedom, in which the user can
give impulses, resulting in behaviour that _looks_ realistic. But
isn't, because the impact model is arbitrary. (Or rather, too complex
and with too many application-specific parameters.)

> another level of "freedom" and these can be handled symbolically
> rather than numerically.  The result is the ability to do things
> like contact without (necessarily) having to deal with stiffness.
No, using impact to do smooth contacts (i.e., constraints!) is not a
good idea. Impact models are only good for "particle like"
interaction, like in ODE (<http://opende.sourceforge.net/>).

[... absence of hybrid systems in Modelica...]
> It is also about not trying to solve every problem in the world.
> Modelica tries to stay focused on a certainly class of problems.
That's a good approach :-) The only message I wanted to give is that
the same computational infrastructure (DAE + events) could without
problems support any extension that Modelica would like to make in the
field of hybrid systems.

[...]
> > 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.
> 
> I'm not sure why you think this is really an error.  Keep in mind
> that in Modelica all connections are constraint relationships.  If
> your "connection" has behavior associated with it (e.g. elasticity)
> then it isn't a connection, its a component.
Right! What I meant with being "decoupled" is that the information
about connections is in a separate place in the file, instead of being
at the same block where the constitutive relationships are of the real
physical body that one models. Having separate file positions for
information that physically belongs together is asking for troubles;in
this case, the troubles are the more involved processing of the model
that has to take place: the processing has to find out what belongs to
what, while a real "object oriented" model would keep this information
together. A (good) XML schema would do this, for example :-)

[...]
> I don't have enough time to go into this.  Mainly it is because the
> annotation are standardized (their in the specification) so I don't
> think this really is as chaotic or unstructured as you think it is.
It is! Also void pointers in C are standardized; which doesn't mean
they are mean :-)

[...]
> 1) Annotations are exactly equivalent to XML (i.e. syntax +
> structure - prescribed meaning).  As such, they are no better or
> worse really.
They are because there is no "schema" involved. 
>
> 2) You don't have to use annotations.  If you want to store
> information outside the model, you can.
> 
Of course. But that "flexibility" is asking for problems! It's an
example of what you call "co-simulation": two or more places to keep
the information that really has a well-defined connectivity structure
is definitely Not A Good Thing :-( 

Herman

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