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

On Mon, 14 Jul 2003, Tiller, Michael (M.M.) wrote:

[...]
> > 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.
Ok, sounds interesting! But I must confess I do not completely
understand what you mean exactly. Isn't type checking etc performed
during parsing? I mean, I expect a parser to fail when the types of
the processed language constructs do not match...
Probably I am overlooking something here :-)


> 
> 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.  
Indeed, that sounds like what I had in mind.

> 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. !
Well, I do not see the relevance of mentioning a "framework" :-)
What I do care about is that one needs runnable code, for simulation
and control purposes, and having the model description correctly
parsed is just the small first step, isn't it? Mind you, I am not
complaining at all, just trying to make sure I understand what you
were saying.

> 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.
The latter. Including the processing into a form that the DAE solver
can work with efficiently.

> 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.
Ok, I follow you until here. But in order to have a consistent and
correct flattened representation, quite some model checking and
connection construction had to take place. And now I begin to see
where we probably misunderstood each other: what you seem to call
"parsing", I called "symbolic processing" :-) So, as far as I am
concerned, we are synchronized again!

> > 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.
Unless you have an idea about what they changed or added to the DASSL
code...

Herman

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