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

> From: Herman Bruyninckx [mailto:[email protected]]
> Subject: RE: [Orocos] Re: dynamics: comment about MBdyn...
> 
> 
> On Wed, 16 Jul 2003, Tiller, Michael (M.M.) wrote:
> 
> > > 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.)

I'm not talking about code design, I'm talking about language design and if language design were simple and clear cut than we would have one language and everything would be written in it.  The reality is that there are hundreds of programming languages for doing a wide range of different things.  Although I'm not going to imply that every programming language is well designed, I don't think that just because there exists a multiplicity that at least all but one must be poorly designed.

Look at C++, Java and C#.  They are remarkably similar but the developers made deliberate design decisions related to garbage collection, efficiency, OO models, etc.  They aren't wrong just because they differ.

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

It is interesting to note that you invoke patterns and the factory pattern specifically.  It is interesting to me for two reasons.  First, Ralph Johnson (a co-author of "Design Patterns") was on my thesis committee so I'm familiar with many of the patterns.  In fact, I was familiar with some of those patterns even before the book was published from looking at a GUI toolkit, InterViews, that John Vlissides worked on.  The factory (or "kit") patterns is a great pattern.  That is why I find it interesting that you invoke it here because you can do exactly what you describe with Modelica.  In other words, you can use the factory pattern in Modelica (my group uses it in a couple of different ways in fact).  It is a pretty advanced idiom in Modelica, but the language definitely supports it.  Here is a simple example:

package PartsFactory
  partial model RevoluteJoint
  end RevoluteJoint;
  partial model InertiaBase
  end InertiaBase;
  partial model Link
  end Link;
end PartsFactory;

package SimpleRobotFactory
  extends PartsFactory;
  model RevoluteJoint = SomeSimpleRevoluteJoint;
  model InertiaBase = SomeSimpleInertiaBase;
  model Link = RigidLink;
end SimpleRobotFactory;

package ComplexRobotFactory
  extends PartsFactory;
  model RevoluteJoint = RevoluteJointWithBacklash;
  model InertiaBase = SomeSimpleInertiaBase;
  model Link = FlexibleLink;
end ComplexRobotFactory;

model MyRobot
  replaceable package Factory=SimplePartsFactory extends PartsFactory;
  Factory.RevoluteJoint joint;
  Factory.InertiaBase base;
  Factory.Link link;
equation
  connect(joint,link.a);
  connect(base,link.b);
end MyRobot;

model MyComplexRobot
  extends MyRobot(redeclare package Factory=ComplexPartsFactory);
end MyComplexRobot;

Keep in mind I'm just typing this in off the top of my head so I probably made a few mistakes.  The point is to convey the concepts.

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

I suspect you will always find the inclusion of the graphical annotations distasteful so I'm not really going to attempt to convince you otherwise, but here are some of the reasons that went into the decision to have them in the model:

1 - Annotations are not used strictly for graphical representation.  In addition, annotations are used for documentation as well (e.g. embedded HTML).  The result is that you can consider a single Modelica model to be composed of several different orthogonal layers.  One layer is the icon (the external view of the model).  This is provided by one annotation.  Another layer is the diagram layer and this is controlled by a different class of annotations.  The third layer is the documentation which represents the content of the documentation annotation.  Finally, there is the remainder of the model which is everything that isn't an annotation.  This is strictly the behavioral aspect of the model.  One reason I consider annotations a good thing is that I can bundle all this up together and it also facilitates automatic generation of HTML documentation that combines all this information (all 
 the layers) into a very nicely organized an coherent document.  Think of it as "literate !
 modeling" (ala literate programming).

2 - Annotations currently only deal with static data, but there is no fundamental constraint about this.  What this means in practice is that you can tie the graphical representation of the model to the content in the model.  So to answer you question about different visualizations, you can have the appearance of the graphics be a function of the parameters in the model (i.e. you can control the appearance in this).  Going even further, you can associate the representation of the graphics with the time-varying signals in the model and produce some very nice 2D animations via the annotations.

3 - One reason annotations are not rigidly defined is that different tools may use different sets of annotations.  There is a principle in the design of the language that if a tool doesn't recognize an annotation (i.e. a certain kind of meta data) that it should simply leave it alone (and pass it along).  This gives different tools flexibility in being able to embed additional kinds of meta data without having to worry that another tool will strip it out just because it doesn't know what the data is.

As I said before, I don't have an objection to introducing a way of validating meta data.  I think you're proposal to use XML is really practical.  I think it would be too jarring to use XML for the annotations and try and reconcile it with the syntax of the remainder of the language.  What you could do (and if I get time to formulate these ideas, I will try to put together a proposal) is associate the structure of the annotations with Modelica records (an existing construct in the language) as a way of representing the schema.  Then you might get something like:

package RobotStuff
  record RobotPartData
    String manufacturer;
    Integer year_produced(min=1900,max=2100);
    Integer serial_number;
  end RobotPartData;
  partial model RobotPart
    annotation(RobotPartData:robotData);   // Associate record with data name
  end RobotPart;
  model MyPart
    extends RobotPart;
    annotation(robotData(manufacturer="Kuka",year_produced=1999,serial_number=533295));
  end MyPart;
end RobotStuff;

This is all perfectly legal Modelica code except for the commented line.  In fact, there is nothing that prevents *YOU* from defining your own annotation to define such relationship, e.g.

  partial model RobotPart
    annotation(Schema(data="robotData",schema="RobotPartData")));
  end RobotPart;

Now you have example of something that is perfectly legal in Modelica today.  Then you could write the equivalent of an XML validator for Modelica that could check that any annotation named "robotData" had only the elements found in "RobotPartData".

I happen to think this design is a very nice compromise because it lets you implement your own validation scheme for your data, lets you completely ignore the metadata or use meta-data in a free form way.  A big part of building a standard is to recognize the need for compromise.  You seem to think the system is flawed because it doesn't force the rest of the world to implement exactly your level of rigidity whereas I see the system as elegant for exactly the same reasons.

> Herman

--
Mike