View Issue Details

IDProjectCategoryView StatusLast Update
0000543ascendpygtk guipublic2012-04-17 03:40
Assigned To 
Status newResolutionopen 
PlatformWindowsOSWindowsOS Version7
Product Version0.9.7 
Target Version1.0Fixed in Version 
Summary0000543: Add support for declaration of Observers from within METHODs
DescriptionSetting up observers for often-used models is a bit tedious. It would be helpful if observers and/or studies (STUDY) would be possible from within the METHODS section of a model.

Possibly this would have to be implemented using something similar to the 'slvreq' functionality, which currently supports the 'SOLVER', 'SOLVE' and 'OPTION' commands.

METHOD on_load
  FIX T;
  (* declare the observer *)
  OBSERVE T, p, h, s;
  (* perform a study *)
  STUDY T := 273.15 {K} .. 873.15 {K} WITH 100 LINEAR RUN on_load;
END on_load;

-- or --

METHOD on_load
  FIX T;
  (* declare the observer within the study statement... *)
  STUDY T, p, h, s FOR T IN 273.15{K}..873.15{K} STEPS 100 LINEAR RUN on_load;
END on_load;

Whether this is the best approach, or whether something more Pythonised is a good move is not yet clear.

Design discussion needed before we could proceed with this one.
TagsNo tags attached.




2012-04-17 03:40

manager   ~0000866

Email from: Ben Allan <>

what happened to simply something like
T.observed := true;
Rather than making a new keyword (stop leaning on parsers for things
they shouldn't do),
call observe(T,p,h,s); //with an external function observe()
This is also what should have been done with FIX.

Re python vs methods, you can do it either way, but doing the highest
level in python and
designing a good C api of reusable pieces for building dae solvers,
nonlinear solvers, and
optimizers is a much better way to go.

We really need to escape the notion that something written in the
ascend language should be
entirely self contained. ASCEND is (probably) not turing complete and
cooking up another
full language is a really bad idea for a small-market community.

For bonus points, define the api for calling (instead of c) arbitrary
scripting languages:

METHOD callpy;

CALL x(T,P,y) IN python;

END callpy;

Arguably, 'in python' is repetitive: what's needed is the api for
importing/registering a python method
just as there is for C.


Issue History

Date Modified Username Field Change
2012-04-10 05:04 john New Issue
2012-04-10 05:06 john Description Updated View Revisions
2012-04-17 03:40 ben Note Added: 0000866