I completed my Bachelor of Engineering Degree from Netaji Subhas Institute of Technology, University of Delhi in 2011. I helped develop the canvas, a graphical modelling layer for ASCEND. I can reached out at the ascend-user mailing list.
Work for GSOC2011
There seems a possibility of using the NOTES and METHODS together to allow a suitable design solution to parameter handling.
Using NOTES to make distinction between the parameters:
- How to best organize the parameters, required, standard etc
- Enhance the blockproperties window even further to support these changes, although the gtk provided widgets are not very capable enough to do a lot of manual tweaking stuff that will be needed to display such parameters, unless we dig very deep. If possible we should look for an alternative for the 'front end' for displaying the parameters
- There would be some changes in the BlockType class, but that would be easy.
Using default METHODS for scaling and specifying default values for parameters:
METHOD canvas_default; RUN pump1.default_self; RUN condenser1.default_self; END canvas_default;
condenser1.default_self METHODS specify the nature of default actions of the block pump1 and condenser1 parameters respectively. This would the be correct solution for scaling and default values, allowing them to be specified in the block code using existing constructs. The parameters tab in the dialog is to some extent duplication of this, so we need to think about the design for that.
This would require the user select somewhere that he intends to use the default values, and the python code can then just include the call to the default_self of the block inside the canvas_default. Some things that will need to be taken care of:
- How to use both the default methods and the parameter tab in blockproperties?
- What if the user selects the a default method and also fixes a parameter separately?
- What if the default method fails in some different configuration of a canvas model?
- What if something we have set as required can also be solved for?
Using the two above things together will let us into hopefully a good design solution for the parameters.
The current solving process involves exporting the string based model to the solver and then subsequently retrieving solved instance to examine the solution. This even though sounds simple has some serious flaws. It does not allow for re-evaluating the model for a changed parameter, instead the user must resolve the complete canvas. There are some improvements which this feature could use to enhance the solving process.
- Have to deal with the 'instances' objects in python which connect to the real ASCEND instances. To either delete these if the solving process diverges or the user does an Undo.
- Checks for unconnected ports and line connectors.
- Better instance tab to view the solved model and be able to use the instance tab somewhat like we use in the pygtk GUI, ability to resolve (which is currently not there).
- Set up canvas to use the new libavoid bindings. Although could be done before, in case the libavoid bindings are completed.
- For Undo need to look for better method for segregating transactions, only some more tweaking should be necessary.
- We have't applied proper Type checking, its just the string names that are being compared, we could use much earlier Ben's suggestion of having a GUI policy that supports Type checking at the ASCEND level.
- User defined shapes of the 'blocks', this was proposed last year but not completed, we will have to take care though of libavoid limitations here though.
- Other smaller GUI improvements, embedding the Canvas into main GUI, more model libraries etc.
- Have tried out two ways of handling streams. First by annotating for further changes to rankine_fprops.a4c to allow for NOTES that define a stream. Subsequently that fluid model is used by the components to define their streams. Here mixtures are not taken care of. Have partial code that recognizes these fluid MODEL(s), user can select a stream on any block. This in some ways does solve some things for us.
- For for support of liquid mixtures and support for true streams, the support of streams as defined in streams.a4l was needed. This is the second method.There has been some progress on this, but it is needed to rewrite the complete rankine cycle library for canvas to use those streams. Only partial conversion could be done. Several things are unclear, as to how the calculations of the mixture would be handled, how the blocks use the stream.
- A way to set the default values of the streams has been implemented. A block is instantiated separately and its default values are queried back to reveal the values defined in METHOD default_self, which can then be used to set the default values.
- Some work on bugs, changeset 3482 and changeset 3513.
Improvement on Canvas-based modeling:
- Updating the graphical flow sheet modeler.
- Enhancing its usability and functionality.
- Making it more robust.
- Initially before coding address the necessary prerequisites that I will discuss with the Ascend team and have solutions ready to be implemented as follows;
- Detailed layout for the integration into the main application. Update with new Gaphas API. Embed the Canvas code into the pyGTK code. Glade integration, GUI improvements that could be added.
- Solution of the redundant equations in case of equality loops. The current method of 'Methods' be either modified or updated, for easy debugging of the models.
- To specify the 'global' variables for generic models, like streams in a turbine. Every such 'general' sub-model could require parameters of that type, defined in the parameters. A METHOD could be then used to fix such variables across all the sub-models.
- Create a detailed frame-work for importing models onto the pallet from a destined directory dynamically. Replacement for the current initialization method.* Solution to the type-checking problem. This can be done by exporting the partially created models to Ascend library and checking for errors, or maybe use a simpler approach and check for port specifications described in the NOTES.
- Define a set number of generic models that could added so that using Ascend Canvas based modeler becomes a head-start process.
- Once the detailed layout of the work has completed after the above immediate, make a weekly task list. Prepare and setup the required development environment for coding. Employ a suitable code-editor, a debugger and a test framework.
By mid-term review:
- Update code to work smoothly with Gaphas. Integration of Canvas code with the current pyGTK code. User can now either solve a text model or create a new graphical model.
- Do the GUI usability improvements. Undo, Redo, Save image etc.
- Code for a suitable framework for importing new models into the pallet from a specified location.
- Code for the solution of the type checking problem.
- Unit tests of features implemented.
- Start to code for defining the global variables for each of the generic block sub-model.
By final-term review:
- Complete the code for setting the global variables for generic models.
- Code for efficient debugging of models with closed circulation loops.
- Code for the type checking.
- Unit tests of features implemented.
- Add new blocks of models.
- Final testing of the code, final integration to the /trunk code, documentation.
In my view integrating the canvas based modeler with the PyGTK interface should be one of the priorities in order to update ascend with a useful and a powerful canvas based modeler once the smaller issues mentioned above have been resolved. Also set up of new canvas components should be vital for making the Ascend canvas based modeler an indispensable tool.
Proper documentation would be maintained on the Ascend wiki, updates on weekly progress. I plan to contribute to Ascend after the GSOC period. This would include support for all the code written and implemented by me and further improvements to the Canvas based Modelings.