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

Although I'm not really involved in OROCOS directly, I still have a few comments...

> -----Original Message-----
> From: Pierangelo Masarati [mailto:[email protected]]
> Subject: [Orocos] Re: dynamics: comment about MBdyn...
> 
> Herman Bruyninckx wrote:
> > Some weeks ago, there were some posts about the free 
> software dynamics
> > package MBDyn <http://www.aero.polimi.it/~mbdyn/index.html>, and I
> > took a closer look at it... Since there is apparently no mailinglist
> > for MBDyn,
> 
> apparently, setting up a mailing list at our University requires
> enough traffic to justify it, ... a sort of catch 22.  The address
> mailto:[email protected] is read by all the developers, and we
> may decide to set a mailing list up in the near future.

You might consider setting up a list through Yahoo groups (http://groups.yahoo.com).  You wouldn't need to deal with your University in that case.

> > First of all, I am personally quite a bit biased by the Bond Graph
> > approach, both because I have many good friends that work in this
> > area and so I know it better than other domains, and because I really
> > think it is the best fit for an "object-oriented" software 
> > engineering solution to general purpose dynamics software.

As I'm sure everyone on this list knows, I have similar feelings about Modelica.  I just wanted to add two comments here with respect to this statement.  First, François Cellier has written a Bond Graph library in Modelica (although I haven't used it) so perhaps that helps "unify" these views to some extent.  Secondly, the latest version of the Modelica language (approved, but not yet published) includes new language constructs to allow multi-body system models to be built with closed kinematic loops but without the need for cut-joint components.  I'm not that familiar with the details, but Dynasim has already released an implementation that supports these features and I expect they will have a demo available within the next few weeks that includes the support for these features and a beta version of a multibody library that utilizes them.

I just thought I would throw those two things in since we were on the topic of Bond Graphs and robots (and since Dr. Masarati mentioned Modelica in his original message).

> > About discussion of symbolic needs. 
> > - Where exactly do you need symbolic support? I mean, what 
> do you use
> >   it for, and what do you _want_ to use it for in the future?
> >   (I guess for the reduction of sets of DAEs to computationally
> >    deterministic smaller sets?)

> No.  At present, symbolic manipulation is in a very early
> stage, and all the support that's there is in "interpreted"
> drives (see the discussion about drives that occurs later),
> and, recently, in a symbolic constitutive law (that requires
> GiNaC; the rest is built-in) for symbolic differentiation.
> In MBDyn's present state there is no low-level symbolic
> manipulation; modelling occurs by using existing building
> blocks in existing element libraries.  One can "easily" add
> new elements with limited effort by hacking the code, or by
> building dynamic modules that are linked run-time.

Herman mentions index reduction efforts (I assume that is what he means by reduction of sets of DAEs).  Symbolic manipulation gets you several other things.  Basic things such as equation sorting can help you formulate problems in block-lower-triangular (BLT) form which is computationally efficient.  In addition, there are other opportunities such as equation tearing that also help computational performance.  The point is that symbolic information has several uses.

> > - Useful to transform to XML + Schema?
> 
> Wy not? We've been talking for a long time about
> how to improve the input.  At some point, before
> it derived towards a complete reinvetion of the
> wheel (say OO language) we were also considering
> the possibility to interpret (at least partially)
> Modelica.

Well, I'm quite pleased to hear you are considering this.  My opinion (and I've probably voiced it here before) is that I don't think XML is an appropriate medium for a modeling language.  It handles data just fine, but I really don't think it is appropriate as a human readable format or as a programming language.  Rather than rehash the arguments, I'll just include a reference to an article that makes them all nicely: 

http://www-106.ibm.com/developerworks/xml/library/x-sbxml.html?dwzone=xml


> > - "Nodes": generic frameworks such as Bond Graphs and Modelica offer
> >   already well-developed terminology and definitions, so it could be
> >   interesting to follow those. Personally, I am very interested in
> >   discussing this in detail.

Just a minor comment.  Modelica doesn't quite have "nodes" in the usual sense (i.e. named entities that exist separate from the components).  Instead, Modelica has entities called "connectors" that exist on the components and these connectors are then in some sense merged to form a single set of variables that are shared between components.

> I was not aware of bond graphs at the time I started
> working at MBDyn, and I currently have a vague idea
> of what they are.  I'm more biased towards finite
> elements; in this sense we have "state" and "flow"
> fields, but while in bond graphs a "force" is typically
> an "effort", in finite elements it would be in the "flow"
> category.  MBDyn's nodes are "efforts", and MBDyn's
> elements mostly write "flow" equations in terms of
> forces.  I note that in bond graphs causality seems
> to play an important role, while Modelica is based
> on the negation of causality (the same is true for
> MBDyn), so the examples you mention, at least on this
> point, are contradictory ...

As I mentioned earlier, there is a new multi-body library coming out in Modelica very soon (I have beta copies, but I'm not sure the author wants me to circulate them).  I suspect you might find the structure of those libraries very interesting.  It would be great to see an open-source tool that could simulate the models in that library (hint, hint).

> One improvement I was considering is to group structured
> data into structure symbols (e.g. vectors in {}, matrices
> in {{},{},{}} and so).

If you are considering Modelica, you could use "records" in Modelica for this.


> > About PDE modelling and simulation.
> > What we miss (well, nobody really _misses_ it at this moment :-)
> > in the Orocos community are the "inifinite dimensional"
> > dynamical objects, (with the Timoshenko beam as the classical
> > example), which requires PDEs instead of ODEs. So, it would be very
> > useful to brainstorm about how to incude both in the same software
> > structure.
> 
> I'm puzzled by the use that people tend to do of PDE
> acronym  when talking about structural analysis.
> It is clear to me that at some point you need to move
> to finite dimensional models, e.g. discretize, and I
> don't find it too much useful to preserve PDE description
> of the problem until the very last moment because it is
> well accepted that efficient and accurate FEM models do
> not allow PDE formulation and discretization separation,
> unfortunately.  As a consequence I'm much more comfortable
> talking directly about a beam element rather than
> Timoshenko PDE beams.

I should mention that I come from an FEM background as do a few other people involved in the Modelica effort.  There is interest within the group of adding some language constructs to support the posing of PDEs.  It is not clear at this point whether that will mean just finite difference shorthand or full support for things like basis functions, quadrature, etc.

> -- 
> Dr. Pierangelo Masarati

It is not my intention to continually bring Modelica into the mix but since Dr. Masarati mentioned Modelica, I just wanted to add a few comments to his very nice explanation of MBDyn where I thought it was relevant.

Two final points.

First, for Dr. Masarati if you have any questions or issues with Modelica, please let me know.  I'd be more than happy to answer any questions you have and if you find that Modelica doesn't work for your, that is fine by me.  The only thing I ask is that you let me know why you don't think it is appropriate so we can consider that for ongoing development of the language.

Second, one of the big criticisms of Modelica I have seen is that there aren't any open source implementations. Ideally, I'd like to see some academic groups attempt an implementation.  In an effort to support this, I am going to try (no promises) to get our (Ford's) internal Modelica parsing and semantic processing tools (very limited capability at the moment) released for distribution by the Modelica Association as open source.  Hopefully, this might help people like Dr. Masarati who are interested in being able to read Modelica models into their simulation environments.

--
Mike