View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000543 | ascend | pygtk gui | public | 2012-04-10 05:04 | 2012-04-17 03:40 |
| Reporter | john | ||||
| Assigned To | |||||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | new | Resolution | open | ||
| Platform | Windows | OS | Windows | OS Version | 7 |
| Product Version | 0.9.7 | ||||
| Target Version | 1.0 | Fixed in Version | |||
| Summary | 0000543: Add support for declaration of Observers from within METHODs | ||||
| Description | Setting 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. | ||||
| Tags | No tags attached. | ||||
|
|
Email from: Ben Allan <ba22.cmu@gmail.com> what happened to simply something like T.observed := true; or: Rather than making a new keyword (stop leaning on parsers for things they shouldn't do), consider 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. Ben |
| 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 |
