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

On Tue, 15 Jul 2003, Klas Nilsson wrote:

> All, what about having orocos components (and library modules) that
> are to be filled in by the output from code generation from Modelica
> models (e.g. by using Dynola or similar tools). 

That's exactly what I am after! And I want to have a sofware design
that is modular enough to interface with both Modelica and with Bond
Graph models. In other words, I want to have a class hierarchy that
can be used "natively" for UI programs in both communities.

> Then the modelica models would encapsulate symbolic (in the
> model-declarative sense, not to be confused with the so called
> symbolic properties of objects in orocos which I think is only
> meta-information about software objects) 
Exactly! So, again, finding unique (and intuitive) terminology will be
a tough job :-)

[...]
> and symbolic tools like Maple and Dymola could be used for
> manipulation&optimization of symbolic components into subsystems and
> executable orocos components.
Absolute agreed again! I am part of the geoplex project, and there
some people have already Maple code to do index reduction etc. They
have no objections against "open sourcing" their stuff; but it's too
early: we should first get the basic class hierarchy sorted out.

> Still, the Modelica approach should not be used a a foundation for
> orocos
Not a foundation, but an important "input/output format". Or "Save
as..." and "Import..." in GUI terms :-)

> * Flexible or intelligent control systems need a dynamically on-line
> changing structure, including a lot of code that are not very
> suitable to express in Modelica, that does not fit with the
> declarative nature of Modelica (unless you want to embedd Dymola in
> your system..).
No, but:
- Modelica is just an input/output format. 
- internally, the models and their physical meaning and mathematical
  representations are available in efficient compiled code, so
  real-time model switching _is_ possible.
- As I said in a previous mail, I am quite confident that this same
  "real-time structure" is useable for _all_ sorts of hybrid systems,
  such as controllers, and "behaviour based agent systems".

> Also from Scilab (the only free tool I know that includes features
> corresponding to simulink) generation of orocos components would be
> desirable (to comply with the same execution interface as from
> Modelica), but for the case of composing control blocks internally
> expressed in imperative form, thus preserving the model/design
> structure during execution.
I do not understand what you mean with this last sentence...

> Note that in the two cases (Modelica and Scilab) above, composition
> cannot result in components damaging data (or code) for other
> components, but if the user writes application code in e.g. C/C++
> anything can happen. 
Not true if you use the Factory pattern! (If correctly coded) this can
only produce consisten models. (THe burden of correctly coding the
Factory is with the framework builders (i.e., the experts, and they
have to do it only once), and not with the users when they model.

I am really beginning these (by now already) classical Software
Patterns enormously, because they avoid making all these stupid
design errors over and over again.

> Hence, scalability is limited.  That is why
> orocos also need a real-time Java (or in any other accepted compiled
> safe programming language without constructs preventing 
> hard real time) programming interface, but that is another story. DS
I do not follow this jump to RT Java... :-) (Java is also using the
Factory pattern internally, as far as I know.)

Herman

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