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

> -----Original Message-----
> From: Herman Bruyninckx [mailto:[email protected]]
> Subject: RE: [Orocos] Re: dynamics: comment about MBdyn...
> 
> 
> On Wed, 16 Jul 2003, Tiller, Michael (M.M.) wrote:

> > I still feel like you are still not quite understanding the
> > implications here.  Modelica isn't just a file format.  As I keep
> > saying, there are semantic implications when I write these things.
> 
> Indeed! And this brings me to another (potential) problem with
> Modelica: if you need _code_ in addition to the _data_ from the file,
> in order to determine the semantics of the file, than this code should
> be standardized too. Otherwise there is no standard!
> 
> That is only possible with an open source code base, not with various
> vendors implementing their own semantics... ("Code is law" is well
> known in the open source community.) Take the MS Word or HTML
> examples: it's basically the software that determines the result,
> which gives an unfair advantage over competitors. So, this leads me to
> a logical conclusion _if_ one doesn't want to go with an open source
> reference implementation: all semantics should be in the file. The PDF
> example I gave before proves that this is possible: PDF files render
> everywhere the same, on all platforms, with all viewers. (Unless you
> miss the fonts, of course.)

So if I understand your assertion, any standard that is not *DEFINED* by an
open source implementation in code (as opposed to a document describing the
standard) is not truly a standard?!?

> > In short, It does perform checks!
> Yes, but where has the Modelica foundation defined what these checks
> should be

I would have thought it was obvious...in the Modelica specification!

> and what happens if they fail?

The specification only concerns itself with whether something is
semantically legal or not.  It doesn't define what the tool should do in the
case (except that the resulting hybrid DAE is undefined).

> > There are subtype requirements that are implied in the semantics of
> > the language.  The original factory defines what the interface is
> > for the RevoluteJoint, InertiaBase and Link classes will be.  It
> > happens that in my example I didn't include anything in the
> > interfaces, but if I did, all factories would be required to provide
> > implementations that were subtypes that supported the original
> > interfaces.

> Ok, but this is only part of the picture: strong type checking is not
> enough. We come back to where we started a week ago: the difference
> between "parsing" and "symbolic processing". I can now express my
> objections a bit clearer: the behaviour of the symbolic processing
> should be standardized too.

Yes and no.  There are two kinds of "symbolic processing" here and I want to
be clear which type we are talking about.  The semantics of the Modelica
specification describe how the Modelica description of a model can be
transformed, unambiguously, into a system of hybrid differential algebraic
equations.  Lets not call this "symbolic processing", lets call it what it
is..."semantic processing".  This IS standardized.

There is another process that takes place after the system of hybrid DAEs
has been specified that does things like equation sorting, index reduction,
tearing, etc.  This is quite deliberately NOT standardized because the
Modelica semantics only concern themselves with defining the problem, not
imposing additional constraints on how the problem is solved.  The idea here
is to avoid constraining future implementations to only those solution
methods that we can think of or know about today.

> [...]
> > That can also be dealt with in the language by making an assertion
> > in the model requiring that a port be connected.  That is support!
> >  ed by the language.
> Please, I am talking about _guarantees_, not about _support_. This is
> a world of difference!

If you put an assertion in your model and you include in the assertion
expression a condition that a given connector on the model must be connected
to something and at compile time that assertion is not satisfied, then the
specification says "the current evaluation is aborted".  Assertions are not
always considered fatal because they may be triggered by candidate solutions
which are not ultimately chosen as actual solutions.  Typically, if the
evaluation continues to fail, the simulation will terminate.  If you wish to
guarantee that the simulation will terminate you can explicitly call the
"terminate()" function yourself (if you don't have enough confidence in your
tool to do it for you).  This is all in the specification (Sections 3.4.2.4
and 3.4.2.5 mainly).

> [...]
> > I didn't make this point explicitly, but annotations are used for
> > things that DO NOT affect the behavior of the model.  As such, it
> > should always be safe to ignore them and still be able to simulate a
> > model.
> 
> Nothing  prevents one from using them to affect behaviour...

This is completely incorrect.  The semantics defined in the specification do
not describe any transformation where information in an annotation enters
into the process that generates the hybrid system of DAEs.

> (For example (_your_ example) using an annotation to define
> dependencies between variables in the model.)

I showed that you could use annotations to relate a type definition in
Modelica to a piece of meta data.  Nowhere, in what I described, was there
any suggestion that this should affect any behavioral aspect of the model.
The type definition constrained the meta-data, not the other way around.  As
such, there is no way this could affect the behavioral data.  What I
proposed was completely outside the scope of the semantic processing (as is
anything annotation related).  The behvavioral data is *already constrained*
by the type definitions (which gives you the structure you want) and this
doesn't involve annotation data either.

In summary, annotations *DO NOT* affect the semantic processing...ever.

> And where is my guarantee that Dymola will not start to use them for that
purpose...?

With any standard, it is entirely possible that a vendor will chose to not
conform to the specification.  Most of the time, such non-conformance is
simply an undisputed bug and gets resolved.  You run the same risk of
non-conformance with an open-source implementation.  Besides, I never said
you should use or were constrained to using Dymola.

> Where is my guarantee that I can change software vendors without
> loosing my investment in models?

That is what the standard attempts to define.  Does the Modelica Association
have a para-military force that will swoop in and compel a vendor at gun
point to conform to the specification or else?  No.  Do you have any real
guarantee that Japan won't invade Europe and force you all to work a slave
labor processing sugar beets?  No.  If you had compliant Modelica models and
your vendor suddenly decided to force you to mix annotation meta-data with
behavioral data could you switch to another tool to avoid this
perversion...yes.

> The common practice in the feature-bloated IT industry has proven time
> and again that this is what is going to happen, sooner or later...
> Unless the standard is complete and guaranteed.

I will not tell you that the Modelica specification is perfect.  In fact,
the Modelica specification is a living document to address deficiencies as
they are identified.  I would be very interested in knowing about *specific*
cases where the specification is incomplete or ambiguous.

> Herman

--
Mike