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

> -----Original Message-----
> From: Herman Bruyninckx [mailto:[email protected]]
> Subject: RE: [Orocos] Re: dynamics: comment about MBdyn...
> 
> 
> On Tue, 15 Jul 2003, Tiller, Michael (M.M.) wrote:
> 
> [...]
> > So to me, the open question is what would the co-simulation
> > interface be?  There is something called "DSBlock" that was 
> developed at DLR
> > (http://www.modelica.org/DSblock/dsblock4.0a.shtml).  This 
> is a potential
> > candidate.  I think this is what Dymola uses internally.
> 
> This is certainly a candidate, in the sense that it captures the
> required information. But I think defining the "software classes" to
> which these descriptions have to translated in the important thing;
> there must be translators to various forms of these descriptions
> (i.e., XML, Bond Graph, graphical editors, etc.)

> BTW, what do you mean with the "co" in "co-simulation"?

For the most part, much of my work involves "simulation" of a model with a
single solver.  Because the entire problem is "known" to the tool solving
the problem, things like algebraic loops, Jacobians, etc. can be computed.

For some applications, a single tool or solver may not be sufficient.  In
that case, you end up treating the individual subsystems or components and
separate software processes with their own solver.  This is the situation I
refer to as "co-simulation".  In case my bias isn't already clear, I
diligently try to avoid co-simulation of coupled physical systems because it
is (in my experience) not very robust or stable.  In addition, I'm never
comfortable with the accuracy of the results.

> And with "harness" in "a harness for co-simulation"?

By harness, I just mean the appropriate interfaces and API for dealing with
a model in a compiled code form.  Obviously, you want to be able to get a
"rate vector" out of the code for the purposes of integration.  In many
cases, you need to be able to resolve events (by checking for
zero-crossings), and you might even need to "rewind" the simulation in some
cases.  These are some examples of things that must be handled by a
co-simulation interface (I'll use interface from now on rather than
harness).

> > Where most of these systems fall down (in my opinion) is that they
> > try to apply co-simulation too finely.  In other words, they develop one
> > component model in one environment, another component in another
environment
> > and then build a system by co-simulating the two components.  This is
> > problematic (especially in domains like robotics where DAEs are quite
> > common) because dealing with algebraic loops and Jacobians is a real
> > problem.

> Aren't these problems to be solved via the "symbolic processing" we
> discussed about? (I mean: are there any _other_ possibilities to solve
> these difficulties than symbolic processing?)

Yes, but the more fragmenting or decomposition, the less potential for
symbolic processing.  Taking this to the extreme, I could develop a
co-simulation interface and then generate compiled code for resistors,
inductors, etc. and then try and co-simulate each component (with its own
solver).  This is the kind of thing I would avoid!  You lose so much in
doing this.  The integration error in this problem is unbounded, the
stability of the system is probably going to be a big issue.  The less you
compartmentalize...the better (in my opinion).

> > Co-simulation with control code is a completely different story because
the
> > reality is that the controls almost always "co-simulate" with mother
nature
> > anyway (i.e. there are no true algebraic loops *through* the control
> > system).
> 
> Can you elaborate on this a bit more, please?

The point is that control systems typically interact with physical systems a
sampled time or interrupt basis so there is not omnipresent algebraic
relationship to satisfy.  Now if you model control systems as purely
continuous (e.g. Simulink models in the Simulink environment and not as RTW
generated code), then you might still have an issue, but most control
systems usually isolate their inputs from their outputs with states (i.e.
the D matrix in the linearized form is typically 0).

Does that help?

> > > * 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..).
> > 
> > Quite possibly.  Keep in mind that Modelica has both imperative and
> > declarative semantics so it wouldn't be impossible, but I 
> can certainly
> > understand that it may not be convenient to use Modelica in 
> such cases.  I
> > have no problem with that.
> 
> I think the existence of FSM and events in Modelica are enough to cope
> with all these "hybrid" things.

Hybrid in what sense now?!?  As I mentioned, changes in connectivity or
causality are beyond the scope of the Modelica semantics.  You can
definitely model things like finite state machines and petri nets, but the
actions of these models cannot affect the connectivity (although they could
affect causality for some cases).

The bottom line is that in a given Modelica model, you must always have the
same number of equations and unknowns.  You can play games by carrying some
variables along even when you aren't using them, but you have to have a
constant number (at least for the purposes of semantic processing).

> [...]
> > I've talked with some people at Scilab and they also have 
> an interest in
> > Modelica.  Perhaps they would be interested in developing a 
> co-simulation
> > harness as well.
> > 
> Of course there are many people on their mailinglist with this
> interest. We should be able to connect to them one way or another.
> (There does remain the license problem with Scilab: it is _not_ open
> source; an insider told me that it's one single authorative person
> within INRIA that is keeping all their software from being 
> open source...)

I think Modelica is a good model for this.  Establish an independent body to
define the interfaces and perhaps a reference implementation and then Scilab
can build on that (rather than being the developers of it).

> Herman

--
Mike