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
