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
