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

On Wed, 16 Jul 2003, Tiller, Michael (M.M.) wrote:

[...]
> > > 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.)
> 
> Keep in mind that in Modelica, we are not talking about a "model" of
> impulses or impact.  We are talking about mathematical impulses.  It
> is still up to the modeler to decide what the "model" is (e.g.
> coefficient of restitution, perfectly elastic, perfectly plastic,
> etc.).  The point is that they can express behavior that involves
> impulses (e.g. velocities changing value discontinuously) and the
> rest of the system will respond appropriately (i.e. compute the
> total instantaneous momentum transfer required to achieve the result
> and make sure that momentum was conserved by changing other
> velocities instantaneously).  This isn't just about mechanical
> systems, impulses are very useful in many domains (electrical
> systems, combustion, etc).

I don't know about how easy it is on other domains than the mechanical
to identify the parameters involved in the impact model...? In
mechanics anyway, providing a parameterized model is doable, deciding
what parameters to use in order to have your model mimick reality
realistically is much more difficult. But of course, this doesn't mean
that having the feature in Modelica is bad, on the contrary.

> > > 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/>).
> 
> Again, I'm not talking about a specific model, I'm talking about
> mathematical expressiveness.  I agree, you don't want to treat the
> interaction as strictly impact.  But, with impulses you might model
> the initial collision as a perfectly plastic interaction (no
> bouncing) and then switch to a mode where the two surfaces are
> constrained to stay together until the reaction forces become
> positive and then you switch to another model where they are free
> bodies again.  This is exactly how clutches are modeled except for
> the impulse part.
Indeed. And that's a good proof showing that all you need are events
or FSM to cope 
> 
> > [...]
> > > > 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 believe any of this.  Much of what you say is completely
> arbitrary.  There is far too much language in this discussion about
> the "right" way to do things or the "real" way to do things.  I
> really think you need to have more appreciation for the fact that
> designs bring with them plenty of aesthetics and other subjective
> influences.  No human endeavor is ever as clear cut as you always
> imply.

Human endeavors are not; code design and implementation should... I am
very strict on that topic. And I have paid the price of non clear-cut
designs way too often in the past myself... (BTW that was the number
one reason why I was motivated to start with Orocos in the first
place.)


> Furthermore, I still don't think your argument is at all compelling.
> Each modeling model contains a set of declarations first and then
> zero or more equation and/or algorithm sections.  This is very much
> like the model you will see in Java and C++ where you have members
> (declarations) and methods (code).  So invoking arguments like "this
> isn't a real object oriented model" I think are just a waste of
> bits.

I don't think so! I am even quite sure it isn't so. Let me try to
explain with an example, i.c., building the model of a robot,
including motors and transmissions. (In fact I will be repeating the
Factory pattern here.) 
When starting, the only thing the building Factory will allow me to do
is to choose an inertial base. Then, a rigid body link, which has to
be connected to the base, or I cannot proceed. Then, a joint, to be
connected immediately to a place where it can be connected. Then the
transmission; to be connected to the joint axis. Etc...
This approach is very different from the traditional one (as
implicitly used in a Modelica file), of first creating all links, all
joints and all transmission, and only then beginning to make
connections. In this latter case, your building software has to check
afterwards whether the system is consisten, whether you have not
forgotten to connect objects, etc. Of course, in practice a skilled
programmer will not make errors, but being able to _avoid_ errors is a
nice thing to have in a large scale distributed development system.

> Finally, ignoring the comparisons with C++ and Java altogether, I
> think you need to give the people in the Modelica effort much more
> credit than you have.  

I do give them credit, a lot even! But why should I not be allowed to
say what I think they missed? There is no personal judgment involved
whatsoever. And I am open to the same kind of criticism myself.
This is the way science progresses, you know :-)

> But when you continually imply that the
> design of Modelica is "wrong" (meta-data, too much coupling, not
> enough coupling, etc), 
I say where I think it can be better. That's _very_ different from
categorizing Modelica as wrong. Very different. And if I have ever
given the impression that you have, I can only apologize.

> I think you not only fail to recognize that
> there is some level of inherent arbitrariness in any design but also
> that perhaps there are details of the decision making in the design
> that you are just not seeing.  

I _know_ that there are many things I do not see. I just don't know
what things that are :-) So, this kind of discussions we are having
helps me a lot to find out more.

> Personally, I can think of several
> arguments to support the Modelica design and refute your notion that
> it is wrong, but I just don't have the time to get into it.

Well, that doesn't bring us any further does it :-) But of course, you
are not obliged at all to do the effort if you are in lack of time.

You are misrepresenting my criticism however, since the only points of
criticism I raised were:
 (i) the introduction of the "annotation" primitive (which gives rise
     to the "flexibility" to do anything you want),
and
(ii) the separation between declaration ("construction") of objects and
     connection of these objects.
Point (ii) is much less of a problem than (i) (it involves only some
overhead from the model "parser"), and in practice (i) is only used
sparingly, so that's also not a real problem. But the fact that these
concepts are not really abused for the time being, doesn't mean that
these concepts are "good".

> > [...]
> > > 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. 
> 
> There is a schema for the graphical annotations although I agree
> with you that in general there is not formal way of associating a
> schema with the annotations.  Within the group, the informal
> association uses record definitions (as you can see in the Modelica
> v2.0 specification).  I would probably support a proposal to
> optionally allow a formal association between record definitions and
> annotations.  Why don't you make a formal proposal?

I just did: an XML + Schema based model representation :-) I would
replace the annotations with a well-discussed set of extensions.
This set would follow quite straightforwardly from a survey of the
reasons that people currently are using the annotations for.
The graphical Icons and Diagrams are already in the specs; maybe one
doesn't need more... I still find it not a good idea to encode
graphical shape in the Modelica file: what do you do when you want
different visualisations? (E.g., a high resolution and low
resolution.)

Herman

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