Re: dynamics: comment about MBdyn...

Herman Bruyninckx writes: 

I'm here, following your discussion; only, you're moving
to a ground a bit too hard for me.  But I'm learning ... 

>> 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.
> No problem with the syntax :-) But in my opinion, a real Factory does
> more than what you describe: it should perform checks during
> construction. (Of course, I guess it is difficult to enforce these
> checks in a file format.) So, what I meant in a previous email is that
> the sequence of constructors
>    Factory.RevoluteJoint joint;
>    Factory.InertiaBase base;
>    Factory.Link link;
> would not be allowed to happen without the connections
>    connect(joint,link.a);
>    connect(base,link.b);
> Using your example, I would prefer to see something like this
> (violating the Modelica syntax, I know):
>   Factory.InertiaBase base;
>   Factory.Link link; connect(base,link.b);
>   Factory.RevoluteJoint joint; connect(joint,link.a);
> The difference with your example is that the file parser can detect
> inconsistencies _immediately_, while in the Modelica the checks are
> "delayed" until the parser reaches the "equation" section. This is not
> a problem for small scale files, but it is for large scale models,
> where the human cannot oversee the complexity anymore. Or when models
> are changed/adapted at runtime (which is inevitable in complex
> interactions). That means that a valid Modelica description can make
> you loose lots of time, for the same reason as a non-allocated memory
> pointer causes problems in large-scale C-programs...
> Of course, the Factory cannot guarantee that what it constructs
> corresponds to what the programmer _thought_ he was modelling, but
> lots of errors could be caught this way.

Actually, what you're suggesting is in contrast with  one
of the peculiarities of Modelica -- one that allows A LOT
of flexibility and code reuse. 

Going back to your example, the factory model you propose trades
early consistency checks with modeling flexibility.  Think of a
system that is made of components which can be connected in
different ways -- of course, provided the resulting system is
consistent; then one could define a model made of components only,
and some descendant models that inherit from the base model with
no connections by connecting the common parts in different -- but
legal -- ways.  The intermediate model would be inconsistent, but
it can declared so (i do not remember the syntax and even the
terminology, unfortunately; I think it's the "partial" model). 

In this case (I'm using C++ syntax, which I'm more familiar with) 

class BaseModel {
private:
   component c1;
   component c2;
   component c3;
public:
   virtual DoSomething() = 0;
}; 

class DerivedModel1 {
public:
   virtual DoSomething() {
       ground(c1);
       connect(c1, c2);
       connect(c1, c3);
   };
}; 

class DerivedModel2 {
public:
   virtual DoSomething() {
       ground(c1);
       connect(c1, c2);
       connect(c2, c3);
   };
}; 

In this sense, how can you leave "dangling" connections,
according to the factory pattern, and force users to
resolve them later, provided multiple connections are
legal and multiple combinations of connections can result
in a legal model?  A simple example in this case is a
hingeless or a bearingless helicopter rotor hub, which
can have single, dual or even multiple load path
(incidentally, this is one of the reasons we need multibody
to analyze helicopters; articulated rotorcraft can be
analyzed by 15 line matlab scripts ;) 

> The more uses you find for the annotations the worse they become!
[...]
> It has been a very interesting discussion, which gave me much more
> insight :-)

I must say that I agree with you.  I like void pointers for my
own small projects because they make life a lot easier at the
beginning; but they are a pain even for myself when my projects
are not small any more.  Not to count all the other objections
that may come to mind ... 

Ciao, p. 

Dr. Pierangelo Masarati               | voice: +39 02 2399 8309
Dip. Ing. Aerospaziale                | fax:   +39 02 2399 8334
Politecnico di Milano                 | mailto:[email protected]
via La Masa 34, 20156 Milano, Italy   | http://www.aero.polimi.it/~masarati