User:Grivan

Grivan Thapar

GSoC 2010 Proposal: Improvement on Canvas-based modelling for Ascend
See Canvas-based modeller for ASCEND for more information.

Mentor: John Pye

Subversion Branch grivan:

I am pursuing my Bachelor of Engineering Degree from Netaji Subhas Institute of Technology, University of Delhi, and will graduate the four-year course in 2011.

Current Work

Canvas

Parameter Handling

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;

Here the pump1.default_self and 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.

GSoC 2010 Participation

Goals

Improvement on Canvas-based modeling:

• Updating the graphical flow sheet modeler.
• Enhancing its usability and functionality.
• Making it more robust.

Tasks

• 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.