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

> From: Herman Bruyninckx [mailto:[email protected]]
> Subject: RE: [Orocos] Re: dynamics: comment about MBdyn...
> 
> 

> 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.  Those are certainly supported in Modelica (the clutch model in the Modelica standard library is a great example).

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

I completely agree.  Having the freedom to choose an appropriate model and not be constrained by the solution method or the expressiveness of the modeling medium is a great thing and I would always advocate.

Interesting, we have already talked (within the Modelica design group) about the possibility of supporting impulses.  This opens up 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.  Dymola even had a beta implementation at one point.

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

It is also about not trying to solve every problem in the world.  Modelica tries to stay focused on a certainly class of problems.

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

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.


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

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.

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

I'm running out of time, a few terse comments:

1) Annotations are exactly equivalent to XML (i.e. syntax + structure - prescribed meaning).  As such, they are no better or worse really.

2) You don't have to use annotations.  If you want to store information outside the model, you can.

> Herman

--
Mike