Triple bonus points to Dante for cutting right to the heart of the matter.
And it gets worse: there are algorithms out there that *change* what is
considered dependent and independent during the solution process.
The (often contemplated) der-style syntax {even if extendeded to 'der(x,t);
Independent(t)'}
basically has the problem of sewing a pile of special cases into the compiler
and *hiding* variables. In a more likely model the user can write either
der(x,t) in 15 places
or
they can simply write
link(xdot,x,t) once and use xdot without all the non-alphabetic characters and
without sewing in a lot of new syntax and without making additional syntax
like der(x,t).fixed = true.
If we *really* like the der(x,t) approach, we should just ditch ascend and
go with an opensource compiler and system that fully supports it instead of
reinventing the wheel. In particular openmodelica has it all, at the 'cost' of
having to put up with nice gui's, etc, that work on mac/linux/windows.
And they finally got their licensing straightened out.
Ben
----- Original Message -----
From: "Dante Stroe" <[email protected]>
To: "John Pye" <[email protected]>, "ben allan" <[email protected]>
Cc: [email protected]
Sent: Tuesday, April 14, 2009 12:36:35 PM GMT -05:00 US/Canada Eastern
Subject: RE: [ASCEND] GSOC: Improved ODE/DAE support
Dear Mr. Pye,
I see, I understand your point of view in terms of user-friendliness and
ease of use and I don't think there is much difference in terms of parsing.
I think that the only drawback would be that, if in the future you decide to
implement PDE functionality, using a similar structure, you might have to
modify the parser again, since this approach assumes having only one
independent variable.
Best wishes,
Dante
-----Original Message-----
From: John Pye [mailto:[email protected]]
Sent: 14 April 2009 01:49
To: [email protected]
Cc: Stroe Dante; [email protected]
Subject: Re: [ASCEND] GSOC: Improved ODE/DAE support
Hi Ben, Dante,
I would add a slightly different perspective here...
[email protected] wrote:
> answer 1) key. Key is used to define the kind of relationship, so all
> 1st derivatives with respect to
> an independent variable would be of the form:
> LINK('deriv1', xdot, x, t);
> LINK('derive1', ydot, y, t);
> meaning xdot is dx/dt in the ode sense; finding the key 'deriv1' is
> how we know the
> link is concerned with ODEs and not some other model-consuming agent.
> Some ode
> solver examines the link tables and ignores any link without key
> 'deriv1'. A better
> word than 'key' might be 'class' or 'link-kind'. A unique key (in the
> database sense) would
> only exist once we combined the identifier of the instance containing
> the link and the
> identifier of the link itself. (links will be 'named' in the same
> sense that ascend
> relations can be named, at least syntactically).
...
> answer 3) ASCEND has a history of being designed around what the user
> sees, instead of creating a functionality and then figuring out how to
> wrap
> it in the parser.
My comment here would be that ultimately we don't really want the *user*
to see this LINK syntax at all. I think that good ODE/DAE syntax will
allow the user to enter statements like
MODEL test;
x, y IS_A distance;
der(x) = -y;
dey(y) = -x;
METHODS
METHOD on_load;
der(x) := 0;
der(y) := 1;
x := 1;
y := 0;
END on_load;
END test;
In other words, "der(x)" would be some kind of virtual variable, defined
just by being referred to. It will obviously have dimensions defined by
its parent type, multipled by (time^-1).
This syntax is intuitive and very concise, and still allows
initialisation of values. It would be implementable using the LINK data
structures, but vastly preferably for the end user.
In terms of implementation, "der(x)" would require the parser to look
through its LINK list to find if any variable was already linked to x as
its derivative. If not, it would create a new variable (make calls
similar to those for "der_x IS_A speed") then link the resulting
variable to x. This would essentially require the "variable" pattern in
the parser to add support for the pattern "der(VARNAME)", where VARNAME
is already defined.
If we pursue the approach of implementing the general-purpose LINK
statement, I would only see that as a half-way step towards the full
task of improved DAE syntax for ASCEND.
Cheers
JP
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Ascend-sim-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ascend-sim-users
