To answer a few questions (I will try to go in order) and add a little more
background:
As mentioned in the wiki page on link semantics, LINK is a way of defining new
and arbitrary
relationships that apply to one or more ascend instance names. Names only exist
in the context
of a model, so a link is only definable (in terms of data structures) as an
attribute of a model instance.
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 2) Based on the opening comment about names and model instances,
all model instances (at construction) will get initialized with an empty link
table.
There is nothing specific about solver_var or any other type in the system for
LINK purposes. It is not in the plan that model instance or variable instance
will be directly queryable for LINKS that reference to it. It will be possible
to
query a model for all the links that reference a specific descendant of that
model.
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. So we would begin with producing some (very simple)
prototype ode model using the proposed link syntax. The current compiler
would of course reject these models. We would then define the syntax
in ascParse.y and include stub methods that we think will be needed to
store the link definitions in the ascend type description data structure.
Once we can have the modified ascend parser digest (and print out correctly
as part of the C typedescio methods) a set of models testing link
syntax, we then move on to the instance-level details of handling links.
The instance level includes:
- defining the link_instance structure(s).
- extending the model_instance data structure as needed for declarative links
and procedural links.
- extending instantiation routines to populate these data structures.
- implementing query routines to look up the results needed (in this case for a
solver).
- creating a simple prototype solver agent (doesn't have to actually solve
numerics-- just has to create correct
variable lists).
An extra bonus goal if all the previous stuff goes really fast would be to
actually take the existing ODE/DAE preprocessing code and make an alternative
version
based on processing the links instead of variable attributes.
Before all that starts, we need to spend a little time discussing/wiki-ing the
details of
the syntax-- what's there now is very preliminary. I expect it will end up
slightly more like
relations we have now in form, except there will be no = involved and LINK will
never be
a valid operator in the relations of ascend.
Ben
----- Original Message -----
From: "Dante Stroe" <[email protected]>
To: [email protected]
Sent: Thursday, April 9, 2009 6:39:06 AM GMT -05:00 US/Canada Eastern
Subject: [ASCEND] GSOC: Improved ODE/DAE support
Dear all,
My name is Dante Stroe, I am a Master student at EPFL, Switzerland, and I have
applied to GSOC for ASCEND’s idea of implementing a better structure and syntax
for handling ODEs and DAEs. I have been looking some more through the
documentation on the web and the code.
I think that using Link syntax is not the only way to describe the differential
variables, and their initial conditions, with respect to their instances. One
other way, for example, would be a referencing system where a reference
attribute would describe a one–way relationship between differential variables
and its derivative. However, the Link syntax described on the wiki is more
general and is more useful ( I think conceptually their more or less the same,
only different in terms of data structures used). To my understanding, the only
instances that should have this type of Link_list are the solver variables, so
a constructor should be initialized whenever it is declared as such (by “IS_A
solver_var”) to create an empty link table.
I didn’t quite understand how you would use the Link syntax from the wiki page
where you described it ( e.g. is the ‘key’ parameter used to identify the
instance it references and is unique, or is it used to describe it? In which
case the uniqueness would be described by the key and the instance). In my view
a way to improve the syntax and to define derivatives using Link semantics,
would be:
Old:
METHOD ode_init;
dx_dt.ode_id := 1;
x.ode_id := 1; (* i.e. these variables are related with ID '1' *)
dx_dt.ode_type := 2; (* i.e. 'this is a derivative variable' *)
x.ode_type := 1; (* ie 'this is a differential variable *) t . ode_type := - 1
; t := 0 {s} ;
END ode_init;
New:
dx_dt = LINK(‘ODE_derivative’, x,t0, x0,…)
(*the key would describe the relationship, the second parameter would be the
instance referenced, and the rest would be the initial conditions and other
requirements *)
(* also, the parser would know from the key that we are describing the ode
type, as well as the relationship between the to instances, and would
recursively update the link tables of other instances related to ‘x’ in this
case with the higher order derivatives*)
PS: - I don’t see any situation where the links shouldn’t be added and removed
recursively.
- Could you give me an example of a declarative Link
So far, I have been looking at the source files for the generic compiler, and
inspecting the dependencies of the objects sent to the solvers once the
differential equations have been initialized.
Also I guess another important aspect is how rules are defined in ascParse, so
that one could similarly add a LINK/UNLINK token.
I see two ways to go around the project plan: first implement the functionality
of the link lists for the modules/methods and test it using regression testing
and then implement the parser that would build on these functions, or the other
way around (first decide on a fix syntax and build the parser). I personally
think that the first way is more safe.
Let me know if I got any of your ideas wrong or whether my approach is
inappropriate.
Best regards,
Dante Stroe
PS: Sorry for answering this late to your email
------------------------------------------------------------------------------
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------------------------------------------------------------------------------
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
