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

> From: Herman Bruyninckx [mailto:[email protected]]
> Subject: RE: [Orocos] Re: dynamics: comment about MBdyn...
> 
> 
> On Mon, 14 Jul 2003, Tiller, Michael (M.M.) wrote:
> 
> [...]
> > 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.
> 
> That doesn't help the open source world a lot, does it? :-)

The specification of the language, all the standard libraries and the multi-body library I mentioned are all open source (not to mention all the conference proceedings and meeting minutes can be found on the web site).  If that doesn't "help", then I'm sorry.

> > 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.
> 
> Well, parsing is not really the big software hurdle... It's defining
> the objects that correspond to the models, as well as the tools to
> build systems and prepare them for simulation. (And the numeric
> solvers too, of course.)

I want to just clarify my comments.  I said "parsing *and* semantic processing tools".  In this context, semantic processing means elaboration of the underlying Modelica code (i.e. things like type checking, name lookup, declaration processing, etc).  I would argue this *is* a big step.  My tools are not complete, but they go well beyond parsing.

Perhaps I'm mistaken, but there seems to be quite a distinct difference in perspectives about what is required here.  You meantion "objects that correspond to the models" and "build systems", etc.  The "objects that correspond to the models" are represented in the Modelica code itself.  You seem to be (correct me if I'm wrong) thinking more along the lines of building a C++ framework in which you would implement class definitions for nodes, elements, etc and then inherit from these framework components to build specific models.  I used to be quite deeply in the "framework" camp when I was in grad school (In fact, I built a PDE framework around these same ideas).  Eventually, I abandoned that way of thinking in favor of Modelica.  I'm sure we could argue endlessly about frameworks vs. special purpose languages but let's not.  I'm perfectly happy to accept that for reasons related to your 
 specific goals (e.g. writing embeded control code), you prefer to work with a framework. !
    I'm only mentioning this to help clarify the capabilities of the tools I described.

I'm not sure what you mean by "build systems".  I can think of two interpretations.  First, you could mean the software build (e.g. autoconf, make, etc).  Or, you could mean the formulation of the system of equations.
After semantic processing of a Modelica model is complete, the result is a system of hybrid DAEs.  There are no objects at this point, only variables and equations.  That is it.  The object hierarchy has "washed away" and only a "flattened" representation of the problem remains.

There is still the issue of hooking up to a numerical solvers.  If you hook up to DAE solvers, you might be pretty close to being able to run once you have done the semantic processing.  If you want to do things like state selection, index reduction, tearing, etc., then this set of DAEs is not the end of the road.  Instead, you must perform symbolic transformations on the DAEs before you can solve them.  In either case, since you have the equations in symbolic form, you can do things like generate analytical Jacobians or compute certain sensitivities.

> BTW, do you have any idea about the quality of the DAE solvers in
> projects like OCtave and Scilab? (They use some form of DASSL, if I am
> not mistaken...)

I have not used the DAE solvers in Octave and Scilab.  The DAE solvers I am familiar with are also based on DASSL but since they exist in closed source tools, I'm sure they are of no interest to you.

> Herman

--
Mike