<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://ascend4.org/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Grivan</id>
	<title>ASCEND - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://ascend4.org/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Grivan"/>
	<link rel="alternate" type="text/html" href="https://ascend4.org/Special:Contributions/Grivan"/>
	<updated>2026-04-28T21:46:01Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.43.6</generator>
	<entry>
		<id>https://ascend4.org/index.php?title=User:Grivan&amp;diff=4546</id>
		<title>User:Grivan</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=User:Grivan&amp;diff=4546"/>
		<updated>2013-12-12T16:42:32Z</updated>

		<summary type="html">&lt;p&gt;Grivan: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;&#039;Grivan Thapar&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Subversion Branch {{srcbranchdir|grivan|}} and {{srcbranchdir|grivan2|}} (merged into trunk code as of May 2012).&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Work for [[GSOC2011]]=&lt;br /&gt;
===Canvas===&lt;br /&gt;
===Goals===&lt;br /&gt;
====Parameter Handling====&lt;br /&gt;
There seems a possibility of using the NOTES and METHODS together to allow a suitable design solution to parameter handling.&lt;br /&gt;
&lt;br /&gt;
Using NOTES to make distinction between the parameters:&lt;br /&gt;
*How to best organize the parameters, required, standard etc&lt;br /&gt;
*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 &#039;front end&#039; for displaying the parameters&lt;br /&gt;
*There would be some changes in the BlockType class, but that would be easy.&lt;br /&gt;
&lt;br /&gt;
Using default METHODS for scaling and specifying default values for parameters:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 METHOD canvas_default;&lt;br /&gt;
  RUN pump1.default_self;&lt;br /&gt;
  RUN condenser1.default_self;&lt;br /&gt;
 END canvas_default;&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Here the &amp;lt;code&amp;gt;pump1.default_self&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;condenser1.default_self&amp;lt;/code&amp;gt; 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.&lt;br /&gt;
&lt;br /&gt;
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:&lt;br /&gt;
&lt;br /&gt;
*How to use both the default methods and the parameter tab in blockproperties?&lt;br /&gt;
*What if the user selects the a default method and also fixes a parameter separately?&lt;br /&gt;
*What if the default method fails in some different configuration of a canvas model?&lt;br /&gt;
*What if something we have set as required can also be solved for?&lt;br /&gt;
&lt;br /&gt;
Using the two above things together will let us into hopefully a good design solution for the parameters.&lt;br /&gt;
&lt;br /&gt;
====Solving Process====&lt;br /&gt;
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.&lt;br /&gt;
*Have to deal with the &#039;instances&#039; 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.&lt;br /&gt;
*Checks for unconnected ports and line connectors.&lt;br /&gt;
*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).&lt;br /&gt;
&lt;br /&gt;
====Other Tasks====&lt;br /&gt;
#Set up canvas to use the new libavoid bindings. Although could be done before, in case the libavoid bindings are completed.&lt;br /&gt;
#For Undo need to look for better method for segregating transactions, only some more tweaking should be necessary.&lt;br /&gt;
#We have&#039;t applied proper Type checking, its just the string names that are being compared, we could use much earlier Ben&#039;s suggestion of having a GUI policy that supports Type checking at the ASCEND level.&lt;br /&gt;
#User defined shapes of the &#039;blocks&#039;, this was proposed last year but not completed, we will have to take care though of libavoid limitations here though.&lt;br /&gt;
#Other smaller GUI improvements, embedding the Canvas into main GUI, more model libraries etc.&lt;br /&gt;
===Progress===&lt;br /&gt;
*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.&lt;br /&gt;
*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.&lt;br /&gt;
*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.&lt;br /&gt;
*Some work on bugs, {{changeset|3482}} and {{changeset|3513}}.&lt;br /&gt;
&lt;br /&gt;
=Previous work=&lt;br /&gt;
&lt;br /&gt;
==[[GSOC2010]] Participation==&lt;br /&gt;
GSoC 2010 Proposal: [http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/ascend/t127230757715 Improvement on Canvas-based modelling for ASCEND] &amp;lt;br&amp;gt; See [[Canvas-based modeller for ASCEND]] for more information.&lt;br /&gt;
&amp;lt;br&amp;gt;Mentor: [[John Pye]]&lt;br /&gt;
&lt;br /&gt;
=== Goals ===&lt;br /&gt;
&lt;br /&gt;
Improvement on Canvas-based modeling:&lt;br /&gt;
* Updating the graphical flow sheet modeler.&lt;br /&gt;
* Enhancing its usability and functionality.&lt;br /&gt;
* Making it more robust.&lt;br /&gt;
&lt;br /&gt;
=== Tasks ===&lt;br /&gt;
&lt;br /&gt;
* Initially before coding address the necessary prerequisites that I will discuss with the Ascend team and have solutions ready to be implemented as follows;&lt;br /&gt;
* 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.&lt;br /&gt;
* Solution of the redundant equations in case of equality loops. The current method of &#039;Methods&#039; be either modified or updated, for easy debugging of the models.&lt;br /&gt;
* To specify the &#039;global&#039; variables for generic models, like streams in a turbine. Every such &#039;general&#039; 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.&lt;br /&gt;
* 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.&lt;br /&gt;
* Define a set number of generic models that could added so that using Ascend Canvas based modeler becomes a head-start process.&lt;br /&gt;
* 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.&lt;br /&gt;
&lt;br /&gt;
By mid-term review:&lt;br /&gt;
* 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.&lt;br /&gt;
* Do the GUI usability improvements. Undo, Redo, Save image etc.&lt;br /&gt;
* Code for a suitable framework for importing new models into the pallet from a specified location.&lt;br /&gt;
* Code for the solution of the type checking problem.&lt;br /&gt;
* Unit tests of features implemented.&lt;br /&gt;
* Start to code for defining the global variables for each of the generic block sub-model.&lt;br /&gt;
&lt;br /&gt;
By final-term review:&lt;br /&gt;
* Complete the code for setting the global variables for generic models.&lt;br /&gt;
* Code for efficient debugging of models with closed circulation loops.&lt;br /&gt;
* Code for the type checking.&lt;br /&gt;
* Unit tests of features implemented.&lt;br /&gt;
* Add new blocks of models.&lt;br /&gt;
* Final testing of the code, final integration to the /trunk code, documentation.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
[[Category:GSOC2010]]&lt;br /&gt;
[[Category:GSOC2011]]&lt;br /&gt;
[[Category:ASCEND Contributors]]&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=3054</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=3054"/>
		<updated>2011-08-24T06:22:47Z</updated>

		<summary type="html">&lt;p&gt;Grivan: /* GUI Usability Improvements */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 and current development carried out by [[Grivan Thapar]]. The goals and tasks for the GSoC period are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. The concerns are right now at setting up better mechanisms for parameter handling and design enhancements like handling of stream objects, globals etc.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
*Global Model equations: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
&lt;br /&gt;
We want to solve models that have feedback loops,&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}} (NOTE: see also {{src|models/johnpye/fprops/rankine_fprops.a4c}} for newer version using [[FPROPS]] instead of [[freesteam]] -- JP). We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece.&lt;br /&gt;
*Elimination of redundant equations in closed loop flows. (Only if we do not use ATS)&lt;br /&gt;
*Specifications and provisioning of complex flow streams.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD. See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*Specifications and provisioning of complex flow streams.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious. For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling with backlash and PID control===&lt;br /&gt;
*Some time after we can look at solving a dynamic model!&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The new Gapahs 0.7.2 release till now seems to work fine.&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head 0.7.1. &lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
===Line Routing===&lt;br /&gt;
Look further for details.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
===Line routing===&lt;br /&gt;
Gaphas now supports line routing, the canvas code would require some changes to work with that. Check the avoid branch of gaphas. It uses [http://adaptagrams.sourceforge.net/libavoid/index.html libavoid] for this.&lt;br /&gt;
&lt;br /&gt;
===Save and restore===&lt;br /&gt;
Pickle is very a flimsy way of persisting a half baked model. Every time a new feature is added, a lot of care has to be taken not to destroy it, infact then it does not even support model saved earlier.&lt;br /&gt;
&lt;br /&gt;
==Improvements on the Solving Process==&lt;br /&gt;
Since we have no Type informations the solving is done primarily by first generating a string representation of the complete MODEL and then exported to the solver. This can lead to problems while trying to solve complex models requiring a large time to solve, because each time a variable is changed the complete model has to solved again. In case of PyGTK GUI we have a more powerful interaction with the solver and thus can change parameters without discarding the already solved model. The basic problem here lies in the fact that we don&#039;t instantiate the model first and then solve it.&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified.&lt;br /&gt;
*GUI implementation: This would provide a suitable GUI to select the stream. An annotated set defined in the &#039;stream&#039; block is being used to specify the stream components. A user must set through GUI the list of components that are needed to be a part of the stream. (eg: [&#039;N2&#039;,&#039;H2&#039;,&#039;NH3&#039;]).&lt;br /&gt;
*Application level implementation: At the application there are several ways the stream can be passed around. Conventionally the streams have been treated as first class objects, passing them around through blocks that accept parameters. But this approach has its own issues. Read further to know why.&lt;br /&gt;
The conventional way,&lt;br /&gt;
&amp;lt;source lang=&amp;quot;a4c&amp;quot;&amp;gt;&lt;br /&gt;
MODEL mycanvas;&lt;br /&gt;
A, B, C IS_A stream([&#039;N2&#039;,&#039;H2&#039;,&#039;NH3&#039;])&lt;br /&gt;
BO IS_A boiler(A,B);&lt;br /&gt;
CO IS_A condenser(C,A);&lt;br /&gt;
END mycanvas;&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
A way John suggests,&lt;br /&gt;
&amp;lt;source lang=&amp;quot;a4c&amp;quot;&amp;gt;&lt;br /&gt;
MODEL mycanvas;&lt;br /&gt;
A, B, C IS_A stream([&#039;N2&#039;,&#039;H2&#039;,&#039;NH3&#039;])&lt;br /&gt;
BO IS_A boiler;&lt;br /&gt;
CO IS_A condenser;&lt;br /&gt;
A, BO.inlet, CO.outlet ARE_THE_SAME;&lt;br /&gt;
END mycanvas;&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
The way it is now,&lt;br /&gt;
&amp;lt;source lang=&amp;quot;a4c&amp;quot;&amp;gt;&lt;br /&gt;
MODEL steram;&lt;br /&gt;
components &amp;quot;param: set of stream components&amp;quot; IS_A set OF symbol_constant;&lt;br /&gt;
END stream;&lt;br /&gt;
MODEL mycanvas;&lt;br /&gt;
A, B, C IS_A stream;&lt;br /&gt;
BO IS_A boiler;&lt;br /&gt;
CO IS_A condenser;&lt;br /&gt;
A, BO.inlet, CO.outlet ARE_THE_SAME;&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
The [[#Simple Rankine Cycle]] could be solved simply by connecting steam_port connectors. The {{src|models/johnpye/rankine.a4c}} uses Steam as the only modelling stream. This model needs to be evolved to use generic port types so that a better and more deep understanding is achieved in the problem of specifying flow streams.&lt;br /&gt;
The ASCEND library provides for generic &#039;stream&#039; types those of which could also be used for representing the stream at the canvas level. But there are several things that need to taken care of before something like that could be done. Some notes:&lt;br /&gt;
*The &#039;stream&#039; types are parametric, although we can support parametric stream (maybe, not yet proven) John feels that doing so we would not be able to use ATS inside our block types, that gives rise to the problem of redundant equations (which mostly goes away once if we use ATS). On the other hand many of commercial modelers use special schemes to remove redundant equations, we could also do that (that is just a speculation, we have no proof how we could do that).&lt;br /&gt;
*Using parametric blocks does give us a upper hand on handling parameters, (as John says) the ascend API reveals a lot more information about the parameters we pass. This would be better than our current nots based approach.&lt;br /&gt;
*Specifying streams requires &#039;sets&#039; to be defined, we might just require to use ARRAY types which can be defined on &#039;sets&#039;, but currently we have no way of identifying array types in our block models, not even through annotations. Some sort of &#039;hack&#039; can work though, but I am just saying.&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now.&lt;br /&gt;
&lt;br /&gt;
*To have highlighting of connectible ports while connecting two ports we need to:&lt;br /&gt;
*#Find all suitable (IN/OUT/BOTH) ports available for connection.&lt;br /&gt;
*#Create a set their Types.&lt;br /&gt;
*#Check connect-ability for each of those types.&lt;br /&gt;
*#Highlight only the connectible ones.&lt;br /&gt;
&lt;br /&gt;
*To give a set of units that can be selected from a drop down menu in block properties:&lt;br /&gt;
*#Scan for the Type of the parameter.&lt;br /&gt;
*#Get the dimensions of the type.&lt;br /&gt;
*#Scan for the units available. &lt;br /&gt;
&lt;br /&gt;
*Implementation&lt;br /&gt;
**Some testing has been done of the functions, see &amp;lt;code&amp;gt;test_type_info()&amp;lt;/code&amp;gt; function inside /compiler/test/test_basics.c&lt;br /&gt;
**The test can be run on any file, using &amp;lt;code&amp;gt;scons test &amp;amp;&amp;amp; test/test compiler_basics.type_info&amp;lt;/code&amp;gt;&lt;br /&gt;
**From the observations, it is clear that the function &amp;lt;code&amp;gt;GetChildList()&amp;lt;/code&amp;gt; works as it should in case of all user generated foreseeable canvas models.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Weekly Reports GSOC 2011==&lt;br /&gt;
&lt;br /&gt;
The weekly reports will be filed here.&lt;br /&gt;
&lt;br /&gt;
====Week 0====&lt;br /&gt;
23th-May-11 to 29th-May-11&lt;br /&gt;
*Necessary changes for libavoid bindings.&lt;br /&gt;
**Still needs some work on the connection mechanism.&lt;br /&gt;
&lt;br /&gt;
====Week 1====&lt;br /&gt;
30th-May-11 to 5th-June-11&lt;br /&gt;
&lt;br /&gt;
====Week 2====&lt;br /&gt;
6th-June-11 to 12th-June-11&lt;br /&gt;
*Some progress towards having methods to set the default values. {{changeset|3474}}&lt;br /&gt;
*Some unusual behavior while updating to use of SWIG 2, some quick fixes. {{changeset|3482}}&lt;br /&gt;
*Some work towards getting stream into the canvas.&lt;br /&gt;
&lt;br /&gt;
====Week 3====&lt;br /&gt;
13th-June-11 to 19th-June-11&lt;br /&gt;
&lt;br /&gt;
Goals:&lt;br /&gt;
*Set up some mechanism of setting of default values.&lt;br /&gt;
*Get implementation ideas on setting up of globals and streams on the canvas. Possibly begin some work on them.&lt;br /&gt;
&lt;br /&gt;
====Week 4====&lt;br /&gt;
20th-June-11 to 26th-June-11&lt;br /&gt;
*Stream MODEL&#039;s recognized by canvas as globals.&lt;br /&gt;
*User can set streams to blocks.&lt;br /&gt;
*From some implementation there for the streams, through discussions it was found that for a very appropriate solution to the issue of streams, streams with variable components has to be taken into account.&lt;br /&gt;
*Spent the weekend on reading the complete models developed by Art on the Hydrogen cycles, which has a set based implementation of streams.&lt;br /&gt;
&lt;br /&gt;
====Week 5====&lt;br /&gt;
27th-June-11 to 3th-July-11&lt;br /&gt;
&lt;br /&gt;
Still struggling with the stream implementation, will do the complete update in a few days time.&lt;br /&gt;
*Writing a new version of Rankine cycle blocks for canvas using the &#039;stream&#039; component defined in the models/stream_holdup.a4l&lt;br /&gt;
*Some success, but still not being able to solve the generated model.&lt;br /&gt;
*Basically in canvas we will have a global &#039;stream&#039; whose properties can be edited using a GUI tool, that particular stream will hold the secrets to the rankine cycle being modeled, each block will use that stream as input and output. Equations inside the block will govern the relation between the output and the input.&lt;br /&gt;
&lt;br /&gt;
====Week 6====&lt;br /&gt;
4th-July-11 to 10th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 7====&lt;br /&gt;
11th-July-11 to 17th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 8====&lt;br /&gt;
18th-July-11 to 24th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 9====&lt;br /&gt;
25th-July-11 to 31st-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 10====&lt;br /&gt;
1st-August-11 to 7th-August-11&lt;br /&gt;
&lt;br /&gt;
====Week 11====&lt;br /&gt;
8th-August-11 to 15th-August-11&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=3053</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=3053"/>
		<updated>2011-08-24T06:19:47Z</updated>

		<summary type="html">&lt;p&gt;Grivan: /* Update for Gaphas HEAD */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 and current development carried out by [[Grivan Thapar]]. The goals and tasks for the GSoC period are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. The concerns are right now at setting up better mechanisms for parameter handling and design enhancements like handling of stream objects, globals etc.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
*Global Model equations: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
&lt;br /&gt;
We want to solve models that have feedback loops,&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}} (NOTE: see also {{src|models/johnpye/fprops/rankine_fprops.a4c}} for newer version using [[FPROPS]] instead of [[freesteam]] -- JP). We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece.&lt;br /&gt;
*Elimination of redundant equations in closed loop flows. (Only if we do not use ATS)&lt;br /&gt;
*Specifications and provisioning of complex flow streams.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD. See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*Specifications and provisioning of complex flow streams.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious. For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling with backlash and PID control===&lt;br /&gt;
*Some time after we can look at solving a dynamic model!&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The new Gapahs 0.7.2 release till now seems to work fine.&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head 0.7.1. &lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
===Line Routing===&lt;br /&gt;
Look further for details.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
===Line routing===&lt;br /&gt;
Gaphas now supports line routing, the canvas code would require some changes to work with that. Check the avoid branch of gaphas. It uses [http://adaptagrams.sourceforge.net/libavoid/index.html libavoid] for this.&lt;br /&gt;
&lt;br /&gt;
==Improvements on the Solving Process==&lt;br /&gt;
Since we have no Type informations the solving is done primarily by first generating a string representation of the complete MODEL and then exported to the solver. This can lead to problems while trying to solve complex models requiring a large time to solve, because each time a variable is changed the complete model has to solved again. In case of PyGTK GUI we have a more powerful interaction with the solver and thus can change parameters without discarding the already solved model. The basic problem here lies in the fact that we don&#039;t instantiate the model first and then solve it.&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified.&lt;br /&gt;
*GUI implementation: This would provide a suitable GUI to select the stream. An annotated set defined in the &#039;stream&#039; block is being used to specify the stream components. A user must set through GUI the list of components that are needed to be a part of the stream. (eg: [&#039;N2&#039;,&#039;H2&#039;,&#039;NH3&#039;]).&lt;br /&gt;
*Application level implementation: At the application there are several ways the stream can be passed around. Conventionally the streams have been treated as first class objects, passing them around through blocks that accept parameters. But this approach has its own issues. Read further to know why.&lt;br /&gt;
The conventional way,&lt;br /&gt;
&amp;lt;source lang=&amp;quot;a4c&amp;quot;&amp;gt;&lt;br /&gt;
MODEL mycanvas;&lt;br /&gt;
A, B, C IS_A stream([&#039;N2&#039;,&#039;H2&#039;,&#039;NH3&#039;])&lt;br /&gt;
BO IS_A boiler(A,B);&lt;br /&gt;
CO IS_A condenser(C,A);&lt;br /&gt;
END mycanvas;&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
A way John suggests,&lt;br /&gt;
&amp;lt;source lang=&amp;quot;a4c&amp;quot;&amp;gt;&lt;br /&gt;
MODEL mycanvas;&lt;br /&gt;
A, B, C IS_A stream([&#039;N2&#039;,&#039;H2&#039;,&#039;NH3&#039;])&lt;br /&gt;
BO IS_A boiler;&lt;br /&gt;
CO IS_A condenser;&lt;br /&gt;
A, BO.inlet, CO.outlet ARE_THE_SAME;&lt;br /&gt;
END mycanvas;&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
The way it is now,&lt;br /&gt;
&amp;lt;source lang=&amp;quot;a4c&amp;quot;&amp;gt;&lt;br /&gt;
MODEL steram;&lt;br /&gt;
components &amp;quot;param: set of stream components&amp;quot; IS_A set OF symbol_constant;&lt;br /&gt;
END stream;&lt;br /&gt;
MODEL mycanvas;&lt;br /&gt;
A, B, C IS_A stream;&lt;br /&gt;
BO IS_A boiler;&lt;br /&gt;
CO IS_A condenser;&lt;br /&gt;
A, BO.inlet, CO.outlet ARE_THE_SAME;&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
The [[#Simple Rankine Cycle]] could be solved simply by connecting steam_port connectors. The {{src|models/johnpye/rankine.a4c}} uses Steam as the only modelling stream. This model needs to be evolved to use generic port types so that a better and more deep understanding is achieved in the problem of specifying flow streams.&lt;br /&gt;
The ASCEND library provides for generic &#039;stream&#039; types those of which could also be used for representing the stream at the canvas level. But there are several things that need to taken care of before something like that could be done. Some notes:&lt;br /&gt;
*The &#039;stream&#039; types are parametric, although we can support parametric stream (maybe, not yet proven) John feels that doing so we would not be able to use ATS inside our block types, that gives rise to the problem of redundant equations (which mostly goes away once if we use ATS). On the other hand many of commercial modelers use special schemes to remove redundant equations, we could also do that (that is just a speculation, we have no proof how we could do that).&lt;br /&gt;
*Using parametric blocks does give us a upper hand on handling parameters, (as John says) the ascend API reveals a lot more information about the parameters we pass. This would be better than our current nots based approach.&lt;br /&gt;
*Specifying streams requires &#039;sets&#039; to be defined, we might just require to use ARRAY types which can be defined on &#039;sets&#039;, but currently we have no way of identifying array types in our block models, not even through annotations. Some sort of &#039;hack&#039; can work though, but I am just saying.&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now.&lt;br /&gt;
&lt;br /&gt;
*To have highlighting of connectible ports while connecting two ports we need to:&lt;br /&gt;
*#Find all suitable (IN/OUT/BOTH) ports available for connection.&lt;br /&gt;
*#Create a set their Types.&lt;br /&gt;
*#Check connect-ability for each of those types.&lt;br /&gt;
*#Highlight only the connectible ones.&lt;br /&gt;
&lt;br /&gt;
*To give a set of units that can be selected from a drop down menu in block properties:&lt;br /&gt;
*#Scan for the Type of the parameter.&lt;br /&gt;
*#Get the dimensions of the type.&lt;br /&gt;
*#Scan for the units available. &lt;br /&gt;
&lt;br /&gt;
*Implementation&lt;br /&gt;
**Some testing has been done of the functions, see &amp;lt;code&amp;gt;test_type_info()&amp;lt;/code&amp;gt; function inside /compiler/test/test_basics.c&lt;br /&gt;
**The test can be run on any file, using &amp;lt;code&amp;gt;scons test &amp;amp;&amp;amp; test/test compiler_basics.type_info&amp;lt;/code&amp;gt;&lt;br /&gt;
**From the observations, it is clear that the function &amp;lt;code&amp;gt;GetChildList()&amp;lt;/code&amp;gt; works as it should in case of all user generated foreseeable canvas models.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Weekly Reports GSOC 2011==&lt;br /&gt;
&lt;br /&gt;
The weekly reports will be filed here.&lt;br /&gt;
&lt;br /&gt;
====Week 0====&lt;br /&gt;
23th-May-11 to 29th-May-11&lt;br /&gt;
*Necessary changes for libavoid bindings.&lt;br /&gt;
**Still needs some work on the connection mechanism.&lt;br /&gt;
&lt;br /&gt;
====Week 1====&lt;br /&gt;
30th-May-11 to 5th-June-11&lt;br /&gt;
&lt;br /&gt;
====Week 2====&lt;br /&gt;
6th-June-11 to 12th-June-11&lt;br /&gt;
*Some progress towards having methods to set the default values. {{changeset|3474}}&lt;br /&gt;
*Some unusual behavior while updating to use of SWIG 2, some quick fixes. {{changeset|3482}}&lt;br /&gt;
*Some work towards getting stream into the canvas.&lt;br /&gt;
&lt;br /&gt;
====Week 3====&lt;br /&gt;
13th-June-11 to 19th-June-11&lt;br /&gt;
&lt;br /&gt;
Goals:&lt;br /&gt;
*Set up some mechanism of setting of default values.&lt;br /&gt;
*Get implementation ideas on setting up of globals and streams on the canvas. Possibly begin some work on them.&lt;br /&gt;
&lt;br /&gt;
====Week 4====&lt;br /&gt;
20th-June-11 to 26th-June-11&lt;br /&gt;
*Stream MODEL&#039;s recognized by canvas as globals.&lt;br /&gt;
*User can set streams to blocks.&lt;br /&gt;
*From some implementation there for the streams, through discussions it was found that for a very appropriate solution to the issue of streams, streams with variable components has to be taken into account.&lt;br /&gt;
*Spent the weekend on reading the complete models developed by Art on the Hydrogen cycles, which has a set based implementation of streams.&lt;br /&gt;
&lt;br /&gt;
====Week 5====&lt;br /&gt;
27th-June-11 to 3th-July-11&lt;br /&gt;
&lt;br /&gt;
Still struggling with the stream implementation, will do the complete update in a few days time.&lt;br /&gt;
*Writing a new version of Rankine cycle blocks for canvas using the &#039;stream&#039; component defined in the models/stream_holdup.a4l&lt;br /&gt;
*Some success, but still not being able to solve the generated model.&lt;br /&gt;
*Basically in canvas we will have a global &#039;stream&#039; whose properties can be edited using a GUI tool, that particular stream will hold the secrets to the rankine cycle being modeled, each block will use that stream as input and output. Equations inside the block will govern the relation between the output and the input.&lt;br /&gt;
&lt;br /&gt;
====Week 6====&lt;br /&gt;
4th-July-11 to 10th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 7====&lt;br /&gt;
11th-July-11 to 17th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 8====&lt;br /&gt;
18th-July-11 to 24th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 9====&lt;br /&gt;
25th-July-11 to 31st-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 10====&lt;br /&gt;
1st-August-11 to 7th-August-11&lt;br /&gt;
&lt;br /&gt;
====Week 11====&lt;br /&gt;
8th-August-11 to 15th-August-11&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=3052</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=3052"/>
		<updated>2011-08-24T06:18:55Z</updated>

		<summary type="html">&lt;p&gt;Grivan: /* Use Cases */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 and current development carried out by [[Grivan Thapar]]. The goals and tasks for the GSoC period are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. The concerns are right now at setting up better mechanisms for parameter handling and design enhancements like handling of stream objects, globals etc.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
*Global Model equations: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
&lt;br /&gt;
We want to solve models that have feedback loops,&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}} (NOTE: see also {{src|models/johnpye/fprops/rankine_fprops.a4c}} for newer version using [[FPROPS]] instead of [[freesteam]] -- JP). We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece.&lt;br /&gt;
*Elimination of redundant equations in closed loop flows. (Only if we do not use ATS)&lt;br /&gt;
*Specifications and provisioning of complex flow streams.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD. See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*Specifications and provisioning of complex flow streams.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious. For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling with backlash and PID control===&lt;br /&gt;
*Some time after we can look at solving a dynamic model!&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The new Gapahs 0.7.2 release till now seems to work fine.&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head 0.7.1. &lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
===Line routing===&lt;br /&gt;
Gaphas now supports line routing, the canvas code would require some changes to work with that. Check the avoid branch of gaphas. It uses [http://adaptagrams.sourceforge.net/libavoid/index.html libavoid] for this.&lt;br /&gt;
&lt;br /&gt;
==Improvements on the Solving Process==&lt;br /&gt;
Since we have no Type informations the solving is done primarily by first generating a string representation of the complete MODEL and then exported to the solver. This can lead to problems while trying to solve complex models requiring a large time to solve, because each time a variable is changed the complete model has to solved again. In case of PyGTK GUI we have a more powerful interaction with the solver and thus can change parameters without discarding the already solved model. The basic problem here lies in the fact that we don&#039;t instantiate the model first and then solve it.&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified.&lt;br /&gt;
*GUI implementation: This would provide a suitable GUI to select the stream. An annotated set defined in the &#039;stream&#039; block is being used to specify the stream components. A user must set through GUI the list of components that are needed to be a part of the stream. (eg: [&#039;N2&#039;,&#039;H2&#039;,&#039;NH3&#039;]).&lt;br /&gt;
*Application level implementation: At the application there are several ways the stream can be passed around. Conventionally the streams have been treated as first class objects, passing them around through blocks that accept parameters. But this approach has its own issues. Read further to know why.&lt;br /&gt;
The conventional way,&lt;br /&gt;
&amp;lt;source lang=&amp;quot;a4c&amp;quot;&amp;gt;&lt;br /&gt;
MODEL mycanvas;&lt;br /&gt;
A, B, C IS_A stream([&#039;N2&#039;,&#039;H2&#039;,&#039;NH3&#039;])&lt;br /&gt;
BO IS_A boiler(A,B);&lt;br /&gt;
CO IS_A condenser(C,A);&lt;br /&gt;
END mycanvas;&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
A way John suggests,&lt;br /&gt;
&amp;lt;source lang=&amp;quot;a4c&amp;quot;&amp;gt;&lt;br /&gt;
MODEL mycanvas;&lt;br /&gt;
A, B, C IS_A stream([&#039;N2&#039;,&#039;H2&#039;,&#039;NH3&#039;])&lt;br /&gt;
BO IS_A boiler;&lt;br /&gt;
CO IS_A condenser;&lt;br /&gt;
A, BO.inlet, CO.outlet ARE_THE_SAME;&lt;br /&gt;
END mycanvas;&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
The way it is now,&lt;br /&gt;
&amp;lt;source lang=&amp;quot;a4c&amp;quot;&amp;gt;&lt;br /&gt;
MODEL steram;&lt;br /&gt;
components &amp;quot;param: set of stream components&amp;quot; IS_A set OF symbol_constant;&lt;br /&gt;
END stream;&lt;br /&gt;
MODEL mycanvas;&lt;br /&gt;
A, B, C IS_A stream;&lt;br /&gt;
BO IS_A boiler;&lt;br /&gt;
CO IS_A condenser;&lt;br /&gt;
A, BO.inlet, CO.outlet ARE_THE_SAME;&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
The [[#Simple Rankine Cycle]] could be solved simply by connecting steam_port connectors. The {{src|models/johnpye/rankine.a4c}} uses Steam as the only modelling stream. This model needs to be evolved to use generic port types so that a better and more deep understanding is achieved in the problem of specifying flow streams.&lt;br /&gt;
The ASCEND library provides for generic &#039;stream&#039; types those of which could also be used for representing the stream at the canvas level. But there are several things that need to taken care of before something like that could be done. Some notes:&lt;br /&gt;
*The &#039;stream&#039; types are parametric, although we can support parametric stream (maybe, not yet proven) John feels that doing so we would not be able to use ATS inside our block types, that gives rise to the problem of redundant equations (which mostly goes away once if we use ATS). On the other hand many of commercial modelers use special schemes to remove redundant equations, we could also do that (that is just a speculation, we have no proof how we could do that).&lt;br /&gt;
*Using parametric blocks does give us a upper hand on handling parameters, (as John says) the ascend API reveals a lot more information about the parameters we pass. This would be better than our current nots based approach.&lt;br /&gt;
*Specifying streams requires &#039;sets&#039; to be defined, we might just require to use ARRAY types which can be defined on &#039;sets&#039;, but currently we have no way of identifying array types in our block models, not even through annotations. Some sort of &#039;hack&#039; can work though, but I am just saying.&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now.&lt;br /&gt;
&lt;br /&gt;
*To have highlighting of connectible ports while connecting two ports we need to:&lt;br /&gt;
*#Find all suitable (IN/OUT/BOTH) ports available for connection.&lt;br /&gt;
*#Create a set their Types.&lt;br /&gt;
*#Check connect-ability for each of those types.&lt;br /&gt;
*#Highlight only the connectible ones.&lt;br /&gt;
&lt;br /&gt;
*To give a set of units that can be selected from a drop down menu in block properties:&lt;br /&gt;
*#Scan for the Type of the parameter.&lt;br /&gt;
*#Get the dimensions of the type.&lt;br /&gt;
*#Scan for the units available. &lt;br /&gt;
&lt;br /&gt;
*Implementation&lt;br /&gt;
**Some testing has been done of the functions, see &amp;lt;code&amp;gt;test_type_info()&amp;lt;/code&amp;gt; function inside /compiler/test/test_basics.c&lt;br /&gt;
**The test can be run on any file, using &amp;lt;code&amp;gt;scons test &amp;amp;&amp;amp; test/test compiler_basics.type_info&amp;lt;/code&amp;gt;&lt;br /&gt;
**From the observations, it is clear that the function &amp;lt;code&amp;gt;GetChildList()&amp;lt;/code&amp;gt; works as it should in case of all user generated foreseeable canvas models.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Weekly Reports GSOC 2011==&lt;br /&gt;
&lt;br /&gt;
The weekly reports will be filed here.&lt;br /&gt;
&lt;br /&gt;
====Week 0====&lt;br /&gt;
23th-May-11 to 29th-May-11&lt;br /&gt;
*Necessary changes for libavoid bindings.&lt;br /&gt;
**Still needs some work on the connection mechanism.&lt;br /&gt;
&lt;br /&gt;
====Week 1====&lt;br /&gt;
30th-May-11 to 5th-June-11&lt;br /&gt;
&lt;br /&gt;
====Week 2====&lt;br /&gt;
6th-June-11 to 12th-June-11&lt;br /&gt;
*Some progress towards having methods to set the default values. {{changeset|3474}}&lt;br /&gt;
*Some unusual behavior while updating to use of SWIG 2, some quick fixes. {{changeset|3482}}&lt;br /&gt;
*Some work towards getting stream into the canvas.&lt;br /&gt;
&lt;br /&gt;
====Week 3====&lt;br /&gt;
13th-June-11 to 19th-June-11&lt;br /&gt;
&lt;br /&gt;
Goals:&lt;br /&gt;
*Set up some mechanism of setting of default values.&lt;br /&gt;
*Get implementation ideas on setting up of globals and streams on the canvas. Possibly begin some work on them.&lt;br /&gt;
&lt;br /&gt;
====Week 4====&lt;br /&gt;
20th-June-11 to 26th-June-11&lt;br /&gt;
*Stream MODEL&#039;s recognized by canvas as globals.&lt;br /&gt;
*User can set streams to blocks.&lt;br /&gt;
*From some implementation there for the streams, through discussions it was found that for a very appropriate solution to the issue of streams, streams with variable components has to be taken into account.&lt;br /&gt;
*Spent the weekend on reading the complete models developed by Art on the Hydrogen cycles, which has a set based implementation of streams.&lt;br /&gt;
&lt;br /&gt;
====Week 5====&lt;br /&gt;
27th-June-11 to 3th-July-11&lt;br /&gt;
&lt;br /&gt;
Still struggling with the stream implementation, will do the complete update in a few days time.&lt;br /&gt;
*Writing a new version of Rankine cycle blocks for canvas using the &#039;stream&#039; component defined in the models/stream_holdup.a4l&lt;br /&gt;
*Some success, but still not being able to solve the generated model.&lt;br /&gt;
*Basically in canvas we will have a global &#039;stream&#039; whose properties can be edited using a GUI tool, that particular stream will hold the secrets to the rankine cycle being modeled, each block will use that stream as input and output. Equations inside the block will govern the relation between the output and the input.&lt;br /&gt;
&lt;br /&gt;
====Week 6====&lt;br /&gt;
4th-July-11 to 10th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 7====&lt;br /&gt;
11th-July-11 to 17th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 8====&lt;br /&gt;
18th-July-11 to 24th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 9====&lt;br /&gt;
25th-July-11 to 31st-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 10====&lt;br /&gt;
1st-August-11 to 7th-August-11&lt;br /&gt;
&lt;br /&gt;
====Week 11====&lt;br /&gt;
8th-August-11 to 15th-August-11&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=3051</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=3051"/>
		<updated>2011-08-24T06:10:02Z</updated>

		<summary type="html">&lt;p&gt;Grivan: /* Simple Rankine Cycle */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 and current development carried out by [[Grivan Thapar]]. The goals and tasks for the GSoC period are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. The concerns are right now at setting up better mechanisms for parameter handling and design enhancements like handling of stream objects, globals etc.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
TODO : Add more ideas, put a concrete solution overview to each Case. Add new use cases based upon electronic circuit models sent over by [[Divyanshu Bandil|Divyanshu]].&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
*Global Model equations: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}} (NOTE: see also {{src|models/johnpye/fprops/rankine_fprops.a4c}} for newer version using [[FPROPS]] instead of [[freesteam]] -- JP). We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece. In addition take care of the ALIASES keyword used in the text model. TODO&lt;br /&gt;
*Elimination of redundant equations in closed loop flows.&lt;br /&gt;
*:Multiple loops present in the system.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Still needs to be discussed. TODO&lt;br /&gt;
*Specifications of flow streams. &lt;br /&gt;
*:It should be possible to switch between stream components, water to CO2 to toluene for example.&lt;br /&gt;
*:This however should &#039;&#039;&#039;not&#039;&#039;&#039; involve redrawing the whole model again.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Streams can be defined in the canvas by selecting the particular connections and specifying the stream component, the connections to these components at the ports must use the values of stream component provided. TODO&lt;br /&gt;
*Providing complex flow streams.&lt;br /&gt;
*:A regenerative cycle requires to specify the fraction of steam extracted at the &#039;&#039;bled&#039;&#039; point, that is a TEE in our sense. Such a fraction must be supplied by the user while making such connections. Assuming an open feedwater scheme.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; This should be easy as a simple TEE component must have a fixable variable &#039;fraction&#039;.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*In this case connections may need to be manually specified in order to provide complex flows as required.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious.&lt;br /&gt;
**For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling of Servo Motor with backlash and PID control===&lt;br /&gt;
*TODO : Add description&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The new Gapahs 0.7.2 release till now seems to work fine.&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head 0.7.1. &lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
===Line routing===&lt;br /&gt;
Gaphas now supports line routing, the canvas code would require some changes to work with that. Check the avoid branch of gaphas. It uses [http://adaptagrams.sourceforge.net/libavoid/index.html libavoid] for this.&lt;br /&gt;
&lt;br /&gt;
==Improvements on the Solving Process==&lt;br /&gt;
Since we have no Type informations the solving is done primarily by first generating a string representation of the complete MODEL and then exported to the solver. This can lead to problems while trying to solve complex models requiring a large time to solve, because each time a variable is changed the complete model has to solved again. In case of PyGTK GUI we have a more powerful interaction with the solver and thus can change parameters without discarding the already solved model. The basic problem here lies in the fact that we don&#039;t instantiate the model first and then solve it.&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified.&lt;br /&gt;
*GUI implementation: This would provide a suitable GUI to select the stream. An annotated set defined in the &#039;stream&#039; block is being used to specify the stream components. A user must set through GUI the list of components that are needed to be a part of the stream. (eg: [&#039;N2&#039;,&#039;H2&#039;,&#039;NH3&#039;]).&lt;br /&gt;
*Application level implementation: At the application there are several ways the stream can be passed around. Conventionally the streams have been treated as first class objects, passing them around through blocks that accept parameters. But this approach has its own issues. Read further to know why.&lt;br /&gt;
The conventional way,&lt;br /&gt;
&amp;lt;source lang=&amp;quot;a4c&amp;quot;&amp;gt;&lt;br /&gt;
MODEL mycanvas;&lt;br /&gt;
A, B, C IS_A stream([&#039;N2&#039;,&#039;H2&#039;,&#039;NH3&#039;])&lt;br /&gt;
BO IS_A boiler(A,B);&lt;br /&gt;
CO IS_A condenser(C,A);&lt;br /&gt;
END mycanvas;&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
A way John suggests,&lt;br /&gt;
&amp;lt;source lang=&amp;quot;a4c&amp;quot;&amp;gt;&lt;br /&gt;
MODEL mycanvas;&lt;br /&gt;
A, B, C IS_A stream([&#039;N2&#039;,&#039;H2&#039;,&#039;NH3&#039;])&lt;br /&gt;
BO IS_A boiler;&lt;br /&gt;
CO IS_A condenser;&lt;br /&gt;
A, BO.inlet, CO.outlet ARE_THE_SAME;&lt;br /&gt;
END mycanvas;&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
The way it is now,&lt;br /&gt;
&amp;lt;source lang=&amp;quot;a4c&amp;quot;&amp;gt;&lt;br /&gt;
MODEL steram;&lt;br /&gt;
components &amp;quot;param: set of stream components&amp;quot; IS_A set OF symbol_constant;&lt;br /&gt;
END stream;&lt;br /&gt;
MODEL mycanvas;&lt;br /&gt;
A, B, C IS_A stream;&lt;br /&gt;
BO IS_A boiler;&lt;br /&gt;
CO IS_A condenser;&lt;br /&gt;
A, BO.inlet, CO.outlet ARE_THE_SAME;&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
The [[#Simple Rankine Cycle]] could be solved simply by connecting steam_port connectors. The {{src|models/johnpye/rankine.a4c}} uses Steam as the only modelling stream. This model needs to be evolved to use generic port types so that a better and more deep understanding is achieved in the problem of specifying flow streams.&lt;br /&gt;
The ASCEND library provides for generic &#039;stream&#039; types those of which could also be used for representing the stream at the canvas level. But there are several things that need to taken care of before something like that could be done. Some notes:&lt;br /&gt;
*The &#039;stream&#039; types are parametric, although we can support parametric stream (maybe, not yet proven) John feels that doing so we would not be able to use ATS inside our block types, that gives rise to the problem of redundant equations (which mostly goes away once if we use ATS). On the other hand many of commercial modelers use special schemes to remove redundant equations, we could also do that (that is just a speculation, we have no proof how we could do that).&lt;br /&gt;
*Using parametric blocks does give us a upper hand on handling parameters, (as John says) the ascend API reveals a lot more information about the parameters we pass. This would be better than our current nots based approach.&lt;br /&gt;
*Specifying streams requires &#039;sets&#039; to be defined, we might just require to use ARRAY types which can be defined on &#039;sets&#039;, but currently we have no way of identifying array types in our block models, not even through annotations. Some sort of &#039;hack&#039; can work though, but I am just saying.&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now.&lt;br /&gt;
&lt;br /&gt;
*To have highlighting of connectible ports while connecting two ports we need to:&lt;br /&gt;
*#Find all suitable (IN/OUT/BOTH) ports available for connection.&lt;br /&gt;
*#Create a set their Types.&lt;br /&gt;
*#Check connect-ability for each of those types.&lt;br /&gt;
*#Highlight only the connectible ones.&lt;br /&gt;
&lt;br /&gt;
*To give a set of units that can be selected from a drop down menu in block properties:&lt;br /&gt;
*#Scan for the Type of the parameter.&lt;br /&gt;
*#Get the dimensions of the type.&lt;br /&gt;
*#Scan for the units available. &lt;br /&gt;
&lt;br /&gt;
*Implementation&lt;br /&gt;
**Some testing has been done of the functions, see &amp;lt;code&amp;gt;test_type_info()&amp;lt;/code&amp;gt; function inside /compiler/test/test_basics.c&lt;br /&gt;
**The test can be run on any file, using &amp;lt;code&amp;gt;scons test &amp;amp;&amp;amp; test/test compiler_basics.type_info&amp;lt;/code&amp;gt;&lt;br /&gt;
**From the observations, it is clear that the function &amp;lt;code&amp;gt;GetChildList()&amp;lt;/code&amp;gt; works as it should in case of all user generated foreseeable canvas models.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Weekly Reports GSOC 2011==&lt;br /&gt;
&lt;br /&gt;
The weekly reports will be filed here.&lt;br /&gt;
&lt;br /&gt;
====Week 0====&lt;br /&gt;
23th-May-11 to 29th-May-11&lt;br /&gt;
*Necessary changes for libavoid bindings.&lt;br /&gt;
**Still needs some work on the connection mechanism.&lt;br /&gt;
&lt;br /&gt;
====Week 1====&lt;br /&gt;
30th-May-11 to 5th-June-11&lt;br /&gt;
&lt;br /&gt;
====Week 2====&lt;br /&gt;
6th-June-11 to 12th-June-11&lt;br /&gt;
*Some progress towards having methods to set the default values. {{changeset|3474}}&lt;br /&gt;
*Some unusual behavior while updating to use of SWIG 2, some quick fixes. {{changeset|3482}}&lt;br /&gt;
*Some work towards getting stream into the canvas.&lt;br /&gt;
&lt;br /&gt;
====Week 3====&lt;br /&gt;
13th-June-11 to 19th-June-11&lt;br /&gt;
&lt;br /&gt;
Goals:&lt;br /&gt;
*Set up some mechanism of setting of default values.&lt;br /&gt;
*Get implementation ideas on setting up of globals and streams on the canvas. Possibly begin some work on them.&lt;br /&gt;
&lt;br /&gt;
====Week 4====&lt;br /&gt;
20th-June-11 to 26th-June-11&lt;br /&gt;
*Stream MODEL&#039;s recognized by canvas as globals.&lt;br /&gt;
*User can set streams to blocks.&lt;br /&gt;
*From some implementation there for the streams, through discussions it was found that for a very appropriate solution to the issue of streams, streams with variable components has to be taken into account.&lt;br /&gt;
*Spent the weekend on reading the complete models developed by Art on the Hydrogen cycles, which has a set based implementation of streams.&lt;br /&gt;
&lt;br /&gt;
====Week 5====&lt;br /&gt;
27th-June-11 to 3th-July-11&lt;br /&gt;
&lt;br /&gt;
Still struggling with the stream implementation, will do the complete update in a few days time.&lt;br /&gt;
*Writing a new version of Rankine cycle blocks for canvas using the &#039;stream&#039; component defined in the models/stream_holdup.a4l&lt;br /&gt;
*Some success, but still not being able to solve the generated model.&lt;br /&gt;
*Basically in canvas we will have a global &#039;stream&#039; whose properties can be edited using a GUI tool, that particular stream will hold the secrets to the rankine cycle being modeled, each block will use that stream as input and output. Equations inside the block will govern the relation between the output and the input.&lt;br /&gt;
&lt;br /&gt;
====Week 6====&lt;br /&gt;
4th-July-11 to 10th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 7====&lt;br /&gt;
11th-July-11 to 17th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 8====&lt;br /&gt;
18th-July-11 to 24th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 9====&lt;br /&gt;
25th-July-11 to 31st-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 10====&lt;br /&gt;
1st-August-11 to 7th-August-11&lt;br /&gt;
&lt;br /&gt;
====Week 11====&lt;br /&gt;
8th-August-11 to 15th-August-11&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=3050</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=3050"/>
		<updated>2011-08-24T06:07:21Z</updated>

		<summary type="html">&lt;p&gt;Grivan: /* GUI Usability Improvements */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 and current development carried out by [[Grivan Thapar]]. The goals and tasks for the GSoC period are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. The concerns are right now at setting up better mechanisms for parameter handling and design enhancements like handling of stream objects, globals etc.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
TODO : Add more ideas, put a concrete solution overview to each Case. Add new use cases based upon electronic circuit models sent over by [[Divyanshu Bandil|Divyanshu]].&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
*Global Model equations.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
*Block rotation.&lt;br /&gt;
*:It would be nice if blocks could be rotated, it makes the canvas look more tidy.&lt;br /&gt;
*Other Issues.&lt;br /&gt;
*:Just specifying a value and not Fixing it. Should it be possible? &lt;br /&gt;
*: How to make additions of equations to the MODEL more intuitive.&lt;br /&gt;
&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}} (NOTE: see also {{src|models/johnpye/fprops/rankine_fprops.a4c}} for newer version using [[FPROPS]] instead of [[freesteam]] -- JP). We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece. In addition take care of the ALIASES keyword used in the text model. TODO&lt;br /&gt;
*Elimination of redundant equations in closed loop flows.&lt;br /&gt;
*:Multiple loops present in the system.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Still needs to be discussed. TODO&lt;br /&gt;
*Specifications of flow streams. &lt;br /&gt;
*:It should be possible to switch between stream components, water to CO2 to toluene for example.&lt;br /&gt;
*:This however should &#039;&#039;&#039;not&#039;&#039;&#039; involve redrawing the whole model again.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Streams can be defined in the canvas by selecting the particular connections and specifying the stream component, the connections to these components at the ports must use the values of stream component provided. TODO&lt;br /&gt;
*Providing complex flow streams.&lt;br /&gt;
*:A regenerative cycle requires to specify the fraction of steam extracted at the &#039;&#039;bled&#039;&#039; point, that is a TEE in our sense. Such a fraction must be supplied by the user while making such connections. Assuming an open feedwater scheme.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; This should be easy as a simple TEE component must have a fixable variable &#039;fraction&#039;.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*In this case connections may need to be manually specified in order to provide complex flows as required.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious.&lt;br /&gt;
**For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling of Servo Motor with backlash and PID control===&lt;br /&gt;
*TODO : Add description&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The new Gapahs 0.7.2 release till now seems to work fine.&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head 0.7.1. &lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
===Line routing===&lt;br /&gt;
Gaphas now supports line routing, the canvas code would require some changes to work with that. Check the avoid branch of gaphas. It uses [http://adaptagrams.sourceforge.net/libavoid/index.html libavoid] for this.&lt;br /&gt;
&lt;br /&gt;
==Improvements on the Solving Process==&lt;br /&gt;
Since we have no Type informations the solving is done primarily by first generating a string representation of the complete MODEL and then exported to the solver. This can lead to problems while trying to solve complex models requiring a large time to solve, because each time a variable is changed the complete model has to solved again. In case of PyGTK GUI we have a more powerful interaction with the solver and thus can change parameters without discarding the already solved model. The basic problem here lies in the fact that we don&#039;t instantiate the model first and then solve it.&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified.&lt;br /&gt;
*GUI implementation: This would provide a suitable GUI to select the stream. An annotated set defined in the &#039;stream&#039; block is being used to specify the stream components. A user must set through GUI the list of components that are needed to be a part of the stream. (eg: [&#039;N2&#039;,&#039;H2&#039;,&#039;NH3&#039;]).&lt;br /&gt;
*Application level implementation: At the application there are several ways the stream can be passed around. Conventionally the streams have been treated as first class objects, passing them around through blocks that accept parameters. But this approach has its own issues. Read further to know why.&lt;br /&gt;
The conventional way,&lt;br /&gt;
&amp;lt;source lang=&amp;quot;a4c&amp;quot;&amp;gt;&lt;br /&gt;
MODEL mycanvas;&lt;br /&gt;
A, B, C IS_A stream([&#039;N2&#039;,&#039;H2&#039;,&#039;NH3&#039;])&lt;br /&gt;
BO IS_A boiler(A,B);&lt;br /&gt;
CO IS_A condenser(C,A);&lt;br /&gt;
END mycanvas;&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
A way John suggests,&lt;br /&gt;
&amp;lt;source lang=&amp;quot;a4c&amp;quot;&amp;gt;&lt;br /&gt;
MODEL mycanvas;&lt;br /&gt;
A, B, C IS_A stream([&#039;N2&#039;,&#039;H2&#039;,&#039;NH3&#039;])&lt;br /&gt;
BO IS_A boiler;&lt;br /&gt;
CO IS_A condenser;&lt;br /&gt;
A, BO.inlet, CO.outlet ARE_THE_SAME;&lt;br /&gt;
END mycanvas;&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
The way it is now,&lt;br /&gt;
&amp;lt;source lang=&amp;quot;a4c&amp;quot;&amp;gt;&lt;br /&gt;
MODEL steram;&lt;br /&gt;
components &amp;quot;param: set of stream components&amp;quot; IS_A set OF symbol_constant;&lt;br /&gt;
END stream;&lt;br /&gt;
MODEL mycanvas;&lt;br /&gt;
A, B, C IS_A stream;&lt;br /&gt;
BO IS_A boiler;&lt;br /&gt;
CO IS_A condenser;&lt;br /&gt;
A, BO.inlet, CO.outlet ARE_THE_SAME;&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
The [[#Simple Rankine Cycle]] could be solved simply by connecting steam_port connectors. The {{src|models/johnpye/rankine.a4c}} uses Steam as the only modelling stream. This model needs to be evolved to use generic port types so that a better and more deep understanding is achieved in the problem of specifying flow streams.&lt;br /&gt;
The ASCEND library provides for generic &#039;stream&#039; types those of which could also be used for representing the stream at the canvas level. But there are several things that need to taken care of before something like that could be done. Some notes:&lt;br /&gt;
*The &#039;stream&#039; types are parametric, although we can support parametric stream (maybe, not yet proven) John feels that doing so we would not be able to use ATS inside our block types, that gives rise to the problem of redundant equations (which mostly goes away once if we use ATS). On the other hand many of commercial modelers use special schemes to remove redundant equations, we could also do that (that is just a speculation, we have no proof how we could do that).&lt;br /&gt;
*Using parametric blocks does give us a upper hand on handling parameters, (as John says) the ascend API reveals a lot more information about the parameters we pass. This would be better than our current nots based approach.&lt;br /&gt;
*Specifying streams requires &#039;sets&#039; to be defined, we might just require to use ARRAY types which can be defined on &#039;sets&#039;, but currently we have no way of identifying array types in our block models, not even through annotations. Some sort of &#039;hack&#039; can work though, but I am just saying.&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now.&lt;br /&gt;
&lt;br /&gt;
*To have highlighting of connectible ports while connecting two ports we need to:&lt;br /&gt;
*#Find all suitable (IN/OUT/BOTH) ports available for connection.&lt;br /&gt;
*#Create a set their Types.&lt;br /&gt;
*#Check connect-ability for each of those types.&lt;br /&gt;
*#Highlight only the connectible ones.&lt;br /&gt;
&lt;br /&gt;
*To give a set of units that can be selected from a drop down menu in block properties:&lt;br /&gt;
*#Scan for the Type of the parameter.&lt;br /&gt;
*#Get the dimensions of the type.&lt;br /&gt;
*#Scan for the units available. &lt;br /&gt;
&lt;br /&gt;
*Implementation&lt;br /&gt;
**Some testing has been done of the functions, see &amp;lt;code&amp;gt;test_type_info()&amp;lt;/code&amp;gt; function inside /compiler/test/test_basics.c&lt;br /&gt;
**The test can be run on any file, using &amp;lt;code&amp;gt;scons test &amp;amp;&amp;amp; test/test compiler_basics.type_info&amp;lt;/code&amp;gt;&lt;br /&gt;
**From the observations, it is clear that the function &amp;lt;code&amp;gt;GetChildList()&amp;lt;/code&amp;gt; works as it should in case of all user generated foreseeable canvas models.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Weekly Reports GSOC 2011==&lt;br /&gt;
&lt;br /&gt;
The weekly reports will be filed here.&lt;br /&gt;
&lt;br /&gt;
====Week 0====&lt;br /&gt;
23th-May-11 to 29th-May-11&lt;br /&gt;
*Necessary changes for libavoid bindings.&lt;br /&gt;
**Still needs some work on the connection mechanism.&lt;br /&gt;
&lt;br /&gt;
====Week 1====&lt;br /&gt;
30th-May-11 to 5th-June-11&lt;br /&gt;
&lt;br /&gt;
====Week 2====&lt;br /&gt;
6th-June-11 to 12th-June-11&lt;br /&gt;
*Some progress towards having methods to set the default values. {{changeset|3474}}&lt;br /&gt;
*Some unusual behavior while updating to use of SWIG 2, some quick fixes. {{changeset|3482}}&lt;br /&gt;
*Some work towards getting stream into the canvas.&lt;br /&gt;
&lt;br /&gt;
====Week 3====&lt;br /&gt;
13th-June-11 to 19th-June-11&lt;br /&gt;
&lt;br /&gt;
Goals:&lt;br /&gt;
*Set up some mechanism of setting of default values.&lt;br /&gt;
*Get implementation ideas on setting up of globals and streams on the canvas. Possibly begin some work on them.&lt;br /&gt;
&lt;br /&gt;
====Week 4====&lt;br /&gt;
20th-June-11 to 26th-June-11&lt;br /&gt;
*Stream MODEL&#039;s recognized by canvas as globals.&lt;br /&gt;
*User can set streams to blocks.&lt;br /&gt;
*From some implementation there for the streams, through discussions it was found that for a very appropriate solution to the issue of streams, streams with variable components has to be taken into account.&lt;br /&gt;
*Spent the weekend on reading the complete models developed by Art on the Hydrogen cycles, which has a set based implementation of streams.&lt;br /&gt;
&lt;br /&gt;
====Week 5====&lt;br /&gt;
27th-June-11 to 3th-July-11&lt;br /&gt;
&lt;br /&gt;
Still struggling with the stream implementation, will do the complete update in a few days time.&lt;br /&gt;
*Writing a new version of Rankine cycle blocks for canvas using the &#039;stream&#039; component defined in the models/stream_holdup.a4l&lt;br /&gt;
*Some success, but still not being able to solve the generated model.&lt;br /&gt;
*Basically in canvas we will have a global &#039;stream&#039; whose properties can be edited using a GUI tool, that particular stream will hold the secrets to the rankine cycle being modeled, each block will use that stream as input and output. Equations inside the block will govern the relation between the output and the input.&lt;br /&gt;
&lt;br /&gt;
====Week 6====&lt;br /&gt;
4th-July-11 to 10th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 7====&lt;br /&gt;
11th-July-11 to 17th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 8====&lt;br /&gt;
18th-July-11 to 24th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 9====&lt;br /&gt;
25th-July-11 to 31st-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 10====&lt;br /&gt;
1st-August-11 to 7th-August-11&lt;br /&gt;
&lt;br /&gt;
====Week 11====&lt;br /&gt;
8th-August-11 to 15th-August-11&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=3049</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=3049"/>
		<updated>2011-08-24T05:40:44Z</updated>

		<summary type="html">&lt;p&gt;Grivan: /* Specification of flow streams */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 and current development carried out by [[Grivan Thapar]]. The goals and tasks for the GSoC period are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. The concerns are right now at setting up better mechanisms for parameter handling and design enhancements like handling of stream objects, globals etc.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
TODO : Add more ideas, put a concrete solution overview to each Case. Add new use cases based upon electronic circuit models sent over by [[Divyanshu Bandil|Divyanshu]].&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
*Global Model equations.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
*Block rotation.&lt;br /&gt;
*:It would be nice if blocks could be rotated, it makes the canvas look more tidy.&lt;br /&gt;
*Other Issues.&lt;br /&gt;
*:Just specifying a value and not Fixing it. Should it be possible? &lt;br /&gt;
*: How to make additions of equations to the MODEL more intuitive.&lt;br /&gt;
&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}} (NOTE: see also {{src|models/johnpye/fprops/rankine_fprops.a4c}} for newer version using [[FPROPS]] instead of [[freesteam]] -- JP). We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece. In addition take care of the ALIASES keyword used in the text model. TODO&lt;br /&gt;
*Elimination of redundant equations in closed loop flows.&lt;br /&gt;
*:Multiple loops present in the system.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Still needs to be discussed. TODO&lt;br /&gt;
*Specifications of flow streams. &lt;br /&gt;
*:It should be possible to switch between stream components, water to CO2 to toluene for example.&lt;br /&gt;
*:This however should &#039;&#039;&#039;not&#039;&#039;&#039; involve redrawing the whole model again.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Streams can be defined in the canvas by selecting the particular connections and specifying the stream component, the connections to these components at the ports must use the values of stream component provided. TODO&lt;br /&gt;
*Providing complex flow streams.&lt;br /&gt;
*:A regenerative cycle requires to specify the fraction of steam extracted at the &#039;&#039;bled&#039;&#039; point, that is a TEE in our sense. Such a fraction must be supplied by the user while making such connections. Assuming an open feedwater scheme.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; This should be easy as a simple TEE component must have a fixable variable &#039;fraction&#039;.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*In this case connections may need to be manually specified in order to provide complex flows as required.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious.&lt;br /&gt;
**For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling of Servo Motor with backlash and PID control===&lt;br /&gt;
*TODO : Add description&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The new Gapahs 0.7.2 release till now seems to work fine.&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head 0.7.1. &lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
TODO : Keep adding details&lt;br /&gt;
&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
==Improvements on the Solving Process==&lt;br /&gt;
Since we have no Type informations the solving is done primarily by first generating a string representation of the complete MODEL and then exported to the solver. This can lead to problems while trying to solve complex models requiring a large time to solve, because each time a variable is changed the complete model has to solved again. In case of PyGTK GUI we have a more powerful interaction with the solver and thus can change parameters without discarding the already solved model. The basic problem here lies in the fact that we don&#039;t instantiate the model first and then solve it.&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified.&lt;br /&gt;
*GUI implementation: This would provide a suitable GUI to select the stream. An annotated set defined in the &#039;stream&#039; block is being used to specify the stream components. A user must set through GUI the list of components that are needed to be a part of the stream. (eg: [&#039;N2&#039;,&#039;H2&#039;,&#039;NH3&#039;]).&lt;br /&gt;
*Application level implementation: At the application there are several ways the stream can be passed around. Conventionally the streams have been treated as first class objects, passing them around through blocks that accept parameters. But this approach has its own issues. Read further to know why.&lt;br /&gt;
The conventional way,&lt;br /&gt;
&amp;lt;source lang=&amp;quot;a4c&amp;quot;&amp;gt;&lt;br /&gt;
MODEL mycanvas;&lt;br /&gt;
A, B, C IS_A stream([&#039;N2&#039;,&#039;H2&#039;,&#039;NH3&#039;])&lt;br /&gt;
BO IS_A boiler(A,B);&lt;br /&gt;
CO IS_A condenser(C,A);&lt;br /&gt;
END mycanvas;&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
A way John suggests,&lt;br /&gt;
&amp;lt;source lang=&amp;quot;a4c&amp;quot;&amp;gt;&lt;br /&gt;
MODEL mycanvas;&lt;br /&gt;
A, B, C IS_A stream([&#039;N2&#039;,&#039;H2&#039;,&#039;NH3&#039;])&lt;br /&gt;
BO IS_A boiler;&lt;br /&gt;
CO IS_A condenser;&lt;br /&gt;
A, BO.inlet, CO.outlet ARE_THE_SAME;&lt;br /&gt;
END mycanvas;&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
The way it is now,&lt;br /&gt;
&amp;lt;source lang=&amp;quot;a4c&amp;quot;&amp;gt;&lt;br /&gt;
MODEL steram;&lt;br /&gt;
components &amp;quot;param: set of stream components&amp;quot; IS_A set OF symbol_constant;&lt;br /&gt;
END stream;&lt;br /&gt;
MODEL mycanvas;&lt;br /&gt;
A, B, C IS_A stream;&lt;br /&gt;
BO IS_A boiler;&lt;br /&gt;
CO IS_A condenser;&lt;br /&gt;
A, BO.inlet, CO.outlet ARE_THE_SAME;&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
The [[#Simple Rankine Cycle]] could be solved simply by connecting steam_port connectors. The {{src|models/johnpye/rankine.a4c}} uses Steam as the only modelling stream. This model needs to be evolved to use generic port types so that a better and more deep understanding is achieved in the problem of specifying flow streams.&lt;br /&gt;
The ASCEND library provides for generic &#039;stream&#039; types those of which could also be used for representing the stream at the canvas level. But there are several things that need to taken care of before something like that could be done. Some notes:&lt;br /&gt;
*The &#039;stream&#039; types are parametric, although we can support parametric stream (maybe, not yet proven) John feels that doing so we would not be able to use ATS inside our block types, that gives rise to the problem of redundant equations (which mostly goes away once if we use ATS). On the other hand many of commercial modelers use special schemes to remove redundant equations, we could also do that (that is just a speculation, we have no proof how we could do that).&lt;br /&gt;
*Using parametric blocks does give us a upper hand on handling parameters, (as John says) the ascend API reveals a lot more information about the parameters we pass. This would be better than our current nots based approach.&lt;br /&gt;
*Specifying streams requires &#039;sets&#039; to be defined, we might just require to use ARRAY types which can be defined on &#039;sets&#039;, but currently we have no way of identifying array types in our block models, not even through annotations. Some sort of &#039;hack&#039; can work though, but I am just saying.&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now.&lt;br /&gt;
&lt;br /&gt;
*To have highlighting of connectible ports while connecting two ports we need to:&lt;br /&gt;
*#Find all suitable (IN/OUT/BOTH) ports available for connection.&lt;br /&gt;
*#Create a set their Types.&lt;br /&gt;
*#Check connect-ability for each of those types.&lt;br /&gt;
*#Highlight only the connectible ones.&lt;br /&gt;
&lt;br /&gt;
*To give a set of units that can be selected from a drop down menu in block properties:&lt;br /&gt;
*#Scan for the Type of the parameter.&lt;br /&gt;
*#Get the dimensions of the type.&lt;br /&gt;
*#Scan for the units available. &lt;br /&gt;
&lt;br /&gt;
*Implementation&lt;br /&gt;
**Some testing has been done of the functions, see &amp;lt;code&amp;gt;test_type_info()&amp;lt;/code&amp;gt; function inside /compiler/test/test_basics.c&lt;br /&gt;
**The test can be run on any file, using &amp;lt;code&amp;gt;scons test &amp;amp;&amp;amp; test/test compiler_basics.type_info&amp;lt;/code&amp;gt;&lt;br /&gt;
**From the observations, it is clear that the function &amp;lt;code&amp;gt;GetChildList()&amp;lt;/code&amp;gt; works as it should in case of all user generated foreseeable canvas models.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Weekly Reports GSOC 2011==&lt;br /&gt;
&lt;br /&gt;
The weekly reports will be filed here.&lt;br /&gt;
&lt;br /&gt;
====Week 0====&lt;br /&gt;
23th-May-11 to 29th-May-11&lt;br /&gt;
*Necessary changes for libavoid bindings.&lt;br /&gt;
**Still needs some work on the connection mechanism.&lt;br /&gt;
&lt;br /&gt;
====Week 1====&lt;br /&gt;
30th-May-11 to 5th-June-11&lt;br /&gt;
&lt;br /&gt;
====Week 2====&lt;br /&gt;
6th-June-11 to 12th-June-11&lt;br /&gt;
*Some progress towards having methods to set the default values. {{changeset|3474}}&lt;br /&gt;
*Some unusual behavior while updating to use of SWIG 2, some quick fixes. {{changeset|3482}}&lt;br /&gt;
*Some work towards getting stream into the canvas.&lt;br /&gt;
&lt;br /&gt;
====Week 3====&lt;br /&gt;
13th-June-11 to 19th-June-11&lt;br /&gt;
&lt;br /&gt;
Goals:&lt;br /&gt;
*Set up some mechanism of setting of default values.&lt;br /&gt;
*Get implementation ideas on setting up of globals and streams on the canvas. Possibly begin some work on them.&lt;br /&gt;
&lt;br /&gt;
====Week 4====&lt;br /&gt;
20th-June-11 to 26th-June-11&lt;br /&gt;
*Stream MODEL&#039;s recognized by canvas as globals.&lt;br /&gt;
*User can set streams to blocks.&lt;br /&gt;
*From some implementation there for the streams, through discussions it was found that for a very appropriate solution to the issue of streams, streams with variable components has to be taken into account.&lt;br /&gt;
*Spent the weekend on reading the complete models developed by Art on the Hydrogen cycles, which has a set based implementation of streams.&lt;br /&gt;
&lt;br /&gt;
====Week 5====&lt;br /&gt;
27th-June-11 to 3th-July-11&lt;br /&gt;
&lt;br /&gt;
Still struggling with the stream implementation, will do the complete update in a few days time.&lt;br /&gt;
*Writing a new version of Rankine cycle blocks for canvas using the &#039;stream&#039; component defined in the models/stream_holdup.a4l&lt;br /&gt;
*Some success, but still not being able to solve the generated model.&lt;br /&gt;
*Basically in canvas we will have a global &#039;stream&#039; whose properties can be edited using a GUI tool, that particular stream will hold the secrets to the rankine cycle being modeled, each block will use that stream as input and output. Equations inside the block will govern the relation between the output and the input.&lt;br /&gt;
&lt;br /&gt;
====Week 6====&lt;br /&gt;
4th-July-11 to 10th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 7====&lt;br /&gt;
11th-July-11 to 17th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 8====&lt;br /&gt;
18th-July-11 to 24th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 9====&lt;br /&gt;
25th-July-11 to 31st-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 10====&lt;br /&gt;
1st-August-11 to 7th-August-11&lt;br /&gt;
&lt;br /&gt;
====Week 11====&lt;br /&gt;
8th-August-11 to 15th-August-11&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=3048</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=3048"/>
		<updated>2011-08-24T05:27:32Z</updated>

		<summary type="html">&lt;p&gt;Grivan: /* Specification of flow streams */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 and current development carried out by [[Grivan Thapar]]. The goals and tasks for the GSoC period are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. The concerns are right now at setting up better mechanisms for parameter handling and design enhancements like handling of stream objects, globals etc.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
TODO : Add more ideas, put a concrete solution overview to each Case. Add new use cases based upon electronic circuit models sent over by [[Divyanshu Bandil|Divyanshu]].&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
*Global Model equations.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
*Block rotation.&lt;br /&gt;
*:It would be nice if blocks could be rotated, it makes the canvas look more tidy.&lt;br /&gt;
*Other Issues.&lt;br /&gt;
*:Just specifying a value and not Fixing it. Should it be possible? &lt;br /&gt;
*: How to make additions of equations to the MODEL more intuitive.&lt;br /&gt;
&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}} (NOTE: see also {{src|models/johnpye/fprops/rankine_fprops.a4c}} for newer version using [[FPROPS]] instead of [[freesteam]] -- JP). We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece. In addition take care of the ALIASES keyword used in the text model. TODO&lt;br /&gt;
*Elimination of redundant equations in closed loop flows.&lt;br /&gt;
*:Multiple loops present in the system.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Still needs to be discussed. TODO&lt;br /&gt;
*Specifications of flow streams. &lt;br /&gt;
*:It should be possible to switch between stream components, water to CO2 to toluene for example.&lt;br /&gt;
*:This however should &#039;&#039;&#039;not&#039;&#039;&#039; involve redrawing the whole model again.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Streams can be defined in the canvas by selecting the particular connections and specifying the stream component, the connections to these components at the ports must use the values of stream component provided. TODO&lt;br /&gt;
*Providing complex flow streams.&lt;br /&gt;
*:A regenerative cycle requires to specify the fraction of steam extracted at the &#039;&#039;bled&#039;&#039; point, that is a TEE in our sense. Such a fraction must be supplied by the user while making such connections. Assuming an open feedwater scheme.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; This should be easy as a simple TEE component must have a fixable variable &#039;fraction&#039;.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*In this case connections may need to be manually specified in order to provide complex flows as required.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious.&lt;br /&gt;
**For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling of Servo Motor with backlash and PID control===&lt;br /&gt;
*TODO : Add description&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The new Gapahs 0.7.2 release till now seems to work fine.&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head 0.7.1. &lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
TODO : Keep adding details&lt;br /&gt;
&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
==Improvements on the Solving Process==&lt;br /&gt;
Since we have no Type informations the solving is done primarily by first generating a string representation of the complete MODEL and then exported to the solver. This can lead to problems while trying to solve complex models requiring a large time to solve, because each time a variable is changed the complete model has to solved again. In case of PyGTK GUI we have a more powerful interaction with the solver and thus can change parameters without discarding the already solved model. The basic problem here lies in the fact that we don&#039;t instantiate the model first and then solve it.&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified. This provides and excellent way to have the same model provide simulation for any number of streams. Two implementations have to be taken care of to specify streams;&lt;br /&gt;
*GUI implementation: This would provide a suitable GUI to select the stream. An annotated set defined in the &#039;stream&#039; block is being used to specify the stream components. A user must set through GUI the list of components that are needed to be a part of the stream. (eg: [&#039;N2&#039;,&#039;H2&#039;,&#039;NH3&#039;]).&lt;br /&gt;
*Application level implementation: &lt;br /&gt;
&lt;br /&gt;
The [[#Simple Rankine Cycle]] could be solved simply by connecting steam_port connectors. The {{src|models/johnpye/rankine.a4c}} uses Steam as the only modelling stream. This model needs to be evolved to use generic port types so that a better and more deep understanding is achieved in the problem of specifying flow streams.&lt;br /&gt;
The ASCEND library provides for generic &#039;stream&#039; types those of which could also be used for representing the stream at the canvas level. But there are several things that need to taken care of before something like that could be done. Some notes:&lt;br /&gt;
*The &#039;stream&#039; types are parametric, although we can support parametric stream (maybe, not yet proven) John feels that doing so we would not be able to use ATS inside our block types, that gives rise to the problem of redundant equations (which mostly goes away once if we use ATS). On the other hand many of commercial modelers use special schemes to remove redundant equations, we could also do that (that is just a speculation, we have no proof how we could do that).&lt;br /&gt;
*Using parametric blocks does give us a upper hand on handling parameters, (as John says) the ascend API reveals a lot more information about the parameters we pass. This would be better than our current nots based approach.&lt;br /&gt;
*Specifying streams requires &#039;sets&#039; to be defined, we might just require to use ARRAY types which can be defined on &#039;sets&#039;, but currently we have no way of identifying array types in our block models, not even through annotations. Some sort of &#039;hack&#039; can work though, but I am just saying.&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now.&lt;br /&gt;
&lt;br /&gt;
*To have highlighting of connectible ports while connecting two ports we need to:&lt;br /&gt;
*#Find all suitable (IN/OUT/BOTH) ports available for connection.&lt;br /&gt;
*#Create a set their Types.&lt;br /&gt;
*#Check connect-ability for each of those types.&lt;br /&gt;
*#Highlight only the connectible ones.&lt;br /&gt;
&lt;br /&gt;
*To give a set of units that can be selected from a drop down menu in block properties:&lt;br /&gt;
*#Scan for the Type of the parameter.&lt;br /&gt;
*#Get the dimensions of the type.&lt;br /&gt;
*#Scan for the units available. &lt;br /&gt;
&lt;br /&gt;
*Implementation&lt;br /&gt;
**Some testing has been done of the functions, see &amp;lt;code&amp;gt;test_type_info()&amp;lt;/code&amp;gt; function inside /compiler/test/test_basics.c&lt;br /&gt;
**The test can be run on any file, using &amp;lt;code&amp;gt;scons test &amp;amp;&amp;amp; test/test compiler_basics.type_info&amp;lt;/code&amp;gt;&lt;br /&gt;
**From the observations, it is clear that the function &amp;lt;code&amp;gt;GetChildList()&amp;lt;/code&amp;gt; works as it should in case of all user generated foreseeable canvas models.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Weekly Reports GSOC 2011==&lt;br /&gt;
&lt;br /&gt;
The weekly reports will be filed here.&lt;br /&gt;
&lt;br /&gt;
====Week 0====&lt;br /&gt;
23th-May-11 to 29th-May-11&lt;br /&gt;
*Necessary changes for libavoid bindings.&lt;br /&gt;
**Still needs some work on the connection mechanism.&lt;br /&gt;
&lt;br /&gt;
====Week 1====&lt;br /&gt;
30th-May-11 to 5th-June-11&lt;br /&gt;
&lt;br /&gt;
====Week 2====&lt;br /&gt;
6th-June-11 to 12th-June-11&lt;br /&gt;
*Some progress towards having methods to set the default values. {{changeset|3474}}&lt;br /&gt;
*Some unusual behavior while updating to use of SWIG 2, some quick fixes. {{changeset|3482}}&lt;br /&gt;
*Some work towards getting stream into the canvas.&lt;br /&gt;
&lt;br /&gt;
====Week 3====&lt;br /&gt;
13th-June-11 to 19th-June-11&lt;br /&gt;
&lt;br /&gt;
Goals:&lt;br /&gt;
*Set up some mechanism of setting of default values.&lt;br /&gt;
*Get implementation ideas on setting up of globals and streams on the canvas. Possibly begin some work on them.&lt;br /&gt;
&lt;br /&gt;
====Week 4====&lt;br /&gt;
20th-June-11 to 26th-June-11&lt;br /&gt;
*Stream MODEL&#039;s recognized by canvas as globals.&lt;br /&gt;
*User can set streams to blocks.&lt;br /&gt;
*From some implementation there for the streams, through discussions it was found that for a very appropriate solution to the issue of streams, streams with variable components has to be taken into account.&lt;br /&gt;
*Spent the weekend on reading the complete models developed by Art on the Hydrogen cycles, which has a set based implementation of streams.&lt;br /&gt;
&lt;br /&gt;
====Week 5====&lt;br /&gt;
27th-June-11 to 3th-July-11&lt;br /&gt;
&lt;br /&gt;
Still struggling with the stream implementation, will do the complete update in a few days time.&lt;br /&gt;
*Writing a new version of Rankine cycle blocks for canvas using the &#039;stream&#039; component defined in the models/stream_holdup.a4l&lt;br /&gt;
*Some success, but still not being able to solve the generated model.&lt;br /&gt;
*Basically in canvas we will have a global &#039;stream&#039; whose properties can be edited using a GUI tool, that particular stream will hold the secrets to the rankine cycle being modeled, each block will use that stream as input and output. Equations inside the block will govern the relation between the output and the input.&lt;br /&gt;
&lt;br /&gt;
====Week 6====&lt;br /&gt;
4th-July-11 to 10th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 7====&lt;br /&gt;
11th-July-11 to 17th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 8====&lt;br /&gt;
18th-July-11 to 24th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 9====&lt;br /&gt;
25th-July-11 to 31st-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 10====&lt;br /&gt;
1st-August-11 to 7th-August-11&lt;br /&gt;
&lt;br /&gt;
====Week 11====&lt;br /&gt;
8th-August-11 to 15th-August-11&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=User:Grivan&amp;diff=2878</id>
		<title>User:Grivan</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=User:Grivan&amp;diff=2878"/>
		<updated>2011-07-15T15:04:42Z</updated>

		<summary type="html">&lt;p&gt;Grivan: /* Progress */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;&#039;Grivan Thapar&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Subversion Branch {{srcbranchdir|grivan|}} and {{srcbranchdir|grivan2|}}&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Current Work=&lt;br /&gt;
===Canvas===&lt;br /&gt;
===Goals===&lt;br /&gt;
====Parameter Handling====&lt;br /&gt;
There seems a possibility of using the NOTES and METHODS together to allow a suitable design solution to parameter handling.&lt;br /&gt;
&lt;br /&gt;
Using NOTES to make distinction between the parameters:&lt;br /&gt;
*How to best organize the parameters, required, standard etc&lt;br /&gt;
*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 &#039;front end&#039; for displaying the parameters&lt;br /&gt;
*There would be some changes in the BlockType class, but that would be easy.&lt;br /&gt;
&lt;br /&gt;
Using default METHODS for scaling and specifying default values for parameters:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 METHOD canvas_default;&lt;br /&gt;
  RUN pump1.default_self;&lt;br /&gt;
  RUN condenser1.default_self;&lt;br /&gt;
 END canvas_default;&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Here the &amp;lt;code&amp;gt;pump1.default_self&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;condenser1.default_self&amp;lt;/code&amp;gt; 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.&lt;br /&gt;
&lt;br /&gt;
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:&lt;br /&gt;
&lt;br /&gt;
*How to use both the default methods and the parameter tab in blockproperties?&lt;br /&gt;
*What if the user selects the a default method and also fixes a parameter separately?&lt;br /&gt;
*What if the default method fails in some different configuration of a canvas model?&lt;br /&gt;
*What if something we have set as required can also be solved for?&lt;br /&gt;
&lt;br /&gt;
Using the two above things together will let us into hopefully a good design solution for the parameters.&lt;br /&gt;
&lt;br /&gt;
====Solving Process====&lt;br /&gt;
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.&lt;br /&gt;
*Have to deal with the &#039;instances&#039; 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.&lt;br /&gt;
*Checks for unconnected ports and line connectors.&lt;br /&gt;
*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).&lt;br /&gt;
&lt;br /&gt;
====Other Tasks====&lt;br /&gt;
#Set up canvas to use the new libavoid bindings. Although could be done before, in case the libavoid bindings are completed.&lt;br /&gt;
#For Undo need to look for better method for segregating transactions, only some more tweaking should be necessary.&lt;br /&gt;
#We have&#039;t applied proper Type checking, its just the string names that are being compared, we could use much earlier Ben&#039;s suggestion of having a GUI policy that supports Type checking at the ASCEND level.&lt;br /&gt;
#User defined shapes of the &#039;blocks&#039;, this was proposed last year but not completed, we will have to take care though of libavoid limitations here though.&lt;br /&gt;
#Other smaller GUI improvements, embedding the Canvas into main GUI, more model libraries etc.&lt;br /&gt;
===Progress===&lt;br /&gt;
*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.&lt;br /&gt;
*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.&lt;br /&gt;
*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.&lt;br /&gt;
*Some work on bugs, {{changeset|3482}} and {{changeset|3513}}.&lt;br /&gt;
&lt;br /&gt;
=Past Work=&lt;br /&gt;
&lt;br /&gt;
==GSoC 2010 Participation==&lt;br /&gt;
GSoC 2010 Proposal: [http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/ascend/t127230757715 Improvement on Canvas-based modelling for Ascend] &amp;lt;br&amp;gt; See [[Canvas-based modeller for ASCEND]] for more information.&lt;br /&gt;
&amp;lt;br&amp;gt;Mentor: [[John Pye]]&lt;br /&gt;
&lt;br /&gt;
=== Goals ===&lt;br /&gt;
&lt;br /&gt;
Improvement on Canvas-based modeling:&lt;br /&gt;
* Updating the graphical flow sheet modeler.&lt;br /&gt;
* Enhancing its usability and functionality.&lt;br /&gt;
* Making it more robust.&lt;br /&gt;
&lt;br /&gt;
=== Tasks ===&lt;br /&gt;
&lt;br /&gt;
* Initially before coding address the necessary prerequisites that I will discuss with the Ascend team and have solutions ready to be implemented as follows;&lt;br /&gt;
* 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.&lt;br /&gt;
* Solution of the redundant equations in case of equality loops. The current method of &#039;Methods&#039; be either modified or updated, for easy debugging of the models.&lt;br /&gt;
* To specify the &#039;global&#039; variables for generic models, like streams in a turbine. Every such &#039;general&#039; 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.&lt;br /&gt;
* 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.&lt;br /&gt;
* Define a set number of generic models that could added so that using Ascend Canvas based modeler becomes a head-start process.&lt;br /&gt;
* 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.&lt;br /&gt;
&lt;br /&gt;
By mid-term review:&lt;br /&gt;
* 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.&lt;br /&gt;
* Do the GUI usability improvements. Undo, Redo, Save image etc.&lt;br /&gt;
* Code for a suitable framework for importing new models into the pallet from a specified location.&lt;br /&gt;
* Code for the solution of the type checking problem.&lt;br /&gt;
* Unit tests of features implemented.&lt;br /&gt;
* Start to code for defining the global variables for each of the generic block sub-model.&lt;br /&gt;
&lt;br /&gt;
By final-term review:&lt;br /&gt;
* Complete the code for setting the global variables for generic models.&lt;br /&gt;
* Code for efficient debugging of models with closed circulation loops.&lt;br /&gt;
* Code for the type checking.&lt;br /&gt;
* Unit tests of features implemented.&lt;br /&gt;
* Add new blocks of models.&lt;br /&gt;
* Final testing of the code, final integration to the /trunk code, documentation.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
[[Category:GSOC2010]]&lt;br /&gt;
[[Category:GSOC2011]]&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=User:Grivan&amp;diff=2877</id>
		<title>User:Grivan</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=User:Grivan&amp;diff=2877"/>
		<updated>2011-07-15T15:00:33Z</updated>

		<summary type="html">&lt;p&gt;Grivan: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;&#039;Grivan Thapar&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Subversion Branch {{srcbranchdir|grivan|}} and {{srcbranchdir|grivan2|}}&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Current Work=&lt;br /&gt;
===Canvas===&lt;br /&gt;
===Goals===&lt;br /&gt;
====Parameter Handling====&lt;br /&gt;
There seems a possibility of using the NOTES and METHODS together to allow a suitable design solution to parameter handling.&lt;br /&gt;
&lt;br /&gt;
Using NOTES to make distinction between the parameters:&lt;br /&gt;
*How to best organize the parameters, required, standard etc&lt;br /&gt;
*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 &#039;front end&#039; for displaying the parameters&lt;br /&gt;
*There would be some changes in the BlockType class, but that would be easy.&lt;br /&gt;
&lt;br /&gt;
Using default METHODS for scaling and specifying default values for parameters:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 METHOD canvas_default;&lt;br /&gt;
  RUN pump1.default_self;&lt;br /&gt;
  RUN condenser1.default_self;&lt;br /&gt;
 END canvas_default;&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Here the &amp;lt;code&amp;gt;pump1.default_self&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;condenser1.default_self&amp;lt;/code&amp;gt; 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.&lt;br /&gt;
&lt;br /&gt;
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:&lt;br /&gt;
&lt;br /&gt;
*How to use both the default methods and the parameter tab in blockproperties?&lt;br /&gt;
*What if the user selects the a default method and also fixes a parameter separately?&lt;br /&gt;
*What if the default method fails in some different configuration of a canvas model?&lt;br /&gt;
*What if something we have set as required can also be solved for?&lt;br /&gt;
&lt;br /&gt;
Using the two above things together will let us into hopefully a good design solution for the parameters.&lt;br /&gt;
&lt;br /&gt;
====Solving Process====&lt;br /&gt;
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.&lt;br /&gt;
*Have to deal with the &#039;instances&#039; 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.&lt;br /&gt;
*Checks for unconnected ports and line connectors.&lt;br /&gt;
*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).&lt;br /&gt;
&lt;br /&gt;
====Other Tasks====&lt;br /&gt;
#Set up canvas to use the new libavoid bindings. Although could be done before, in case the libavoid bindings are completed.&lt;br /&gt;
#For Undo need to look for better method for segregating transactions, only some more tweaking should be necessary.&lt;br /&gt;
#We have&#039;t applied proper Type checking, its just the string names that are being compared, we could use much earlier Ben&#039;s suggestion of having a GUI policy that supports Type checking at the ASCEND level.&lt;br /&gt;
#User defined shapes of the &#039;blocks&#039;, this was proposed last year but not completed, we will have to take care though of libavoid limitations here though.&lt;br /&gt;
#Other smaller GUI improvements, embedding the Canvas into main GUI, more model libraries etc.&lt;br /&gt;
===Progress===&lt;br /&gt;
*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.&lt;br /&gt;
*The need for support of liquid mixtures and support for true streams, support of streams as defined in streams.a4l was needed. 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.&lt;br /&gt;
*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.&lt;br /&gt;
*Some work on bugs, {{changeset|3482}} and {{changeset|3513}}.&lt;br /&gt;
&lt;br /&gt;
=Past Work=&lt;br /&gt;
&lt;br /&gt;
==GSoC 2010 Participation==&lt;br /&gt;
GSoC 2010 Proposal: [http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/ascend/t127230757715 Improvement on Canvas-based modelling for Ascend] &amp;lt;br&amp;gt; See [[Canvas-based modeller for ASCEND]] for more information.&lt;br /&gt;
&amp;lt;br&amp;gt;Mentor: [[John Pye]]&lt;br /&gt;
&lt;br /&gt;
=== Goals ===&lt;br /&gt;
&lt;br /&gt;
Improvement on Canvas-based modeling:&lt;br /&gt;
* Updating the graphical flow sheet modeler.&lt;br /&gt;
* Enhancing its usability and functionality.&lt;br /&gt;
* Making it more robust.&lt;br /&gt;
&lt;br /&gt;
=== Tasks ===&lt;br /&gt;
&lt;br /&gt;
* Initially before coding address the necessary prerequisites that I will discuss with the Ascend team and have solutions ready to be implemented as follows;&lt;br /&gt;
* 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.&lt;br /&gt;
* Solution of the redundant equations in case of equality loops. The current method of &#039;Methods&#039; be either modified or updated, for easy debugging of the models.&lt;br /&gt;
* To specify the &#039;global&#039; variables for generic models, like streams in a turbine. Every such &#039;general&#039; 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.&lt;br /&gt;
* 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.&lt;br /&gt;
* Define a set number of generic models that could added so that using Ascend Canvas based modeler becomes a head-start process.&lt;br /&gt;
* 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.&lt;br /&gt;
&lt;br /&gt;
By mid-term review:&lt;br /&gt;
* 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.&lt;br /&gt;
* Do the GUI usability improvements. Undo, Redo, Save image etc.&lt;br /&gt;
* Code for a suitable framework for importing new models into the pallet from a specified location.&lt;br /&gt;
* Code for the solution of the type checking problem.&lt;br /&gt;
* Unit tests of features implemented.&lt;br /&gt;
* Start to code for defining the global variables for each of the generic block sub-model.&lt;br /&gt;
&lt;br /&gt;
By final-term review:&lt;br /&gt;
* Complete the code for setting the global variables for generic models.&lt;br /&gt;
* Code for efficient debugging of models with closed circulation loops.&lt;br /&gt;
* Code for the type checking.&lt;br /&gt;
* Unit tests of features implemented.&lt;br /&gt;
* Add new blocks of models.&lt;br /&gt;
* Final testing of the code, final integration to the /trunk code, documentation.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
[[Category:GSOC2010]]&lt;br /&gt;
[[Category:GSOC2011]]&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=User:Grivan&amp;diff=2876</id>
		<title>User:Grivan</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=User:Grivan&amp;diff=2876"/>
		<updated>2011-07-15T15:00:13Z</updated>

		<summary type="html">&lt;p&gt;Grivan: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;&#039;Grivan Thapar&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Subversion Branch {{srcbranchdir|grivan|}} and {{srcbranchdir|grivan2|}}&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Current Work=&lt;br /&gt;
===Canvas===&lt;br /&gt;
===Goals====&lt;br /&gt;
====Parameter Handling====&lt;br /&gt;
There seems a possibility of using the NOTES and METHODS together to allow a suitable design solution to parameter handling.&lt;br /&gt;
&lt;br /&gt;
Using NOTES to make distinction between the parameters:&lt;br /&gt;
*How to best organize the parameters, required, standard etc&lt;br /&gt;
*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 &#039;front end&#039; for displaying the parameters&lt;br /&gt;
*There would be some changes in the BlockType class, but that would be easy.&lt;br /&gt;
&lt;br /&gt;
Using default METHODS for scaling and specifying default values for parameters:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 METHOD canvas_default;&lt;br /&gt;
  RUN pump1.default_self;&lt;br /&gt;
  RUN condenser1.default_self;&lt;br /&gt;
 END canvas_default;&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Here the &amp;lt;code&amp;gt;pump1.default_self&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;condenser1.default_self&amp;lt;/code&amp;gt; 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.&lt;br /&gt;
&lt;br /&gt;
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:&lt;br /&gt;
&lt;br /&gt;
*How to use both the default methods and the parameter tab in blockproperties?&lt;br /&gt;
*What if the user selects the a default method and also fixes a parameter separately?&lt;br /&gt;
*What if the default method fails in some different configuration of a canvas model?&lt;br /&gt;
*What if something we have set as required can also be solved for?&lt;br /&gt;
&lt;br /&gt;
Using the two above things together will let us into hopefully a good design solution for the parameters.&lt;br /&gt;
&lt;br /&gt;
====Solving Process====&lt;br /&gt;
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.&lt;br /&gt;
*Have to deal with the &#039;instances&#039; 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.&lt;br /&gt;
*Checks for unconnected ports and line connectors.&lt;br /&gt;
*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).&lt;br /&gt;
&lt;br /&gt;
====Other Tasks====&lt;br /&gt;
#Set up canvas to use the new libavoid bindings. Although could be done before, in case the libavoid bindings are completed.&lt;br /&gt;
#For Undo need to look for better method for segregating transactions, only some more tweaking should be necessary.&lt;br /&gt;
#We have&#039;t applied proper Type checking, its just the string names that are being compared, we could use much earlier Ben&#039;s suggestion of having a GUI policy that supports Type checking at the ASCEND level.&lt;br /&gt;
#User defined shapes of the &#039;blocks&#039;, this was proposed last year but not completed, we will have to take care though of libavoid limitations here though.&lt;br /&gt;
#Other smaller GUI improvements, embedding the Canvas into main GUI, more model libraries etc.&lt;br /&gt;
===Progress===&lt;br /&gt;
*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.&lt;br /&gt;
*The need for support of liquid mixtures and support for true streams, support of streams as defined in streams.a4l was needed. 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.&lt;br /&gt;
*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.&lt;br /&gt;
*Some work on bugs, {{changeset|3482}} and {{changeset|3513}}.&lt;br /&gt;
&lt;br /&gt;
=Past Work=&lt;br /&gt;
&lt;br /&gt;
==GSoC 2010 Participation==&lt;br /&gt;
GSoC 2010 Proposal: [http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/ascend/t127230757715 Improvement on Canvas-based modelling for Ascend] &amp;lt;br&amp;gt; See [[Canvas-based modeller for ASCEND]] for more information.&lt;br /&gt;
&amp;lt;br&amp;gt;Mentor: [[John Pye]]&lt;br /&gt;
&lt;br /&gt;
=== Goals ===&lt;br /&gt;
&lt;br /&gt;
Improvement on Canvas-based modeling:&lt;br /&gt;
* Updating the graphical flow sheet modeler.&lt;br /&gt;
* Enhancing its usability and functionality.&lt;br /&gt;
* Making it more robust.&lt;br /&gt;
&lt;br /&gt;
=== Tasks ===&lt;br /&gt;
&lt;br /&gt;
* Initially before coding address the necessary prerequisites that I will discuss with the Ascend team and have solutions ready to be implemented as follows;&lt;br /&gt;
* 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.&lt;br /&gt;
* Solution of the redundant equations in case of equality loops. The current method of &#039;Methods&#039; be either modified or updated, for easy debugging of the models.&lt;br /&gt;
* To specify the &#039;global&#039; variables for generic models, like streams in a turbine. Every such &#039;general&#039; 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.&lt;br /&gt;
* 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.&lt;br /&gt;
* Define a set number of generic models that could added so that using Ascend Canvas based modeler becomes a head-start process.&lt;br /&gt;
* 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.&lt;br /&gt;
&lt;br /&gt;
By mid-term review:&lt;br /&gt;
* 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.&lt;br /&gt;
* Do the GUI usability improvements. Undo, Redo, Save image etc.&lt;br /&gt;
* Code for a suitable framework for importing new models into the pallet from a specified location.&lt;br /&gt;
* Code for the solution of the type checking problem.&lt;br /&gt;
* Unit tests of features implemented.&lt;br /&gt;
* Start to code for defining the global variables for each of the generic block sub-model.&lt;br /&gt;
&lt;br /&gt;
By final-term review:&lt;br /&gt;
* Complete the code for setting the global variables for generic models.&lt;br /&gt;
* Code for efficient debugging of models with closed circulation loops.&lt;br /&gt;
* Code for the type checking.&lt;br /&gt;
* Unit tests of features implemented.&lt;br /&gt;
* Add new blocks of models.&lt;br /&gt;
* Final testing of the code, final integration to the /trunk code, documentation.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
[[Category:GSOC2010]]&lt;br /&gt;
[[Category:GSOC2011]]&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=User:Grivan&amp;diff=2875</id>
		<title>User:Grivan</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=User:Grivan&amp;diff=2875"/>
		<updated>2011-07-15T14:59:10Z</updated>

		<summary type="html">&lt;p&gt;Grivan: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;&#039;Grivan Thapar&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Subversion Branch {{srcbranchdir|grivan|}} and {{srcbranchdir|grivan2|}}&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Current Work=&lt;br /&gt;
===Canvas===&lt;br /&gt;
===Goals====&lt;br /&gt;
====Parameter Handling===&lt;br /&gt;
There seems a possibility of using the NOTES and METHODS together to allow a suitable design solution to parameter handling.&lt;br /&gt;
&lt;br /&gt;
Using NOTES to make distinction between the parameters:&lt;br /&gt;
*How to best organize the parameters, required, standard etc&lt;br /&gt;
*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 &#039;front end&#039; for displaying the parameters&lt;br /&gt;
*There would be some changes in the BlockType class, but that would be easy.&lt;br /&gt;
&lt;br /&gt;
Using default METHODS for scaling and specifying default values for parameters:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 METHOD canvas_default;&lt;br /&gt;
  RUN pump1.default_self;&lt;br /&gt;
  RUN condenser1.default_self;&lt;br /&gt;
 END canvas_default;&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Here the &amp;lt;code&amp;gt;pump1.default_self&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;condenser1.default_self&amp;lt;/code&amp;gt; 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.&lt;br /&gt;
&lt;br /&gt;
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:&lt;br /&gt;
&lt;br /&gt;
*How to use both the default methods and the parameter tab in blockproperties?&lt;br /&gt;
*What if the user selects the a default method and also fixes a parameter separately?&lt;br /&gt;
*What if the default method fails in some different configuration of a canvas model?&lt;br /&gt;
*What if something we have set as required can also be solved for?&lt;br /&gt;
&lt;br /&gt;
Using the two above things together will let us into hopefully a good design solution for the parameters.&lt;br /&gt;
&lt;br /&gt;
====Solving Process====&lt;br /&gt;
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.&lt;br /&gt;
*Have to deal with the &#039;instances&#039; 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.&lt;br /&gt;
*Checks for unconnected ports and line connectors.&lt;br /&gt;
*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).&lt;br /&gt;
&lt;br /&gt;
====Other Tasks====&lt;br /&gt;
#Set up canvas to use the new libavoid bindings. Although could be done before, in case the libavoid bindings are completed.&lt;br /&gt;
#For Undo need to look for better method for segregating transactions, only some more tweaking should be necessary.&lt;br /&gt;
#We have&#039;t applied proper Type checking, its just the string names that are being compared, we could use much earlier Ben&#039;s suggestion of having a GUI policy that supports Type checking at the ASCEND level.&lt;br /&gt;
#User defined shapes of the &#039;blocks&#039;, this was proposed last year but not completed, we will have to take care though of libavoid limitations here though.&lt;br /&gt;
#Other smaller GUI improvements, embedding the Canvas into main GUI, more model libraries etc.&lt;br /&gt;
===Progress===&lt;br /&gt;
*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.&lt;br /&gt;
*The need for support of liquid mixtures and support for true streams, support of streams as defined in streams.a4l was needed. 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.&lt;br /&gt;
*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.&lt;br /&gt;
*Some work on bugs, {{changeset|3482}} and {{changeset|3513}}.&lt;br /&gt;
&lt;br /&gt;
=Past Work=&lt;br /&gt;
&lt;br /&gt;
==GSoC 2010 Participation==&lt;br /&gt;
GSoC 2010 Proposal: [http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/ascend/t127230757715 Improvement on Canvas-based modelling for Ascend] &amp;lt;br&amp;gt; See [[Canvas-based modeller for ASCEND]] for more information.&lt;br /&gt;
&amp;lt;br&amp;gt;Mentor: [[John Pye]]&lt;br /&gt;
&lt;br /&gt;
=== Goals ===&lt;br /&gt;
&lt;br /&gt;
Improvement on Canvas-based modeling:&lt;br /&gt;
* Updating the graphical flow sheet modeler.&lt;br /&gt;
* Enhancing its usability and functionality.&lt;br /&gt;
* Making it more robust.&lt;br /&gt;
&lt;br /&gt;
=== Tasks ===&lt;br /&gt;
&lt;br /&gt;
* Initially before coding address the necessary prerequisites that I will discuss with the Ascend team and have solutions ready to be implemented as follows;&lt;br /&gt;
* 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.&lt;br /&gt;
* Solution of the redundant equations in case of equality loops. The current method of &#039;Methods&#039; be either modified or updated, for easy debugging of the models.&lt;br /&gt;
* To specify the &#039;global&#039; variables for generic models, like streams in a turbine. Every such &#039;general&#039; 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.&lt;br /&gt;
* 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.&lt;br /&gt;
* Define a set number of generic models that could added so that using Ascend Canvas based modeler becomes a head-start process.&lt;br /&gt;
* 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.&lt;br /&gt;
&lt;br /&gt;
By mid-term review:&lt;br /&gt;
* 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.&lt;br /&gt;
* Do the GUI usability improvements. Undo, Redo, Save image etc.&lt;br /&gt;
* Code for a suitable framework for importing new models into the pallet from a specified location.&lt;br /&gt;
* Code for the solution of the type checking problem.&lt;br /&gt;
* Unit tests of features implemented.&lt;br /&gt;
* Start to code for defining the global variables for each of the generic block sub-model.&lt;br /&gt;
&lt;br /&gt;
By final-term review:&lt;br /&gt;
* Complete the code for setting the global variables for generic models.&lt;br /&gt;
* Code for efficient debugging of models with closed circulation loops.&lt;br /&gt;
* Code for the type checking.&lt;br /&gt;
* Unit tests of features implemented.&lt;br /&gt;
* Add new blocks of models.&lt;br /&gt;
* Final testing of the code, final integration to the /trunk code, documentation.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
[[Category:GSOC2010]]&lt;br /&gt;
[[Category:GSOC2011]]&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2774</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2774"/>
		<updated>2011-07-03T18:41:29Z</updated>

		<summary type="html">&lt;p&gt;Grivan: /* Week 5 */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 and current development carried out by [[Grivan Thapar]]. The goals and tasks for the GSoC period are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. The concerns are right now at setting up better mechanisms for parameter handling and design enhancements like handling of stream objects, globals etc.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
TODO : Add more ideas, put a concrete solution overview to each Case. Add new use cases based upon electronic circuit models sent over by [[Divyanshu Bandil|Divyanshu]].&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
*Global Model equations.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
*Block rotation.&lt;br /&gt;
*:It would be nice if blocks could be rotated, it makes the canvas look more tidy.&lt;br /&gt;
*Other Issues.&lt;br /&gt;
*:Just specifying a value and not Fixing it. Should it be possible? &lt;br /&gt;
*: How to make additions of equations to the MODEL more intuitive.&lt;br /&gt;
&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}} (NOTE: see also {{src|models/johnpye/fprops/rankine_fprops.a4c}} for newer version using [[FPROPS]] instead of [[freesteam]] -- JP). We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece. In addition take care of the ALIASES keyword used in the text model. TODO&lt;br /&gt;
*Elimination of redundant equations in closed loop flows.&lt;br /&gt;
*:Multiple loops present in the system.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Still needs to be discussed. TODO&lt;br /&gt;
*Specifications of flow streams. &lt;br /&gt;
*:It should be possible to switch between stream components, water to CO2 to toluene for example.&lt;br /&gt;
*:This however should &#039;&#039;&#039;not&#039;&#039;&#039; involve redrawing the whole model again.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Streams can be defined in the canvas by selecting the particular connections and specifying the stream component, the connections to these components at the ports must use the values of stream component provided. TODO&lt;br /&gt;
*Providing complex flow streams.&lt;br /&gt;
*:A regenerative cycle requires to specify the fraction of steam extracted at the &#039;&#039;bled&#039;&#039; point, that is a TEE in our sense. Such a fraction must be supplied by the user while making such connections. Assuming an open feedwater scheme.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; This should be easy as a simple TEE component must have a fixable variable &#039;fraction&#039;.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*In this case connections may need to be manually specified in order to provide complex flows as required.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious.&lt;br /&gt;
**For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling of Servo Motor with backlash and PID control===&lt;br /&gt;
*TODO : Add description&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The new Gapahs 0.7.2 release till now seems to work fine.&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head 0.7.1. &lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
TODO : Keep adding details&lt;br /&gt;
&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
==Improvements on the Solving Process==&lt;br /&gt;
Since we have no Type informations the solving is done primarily by first generating a string representation of the complete MODEL and then exported to the solver. This can lead to problems while trying to solve complex models requiring a large time to solve, because each time a variable is changed the complete model has to solved again. In case of PyGTK GUI we have a more powerful interaction with the solver and thus can change parameters without discarding the already solved model. The basic problem here lies in the fact that we don&#039;t instantiate the model first and then solve it.&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified. This provides and excellent way to have the same model provide simulation for any number of streams. Two implementations have to be taken care of to specify streams;&lt;br /&gt;
*GUI implementation:&lt;br /&gt;
*:This would provide a suitable GUI to select the stream.&lt;br /&gt;
*Application level implementation&lt;br /&gt;
*:This would add actual stream modifications to the block code.&lt;br /&gt;
The [[#Simple Rankine Cycle]] could be solved simply by connecting steam_port connectors. The {{src|models/johnpye/rankine.a4c}} uses Steam as the only modelling stream. This model needs to be evolved to use generic port types so that a better and more deep understanding is achieved in the problem of specifying flow streams.&lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now.&lt;br /&gt;
&lt;br /&gt;
*To have highlighting of connectible ports while connecting two ports we need to:&lt;br /&gt;
*#Find all suitable (IN/OUT/BOTH) ports available for connection.&lt;br /&gt;
*#Create a set their Types.&lt;br /&gt;
*#Check connect-ability for each of those types.&lt;br /&gt;
*#Highlight only the connectible ones.&lt;br /&gt;
&lt;br /&gt;
*To give a set of units that can be selected from a drop down menu in block properties:&lt;br /&gt;
*#Scan for the Type of the parameter.&lt;br /&gt;
*#Get the dimensions of the type.&lt;br /&gt;
*#Scan for the units available. &lt;br /&gt;
&lt;br /&gt;
*Implementation&lt;br /&gt;
**Some testing has been done of the functions, see &amp;lt;code&amp;gt;test_type_info()&amp;lt;/code&amp;gt; function inside /compiler/test/test_basics.c&lt;br /&gt;
**The test can be run on any file, using &amp;lt;code&amp;gt;scons test &amp;amp;&amp;amp; test/test compiler_basics.type_info&amp;lt;/code&amp;gt;&lt;br /&gt;
**From the observations, it is clear that the function &amp;lt;code&amp;gt;GetChildList()&amp;lt;/code&amp;gt; works as it should in case of all user generated foreseeable canvas models.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Weekly Reports GSOC 2011==&lt;br /&gt;
&lt;br /&gt;
The weekly reports will be filed here.&lt;br /&gt;
&lt;br /&gt;
====Week 0====&lt;br /&gt;
23th-May-11 to 29th-May-11&lt;br /&gt;
*Necessary changes for libavoid bindings.&lt;br /&gt;
**Still needs some work on the connection mechanism.&lt;br /&gt;
&lt;br /&gt;
====Week 1====&lt;br /&gt;
30th-May-11 to 5th-June-11&lt;br /&gt;
&lt;br /&gt;
====Week 2====&lt;br /&gt;
6th-June-11 to 12th-June-11&lt;br /&gt;
*Some progress towards having methods to set the default values. {{changeset|3474}}&lt;br /&gt;
*Some unusual behavior while updating to use of SWIG 2, some quick fixes. {{changeset|3482}}&lt;br /&gt;
*Some work towards getting stream into the canvas.&lt;br /&gt;
&lt;br /&gt;
====Week 3====&lt;br /&gt;
13th-June-11 to 19th-June-11&lt;br /&gt;
&lt;br /&gt;
Goals:&lt;br /&gt;
*Set up some mechanism of setting of default values.&lt;br /&gt;
*Get implementation ideas on setting up of globals and streams on the canvas. Possibly begin some work on them.&lt;br /&gt;
&lt;br /&gt;
====Week 4====&lt;br /&gt;
20th-June-11 to 26th-June-11&lt;br /&gt;
*Stream MODEL&#039;s recognized by canvas as globals.&lt;br /&gt;
*User can set streams to blocks.&lt;br /&gt;
*From some implementation there for the streams, through discussions it was found that for a very appropriate solution to the issue of streams, streams with variable components has to be taken into account.&lt;br /&gt;
*Spent the weekend on reading the complete models developed by Art on the Hydrogen cycles, which has a set based implementation of streams.&lt;br /&gt;
&lt;br /&gt;
====Week 5====&lt;br /&gt;
27th-June-11 to 3th-July-11&lt;br /&gt;
&lt;br /&gt;
Still struggling with the stream implementation, will do the complete update in a few days time.&lt;br /&gt;
*Writing a new version of Rankine cycle blocks for canvas using the &#039;stream&#039; component defined in the models/stream_holdup.a4l&lt;br /&gt;
*Some success, but still not being able to solve the generated model.&lt;br /&gt;
*Basically in canvas we will have a global &#039;stream&#039; whose properties can be edited using a GUI tool, that particular stream will hold the secrets to the rankine cycle being modeled, each block will use that stream as input and output. Equations inside the block will govern the relation between the output and the input.&lt;br /&gt;
&lt;br /&gt;
====Week 6====&lt;br /&gt;
4th-July-11 to 10th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 7====&lt;br /&gt;
11th-July-11 to 17th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 8====&lt;br /&gt;
18th-July-11 to 24th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 9====&lt;br /&gt;
25th-July-11 to 31st-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 10====&lt;br /&gt;
1st-August-11 to 7th-August-11&lt;br /&gt;
&lt;br /&gt;
====Week 11====&lt;br /&gt;
8th-August-11 to 15th-August-11&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2773</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2773"/>
		<updated>2011-07-03T18:41:12Z</updated>

		<summary type="html">&lt;p&gt;Grivan: /* Week 5 */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 and current development carried out by [[Grivan Thapar]]. The goals and tasks for the GSoC period are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. The concerns are right now at setting up better mechanisms for parameter handling and design enhancements like handling of stream objects, globals etc.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
TODO : Add more ideas, put a concrete solution overview to each Case. Add new use cases based upon electronic circuit models sent over by [[Divyanshu Bandil|Divyanshu]].&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
*Global Model equations.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
*Block rotation.&lt;br /&gt;
*:It would be nice if blocks could be rotated, it makes the canvas look more tidy.&lt;br /&gt;
*Other Issues.&lt;br /&gt;
*:Just specifying a value and not Fixing it. Should it be possible? &lt;br /&gt;
*: How to make additions of equations to the MODEL more intuitive.&lt;br /&gt;
&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}} (NOTE: see also {{src|models/johnpye/fprops/rankine_fprops.a4c}} for newer version using [[FPROPS]] instead of [[freesteam]] -- JP). We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece. In addition take care of the ALIASES keyword used in the text model. TODO&lt;br /&gt;
*Elimination of redundant equations in closed loop flows.&lt;br /&gt;
*:Multiple loops present in the system.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Still needs to be discussed. TODO&lt;br /&gt;
*Specifications of flow streams. &lt;br /&gt;
*:It should be possible to switch between stream components, water to CO2 to toluene for example.&lt;br /&gt;
*:This however should &#039;&#039;&#039;not&#039;&#039;&#039; involve redrawing the whole model again.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Streams can be defined in the canvas by selecting the particular connections and specifying the stream component, the connections to these components at the ports must use the values of stream component provided. TODO&lt;br /&gt;
*Providing complex flow streams.&lt;br /&gt;
*:A regenerative cycle requires to specify the fraction of steam extracted at the &#039;&#039;bled&#039;&#039; point, that is a TEE in our sense. Such a fraction must be supplied by the user while making such connections. Assuming an open feedwater scheme.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; This should be easy as a simple TEE component must have a fixable variable &#039;fraction&#039;.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*In this case connections may need to be manually specified in order to provide complex flows as required.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious.&lt;br /&gt;
**For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling of Servo Motor with backlash and PID control===&lt;br /&gt;
*TODO : Add description&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The new Gapahs 0.7.2 release till now seems to work fine.&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head 0.7.1. &lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
TODO : Keep adding details&lt;br /&gt;
&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
==Improvements on the Solving Process==&lt;br /&gt;
Since we have no Type informations the solving is done primarily by first generating a string representation of the complete MODEL and then exported to the solver. This can lead to problems while trying to solve complex models requiring a large time to solve, because each time a variable is changed the complete model has to solved again. In case of PyGTK GUI we have a more powerful interaction with the solver and thus can change parameters without discarding the already solved model. The basic problem here lies in the fact that we don&#039;t instantiate the model first and then solve it.&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified. This provides and excellent way to have the same model provide simulation for any number of streams. Two implementations have to be taken care of to specify streams;&lt;br /&gt;
*GUI implementation:&lt;br /&gt;
*:This would provide a suitable GUI to select the stream.&lt;br /&gt;
*Application level implementation&lt;br /&gt;
*:This would add actual stream modifications to the block code.&lt;br /&gt;
The [[#Simple Rankine Cycle]] could be solved simply by connecting steam_port connectors. The {{src|models/johnpye/rankine.a4c}} uses Steam as the only modelling stream. This model needs to be evolved to use generic port types so that a better and more deep understanding is achieved in the problem of specifying flow streams.&lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now.&lt;br /&gt;
&lt;br /&gt;
*To have highlighting of connectible ports while connecting two ports we need to:&lt;br /&gt;
*#Find all suitable (IN/OUT/BOTH) ports available for connection.&lt;br /&gt;
*#Create a set their Types.&lt;br /&gt;
*#Check connect-ability for each of those types.&lt;br /&gt;
*#Highlight only the connectible ones.&lt;br /&gt;
&lt;br /&gt;
*To give a set of units that can be selected from a drop down menu in block properties:&lt;br /&gt;
*#Scan for the Type of the parameter.&lt;br /&gt;
*#Get the dimensions of the type.&lt;br /&gt;
*#Scan for the units available. &lt;br /&gt;
&lt;br /&gt;
*Implementation&lt;br /&gt;
**Some testing has been done of the functions, see &amp;lt;code&amp;gt;test_type_info()&amp;lt;/code&amp;gt; function inside /compiler/test/test_basics.c&lt;br /&gt;
**The test can be run on any file, using &amp;lt;code&amp;gt;scons test &amp;amp;&amp;amp; test/test compiler_basics.type_info&amp;lt;/code&amp;gt;&lt;br /&gt;
**From the observations, it is clear that the function &amp;lt;code&amp;gt;GetChildList()&amp;lt;/code&amp;gt; works as it should in case of all user generated foreseeable canvas models.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Weekly Reports GSOC 2011==&lt;br /&gt;
&lt;br /&gt;
The weekly reports will be filed here.&lt;br /&gt;
&lt;br /&gt;
====Week 0====&lt;br /&gt;
23th-May-11 to 29th-May-11&lt;br /&gt;
*Necessary changes for libavoid bindings.&lt;br /&gt;
**Still needs some work on the connection mechanism.&lt;br /&gt;
&lt;br /&gt;
====Week 1====&lt;br /&gt;
30th-May-11 to 5th-June-11&lt;br /&gt;
&lt;br /&gt;
====Week 2====&lt;br /&gt;
6th-June-11 to 12th-June-11&lt;br /&gt;
*Some progress towards having methods to set the default values. {{changeset|3474}}&lt;br /&gt;
*Some unusual behavior while updating to use of SWIG 2, some quick fixes. {{changeset|3482}}&lt;br /&gt;
*Some work towards getting stream into the canvas.&lt;br /&gt;
&lt;br /&gt;
====Week 3====&lt;br /&gt;
13th-June-11 to 19th-June-11&lt;br /&gt;
&lt;br /&gt;
Goals:&lt;br /&gt;
*Set up some mechanism of setting of default values.&lt;br /&gt;
*Get implementation ideas on setting up of globals and streams on the canvas. Possibly begin some work on them.&lt;br /&gt;
&lt;br /&gt;
====Week 4====&lt;br /&gt;
20th-June-11 to 26th-June-11&lt;br /&gt;
*Stream MODEL&#039;s recognized by canvas as globals.&lt;br /&gt;
*User can set streams to blocks.&lt;br /&gt;
*From some implementation there for the streams, through discussions it was found that for a very appropriate solution to the issue of streams, streams with variable components has to be taken into account.&lt;br /&gt;
*Spent the weekend on reading the complete models developed by Art on the Hydrogen cycles, which has a set based implementation of streams.&lt;br /&gt;
&lt;br /&gt;
====Week 5====&lt;br /&gt;
27th-June-11 to 3th-July-11&lt;br /&gt;
&amp;lt;/n&amp;gt;Still struggling with the stream implementation, will do the complete update in a few days time.&lt;br /&gt;
*Writing a new version of Rankine cycle blocks for canvas using the &#039;stream&#039; component defined in the models/stream_holdup.a4l&lt;br /&gt;
*Some success, but still not being able to solve the generated model.&lt;br /&gt;
*Basically in canvas we will have a global &#039;stream&#039; whose properties can be edited using a GUI tool, that particular stream will hold the secrets to the rankine cycle being modeled, each block will use that stream as input and output. Equations inside the block will govern the relation between the output and the input.&lt;br /&gt;
&lt;br /&gt;
====Week 6====&lt;br /&gt;
4th-July-11 to 10th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 7====&lt;br /&gt;
11th-July-11 to 17th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 8====&lt;br /&gt;
18th-July-11 to 24th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 9====&lt;br /&gt;
25th-July-11 to 31st-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 10====&lt;br /&gt;
1st-August-11 to 7th-August-11&lt;br /&gt;
&lt;br /&gt;
====Week 11====&lt;br /&gt;
8th-August-11 to 15th-August-11&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2772</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2772"/>
		<updated>2011-07-03T18:40:57Z</updated>

		<summary type="html">&lt;p&gt;Grivan: /* Week 5 */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 and current development carried out by [[Grivan Thapar]]. The goals and tasks for the GSoC period are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. The concerns are right now at setting up better mechanisms for parameter handling and design enhancements like handling of stream objects, globals etc.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
TODO : Add more ideas, put a concrete solution overview to each Case. Add new use cases based upon electronic circuit models sent over by [[Divyanshu Bandil|Divyanshu]].&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
*Global Model equations.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
*Block rotation.&lt;br /&gt;
*:It would be nice if blocks could be rotated, it makes the canvas look more tidy.&lt;br /&gt;
*Other Issues.&lt;br /&gt;
*:Just specifying a value and not Fixing it. Should it be possible? &lt;br /&gt;
*: How to make additions of equations to the MODEL more intuitive.&lt;br /&gt;
&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}} (NOTE: see also {{src|models/johnpye/fprops/rankine_fprops.a4c}} for newer version using [[FPROPS]] instead of [[freesteam]] -- JP). We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece. In addition take care of the ALIASES keyword used in the text model. TODO&lt;br /&gt;
*Elimination of redundant equations in closed loop flows.&lt;br /&gt;
*:Multiple loops present in the system.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Still needs to be discussed. TODO&lt;br /&gt;
*Specifications of flow streams. &lt;br /&gt;
*:It should be possible to switch between stream components, water to CO2 to toluene for example.&lt;br /&gt;
*:This however should &#039;&#039;&#039;not&#039;&#039;&#039; involve redrawing the whole model again.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Streams can be defined in the canvas by selecting the particular connections and specifying the stream component, the connections to these components at the ports must use the values of stream component provided. TODO&lt;br /&gt;
*Providing complex flow streams.&lt;br /&gt;
*:A regenerative cycle requires to specify the fraction of steam extracted at the &#039;&#039;bled&#039;&#039; point, that is a TEE in our sense. Such a fraction must be supplied by the user while making such connections. Assuming an open feedwater scheme.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; This should be easy as a simple TEE component must have a fixable variable &#039;fraction&#039;.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*In this case connections may need to be manually specified in order to provide complex flows as required.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious.&lt;br /&gt;
**For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling of Servo Motor with backlash and PID control===&lt;br /&gt;
*TODO : Add description&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The new Gapahs 0.7.2 release till now seems to work fine.&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head 0.7.1. &lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
TODO : Keep adding details&lt;br /&gt;
&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
==Improvements on the Solving Process==&lt;br /&gt;
Since we have no Type informations the solving is done primarily by first generating a string representation of the complete MODEL and then exported to the solver. This can lead to problems while trying to solve complex models requiring a large time to solve, because each time a variable is changed the complete model has to solved again. In case of PyGTK GUI we have a more powerful interaction with the solver and thus can change parameters without discarding the already solved model. The basic problem here lies in the fact that we don&#039;t instantiate the model first and then solve it.&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified. This provides and excellent way to have the same model provide simulation for any number of streams. Two implementations have to be taken care of to specify streams;&lt;br /&gt;
*GUI implementation:&lt;br /&gt;
*:This would provide a suitable GUI to select the stream.&lt;br /&gt;
*Application level implementation&lt;br /&gt;
*:This would add actual stream modifications to the block code.&lt;br /&gt;
The [[#Simple Rankine Cycle]] could be solved simply by connecting steam_port connectors. The {{src|models/johnpye/rankine.a4c}} uses Steam as the only modelling stream. This model needs to be evolved to use generic port types so that a better and more deep understanding is achieved in the problem of specifying flow streams.&lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now.&lt;br /&gt;
&lt;br /&gt;
*To have highlighting of connectible ports while connecting two ports we need to:&lt;br /&gt;
*#Find all suitable (IN/OUT/BOTH) ports available for connection.&lt;br /&gt;
*#Create a set their Types.&lt;br /&gt;
*#Check connect-ability for each of those types.&lt;br /&gt;
*#Highlight only the connectible ones.&lt;br /&gt;
&lt;br /&gt;
*To give a set of units that can be selected from a drop down menu in block properties:&lt;br /&gt;
*#Scan for the Type of the parameter.&lt;br /&gt;
*#Get the dimensions of the type.&lt;br /&gt;
*#Scan for the units available. &lt;br /&gt;
&lt;br /&gt;
*Implementation&lt;br /&gt;
**Some testing has been done of the functions, see &amp;lt;code&amp;gt;test_type_info()&amp;lt;/code&amp;gt; function inside /compiler/test/test_basics.c&lt;br /&gt;
**The test can be run on any file, using &amp;lt;code&amp;gt;scons test &amp;amp;&amp;amp; test/test compiler_basics.type_info&amp;lt;/code&amp;gt;&lt;br /&gt;
**From the observations, it is clear that the function &amp;lt;code&amp;gt;GetChildList()&amp;lt;/code&amp;gt; works as it should in case of all user generated foreseeable canvas models.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Weekly Reports GSOC 2011==&lt;br /&gt;
&lt;br /&gt;
The weekly reports will be filed here.&lt;br /&gt;
&lt;br /&gt;
====Week 0====&lt;br /&gt;
23th-May-11 to 29th-May-11&lt;br /&gt;
*Necessary changes for libavoid bindings.&lt;br /&gt;
**Still needs some work on the connection mechanism.&lt;br /&gt;
&lt;br /&gt;
====Week 1====&lt;br /&gt;
30th-May-11 to 5th-June-11&lt;br /&gt;
&lt;br /&gt;
====Week 2====&lt;br /&gt;
6th-June-11 to 12th-June-11&lt;br /&gt;
*Some progress towards having methods to set the default values. {{changeset|3474}}&lt;br /&gt;
*Some unusual behavior while updating to use of SWIG 2, some quick fixes. {{changeset|3482}}&lt;br /&gt;
*Some work towards getting stream into the canvas.&lt;br /&gt;
&lt;br /&gt;
====Week 3====&lt;br /&gt;
13th-June-11 to 19th-June-11&lt;br /&gt;
&lt;br /&gt;
Goals:&lt;br /&gt;
*Set up some mechanism of setting of default values.&lt;br /&gt;
*Get implementation ideas on setting up of globals and streams on the canvas. Possibly begin some work on them.&lt;br /&gt;
&lt;br /&gt;
====Week 4====&lt;br /&gt;
20th-June-11 to 26th-June-11&lt;br /&gt;
*Stream MODEL&#039;s recognized by canvas as globals.&lt;br /&gt;
*User can set streams to blocks.&lt;br /&gt;
*From some implementation there for the streams, through discussions it was found that for a very appropriate solution to the issue of streams, streams with variable components has to be taken into account.&lt;br /&gt;
*Spent the weekend on reading the complete models developed by Art on the Hydrogen cycles, which has a set based implementation of streams.&lt;br /&gt;
&lt;br /&gt;
====Week 5====&lt;br /&gt;
27th-June-11 to 3th-July-11&lt;br /&gt;
&amp;lt;\n&amp;gt;Still struggling with the stream implementation, will do the complete update in a few days time.&lt;br /&gt;
*Writing a new version of Rankine cycle blocks for canvas using the &#039;stream&#039; component defined in the models/stream_holdup.a4l&lt;br /&gt;
*Some success, but still not being able to solve the generated model.&lt;br /&gt;
*Basically in canvas we will have a global &#039;stream&#039; whose properties can be edited using a GUI tool, that particular stream will hold the secrets to the rankine cycle being modeled, each block will use that stream as input and output. Equations inside the block will govern the relation between the output and the input.&lt;br /&gt;
&lt;br /&gt;
====Week 6====&lt;br /&gt;
4th-July-11 to 10th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 7====&lt;br /&gt;
11th-July-11 to 17th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 8====&lt;br /&gt;
18th-July-11 to 24th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 9====&lt;br /&gt;
25th-July-11 to 31st-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 10====&lt;br /&gt;
1st-August-11 to 7th-August-11&lt;br /&gt;
&lt;br /&gt;
====Week 11====&lt;br /&gt;
8th-August-11 to 15th-August-11&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2771</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2771"/>
		<updated>2011-07-03T18:27:14Z</updated>

		<summary type="html">&lt;p&gt;Grivan: v2&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 and current development carried out by [[Grivan Thapar]]. The goals and tasks for the GSoC period are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. The concerns are right now at setting up better mechanisms for parameter handling and design enhancements like handling of stream objects, globals etc.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
TODO : Add more ideas, put a concrete solution overview to each Case. Add new use cases based upon electronic circuit models sent over by [[Divyanshu Bandil|Divyanshu]].&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
*Global Model equations.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
*Block rotation.&lt;br /&gt;
*:It would be nice if blocks could be rotated, it makes the canvas look more tidy.&lt;br /&gt;
*Other Issues.&lt;br /&gt;
*:Just specifying a value and not Fixing it. Should it be possible? &lt;br /&gt;
*: How to make additions of equations to the MODEL more intuitive.&lt;br /&gt;
&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}} (NOTE: see also {{src|models/johnpye/fprops/rankine_fprops.a4c}} for newer version using [[FPROPS]] instead of [[freesteam]] -- JP). We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece. In addition take care of the ALIASES keyword used in the text model. TODO&lt;br /&gt;
*Elimination of redundant equations in closed loop flows.&lt;br /&gt;
*:Multiple loops present in the system.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Still needs to be discussed. TODO&lt;br /&gt;
*Specifications of flow streams. &lt;br /&gt;
*:It should be possible to switch between stream components, water to CO2 to toluene for example.&lt;br /&gt;
*:This however should &#039;&#039;&#039;not&#039;&#039;&#039; involve redrawing the whole model again.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Streams can be defined in the canvas by selecting the particular connections and specifying the stream component, the connections to these components at the ports must use the values of stream component provided. TODO&lt;br /&gt;
*Providing complex flow streams.&lt;br /&gt;
*:A regenerative cycle requires to specify the fraction of steam extracted at the &#039;&#039;bled&#039;&#039; point, that is a TEE in our sense. Such a fraction must be supplied by the user while making such connections. Assuming an open feedwater scheme.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; This should be easy as a simple TEE component must have a fixable variable &#039;fraction&#039;.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*In this case connections may need to be manually specified in order to provide complex flows as required.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious.&lt;br /&gt;
**For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling of Servo Motor with backlash and PID control===&lt;br /&gt;
*TODO : Add description&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The new Gapahs 0.7.2 release till now seems to work fine.&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head 0.7.1. &lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
TODO : Keep adding details&lt;br /&gt;
&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
==Improvements on the Solving Process==&lt;br /&gt;
Since we have no Type informations the solving is done primarily by first generating a string representation of the complete MODEL and then exported to the solver. This can lead to problems while trying to solve complex models requiring a large time to solve, because each time a variable is changed the complete model has to solved again. In case of PyGTK GUI we have a more powerful interaction with the solver and thus can change parameters without discarding the already solved model. The basic problem here lies in the fact that we don&#039;t instantiate the model first and then solve it.&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified. This provides and excellent way to have the same model provide simulation for any number of streams. Two implementations have to be taken care of to specify streams;&lt;br /&gt;
*GUI implementation:&lt;br /&gt;
*:This would provide a suitable GUI to select the stream.&lt;br /&gt;
*Application level implementation&lt;br /&gt;
*:This would add actual stream modifications to the block code.&lt;br /&gt;
The [[#Simple Rankine Cycle]] could be solved simply by connecting steam_port connectors. The {{src|models/johnpye/rankine.a4c}} uses Steam as the only modelling stream. This model needs to be evolved to use generic port types so that a better and more deep understanding is achieved in the problem of specifying flow streams.&lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now.&lt;br /&gt;
&lt;br /&gt;
*To have highlighting of connectible ports while connecting two ports we need to:&lt;br /&gt;
*#Find all suitable (IN/OUT/BOTH) ports available for connection.&lt;br /&gt;
*#Create a set their Types.&lt;br /&gt;
*#Check connect-ability for each of those types.&lt;br /&gt;
*#Highlight only the connectible ones.&lt;br /&gt;
&lt;br /&gt;
*To give a set of units that can be selected from a drop down menu in block properties:&lt;br /&gt;
*#Scan for the Type of the parameter.&lt;br /&gt;
*#Get the dimensions of the type.&lt;br /&gt;
*#Scan for the units available. &lt;br /&gt;
&lt;br /&gt;
*Implementation&lt;br /&gt;
**Some testing has been done of the functions, see &amp;lt;code&amp;gt;test_type_info()&amp;lt;/code&amp;gt; function inside /compiler/test/test_basics.c&lt;br /&gt;
**The test can be run on any file, using &amp;lt;code&amp;gt;scons test &amp;amp;&amp;amp; test/test compiler_basics.type_info&amp;lt;/code&amp;gt;&lt;br /&gt;
**From the observations, it is clear that the function &amp;lt;code&amp;gt;GetChildList()&amp;lt;/code&amp;gt; works as it should in case of all user generated foreseeable canvas models.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Weekly Reports GSOC 2011==&lt;br /&gt;
&lt;br /&gt;
The weekly reports will be filed here.&lt;br /&gt;
&lt;br /&gt;
====Week 0====&lt;br /&gt;
23th-May-11 to 29th-May-11&lt;br /&gt;
*Necessary changes for libavoid bindings.&lt;br /&gt;
**Still needs some work on the connection mechanism.&lt;br /&gt;
&lt;br /&gt;
====Week 1====&lt;br /&gt;
30th-May-11 to 5th-June-11&lt;br /&gt;
&lt;br /&gt;
====Week 2====&lt;br /&gt;
6th-June-11 to 12th-June-11&lt;br /&gt;
*Some progress towards having methods to set the default values. {{changeset|3474}}&lt;br /&gt;
*Some unusual behavior while updating to use of SWIG 2, some quick fixes. {{changeset|3482}}&lt;br /&gt;
*Some work towards getting stream into the canvas.&lt;br /&gt;
&lt;br /&gt;
====Week 3====&lt;br /&gt;
13th-June-11 to 19th-June-11&lt;br /&gt;
&lt;br /&gt;
Goals:&lt;br /&gt;
*Set up some mechanism of setting of default values.&lt;br /&gt;
*Get implementation ideas on setting up of globals and streams on the canvas. Possibly begin some work on them.&lt;br /&gt;
&lt;br /&gt;
====Week 4====&lt;br /&gt;
20th-June-11 to 26th-June-11&lt;br /&gt;
*Stream MODEL&#039;s recognized by canvas as globals.&lt;br /&gt;
*User can set streams to blocks.&lt;br /&gt;
*From some implementation there for the streams, through discussions it was found that for a very appropriate solution to the issue of streams, streams with variable components has to be taken into account.&lt;br /&gt;
*Spent the weekend on reading the complete models developed by Art on the Hydrogen cycles, which has a set based implementation of streams.&lt;br /&gt;
&lt;br /&gt;
====Week 5====&lt;br /&gt;
27th-June-11 to 3th-July-11&lt;br /&gt;
Still struggling with the stream implementation, will do the complete update in a few days time.&lt;br /&gt;
*Writing a new version of Rankine cycle blocks for canvas using the &#039;stream&#039; component defined in the models/stream_holdup.a4l&lt;br /&gt;
*Some success, but still not being able to solve the generated model.&lt;br /&gt;
&lt;br /&gt;
====Week 6====&lt;br /&gt;
4th-July-11 to 10th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 7====&lt;br /&gt;
11th-July-11 to 17th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 8====&lt;br /&gt;
18th-July-11 to 24th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 9====&lt;br /&gt;
25th-July-11 to 31st-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 10====&lt;br /&gt;
1st-August-11 to 7th-August-11&lt;br /&gt;
&lt;br /&gt;
====Week 11====&lt;br /&gt;
8th-August-11 to 15th-August-11&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2738</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2738"/>
		<updated>2011-06-28T00:00:35Z</updated>

		<summary type="html">&lt;p&gt;Grivan: /* Week 4 */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 and current development carried out by [[Grivan Thapar]]. The goals and tasks for the GSoC period are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. The concerns are right now at setting up better mechanisms for parameter handling and design enhancements like handling of stream objects, globals etc.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
TODO : Add more ideas, put a concrete solution overview to each Case. Add new use cases based upon electronic circuit models sent over by Divyanshu.&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
*Global Model equations.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
*Block rotation.&lt;br /&gt;
*:It would be nice if blocks could be rotated, it makes the canvas look more tidy.&lt;br /&gt;
*Other Issues.&lt;br /&gt;
*:Just specifying a value and not Fixing it. Should it be possible? &lt;br /&gt;
*: How to make additions of equations to the MODEL more intuitive.&lt;br /&gt;
&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}} (NOTE: see also {{src|models/johnpye/fprops/rankine_fprops.a4c}} for newer version using [[FPROPS]] instead of [[freesteam]] -- JP). We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece. In addition take care of the ALIASES keyword used in the text model. TODO&lt;br /&gt;
*Elimination of redundant equations in closed loop flows.&lt;br /&gt;
*:Multiple loops present in the system.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Still needs to be discussed. TODO&lt;br /&gt;
*Specifications of flow streams. &lt;br /&gt;
*:It should be possible to switch between stream components, water to CO2 to toluene for example.&lt;br /&gt;
*:This however should &#039;&#039;&#039;not&#039;&#039;&#039; involve redrawing the whole model again.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Streams can be defined in the canvas by selecting the particular connections and specifying the stream component, the connections to these components at the ports must use the values of stream component provided. TODO&lt;br /&gt;
*Providing complex flow streams.&lt;br /&gt;
*:A regenerative cycle requires to specify the fraction of steam extracted at the &#039;&#039;bled&#039;&#039; point, that is a TEE in our sense. Such a fraction must be supplied by the user while making such connections. Assuming an open feedwater scheme.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; This should be easy as a simple TEE component must have a fixable variable &#039;fraction&#039;.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*In this case connections may need to be manually specified in order to provide complex flows as required.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious.&lt;br /&gt;
**For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling of Servo Motor with backlash and PID control===&lt;br /&gt;
*TODO : Add description&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The new Gapahs 0.7.2 release till now seems to work fine.&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head 0.7.1. &lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
TODO : Keep adding details&lt;br /&gt;
&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
==Improvements on the Solving Process==&lt;br /&gt;
Since we have no Type informations the solving is done primarily by first generating a string representation of the complete MODEL and then exported to the solver. This can lead to problems while trying to solve complex models requiring a large time to solve, because each time a variable is changed the complete model has to solved again. In case of PyGTK GUI we have a more powerful interaction with the solver and thus can change parameters without discarding the already solved model. The basic problem here lies in the fact that we don&#039;t instantiate the model first and then solve it.&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified. This provides and excellent way to have the same model provide simulation for any number of streams. Two implementations have to be taken care of to specify streams;&lt;br /&gt;
*GUI implementation:&lt;br /&gt;
*:This would provide a suitable GUI to select the stream.&lt;br /&gt;
*Application level implementation&lt;br /&gt;
*:This would add actual stream modifications to the block code.&lt;br /&gt;
The [[#Simple Rankine Cycle]] could be solved simply by connecting steam_port connectors. The {{src|models/johnpye/rankine.a4c}} uses Steam as the only modelling stream. This model needs to be evolved to use generic port types so that a better and more deep understanding is achieved in the problem of specifying flow streams.&lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now.&lt;br /&gt;
&lt;br /&gt;
*To have highlighting of connectible ports while connecting two ports we need to:&lt;br /&gt;
*#Find all suitable (IN/OUT/BOTH) ports available for connection.&lt;br /&gt;
*#Create a set their Types.&lt;br /&gt;
*#Check connect-ability for each of those types.&lt;br /&gt;
*#Highlight only the connectible ones.&lt;br /&gt;
&lt;br /&gt;
*To give a set of units that can be selected from a drop down menu in block properties:&lt;br /&gt;
*#Scan for the Type of the parameter.&lt;br /&gt;
*#Get the dimensions of the type.&lt;br /&gt;
*#Scan for the units available. &lt;br /&gt;
&lt;br /&gt;
*Implementation&lt;br /&gt;
**Some testing has been done of the functions, see &amp;lt;code&amp;gt;test_type_info()&amp;lt;/code&amp;gt; function inside /compiler/test/test_basics.c&lt;br /&gt;
**The test can be run on any file, using &amp;lt;code&amp;gt;scons test &amp;amp;&amp;amp; test/test compiler_basics.type_info&amp;lt;/code&amp;gt;&lt;br /&gt;
**From the observations, it is clear that the function &amp;lt;code&amp;gt;GetChildList()&amp;lt;/code&amp;gt; works as it should in case of all user generated foreseeable canvas models.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Weekly Reports GSOC 2011==&lt;br /&gt;
&lt;br /&gt;
The weekly reports will be filed here.&lt;br /&gt;
&lt;br /&gt;
====Week 0====&lt;br /&gt;
23th-May-11 to 29th-May-11&lt;br /&gt;
*Necessary changes for libavoid bindings.&lt;br /&gt;
**Still needs some work on the connection mechanism.&lt;br /&gt;
&lt;br /&gt;
====Week 1====&lt;br /&gt;
30th-May-11 to 5th-June-11&lt;br /&gt;
&lt;br /&gt;
====Week 2====&lt;br /&gt;
6th-June-11 to 12th-June-11&lt;br /&gt;
*Some progress towards having methods to set the default values. {{changeset|3474}}&lt;br /&gt;
*Some unusual behavior while updating to use of SWIG 2, some quick fixes. {{changeset|3482}}&lt;br /&gt;
*Some work towards getting stream into the canvas.&lt;br /&gt;
&lt;br /&gt;
====Week 3====&lt;br /&gt;
13th-June-11 to 19th-June-11&lt;br /&gt;
&lt;br /&gt;
Goals:&lt;br /&gt;
*Set up some mechanism of setting of default values.&lt;br /&gt;
*Get implementation ideas on setting up of globals and streams on the canvas. Possibly begin some work on them.&lt;br /&gt;
&lt;br /&gt;
====Week 4====&lt;br /&gt;
20th-June-11 to 26th-June-11&lt;br /&gt;
*Stream MODEL&#039;s recognized by canvas as globals.&lt;br /&gt;
*User can set streams to blocks.&lt;br /&gt;
*From some implementation there for the streams, through discussions it was found that for a very appropriate solution to the issue of streams, streams with variable components has to be taken into account.&lt;br /&gt;
*Spent the weekend on reading the complete models developed by Art on the Hydrogen cycles, which has a set based implementation of streams.&lt;br /&gt;
&lt;br /&gt;
====Week 5====&lt;br /&gt;
27th-June-11 to 3th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 6====&lt;br /&gt;
4th-July-11 to 10th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 7====&lt;br /&gt;
11th-July-11 to 17th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 8====&lt;br /&gt;
18th-July-11 to 24th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 9====&lt;br /&gt;
25th-July-11 to 31st-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 10====&lt;br /&gt;
1st-August-11 to 7th-August-11&lt;br /&gt;
&lt;br /&gt;
====Week 11====&lt;br /&gt;
8th-August-11 to 15th-August-11&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2581</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2581"/>
		<updated>2011-06-13T21:43:44Z</updated>

		<summary type="html">&lt;p&gt;Grivan: /* Week 3 */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 and current development carried out by [[Grivan Thapar]]. The goals and tasks for the GSoC period are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. The concerns are right now at setting up better mechanisms for parameter handling and design enhancements like handling of stream objects, globals etc.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
TODO : Add more ideas, put a concrete solution overview to each Case. Add new use cases based upon electronic circuit models sent over by Divyanshu.&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
*Global Model equations.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
*Block rotation.&lt;br /&gt;
*:It would be nice if blocks could be rotated, it makes the canvas look more tidy.&lt;br /&gt;
*Other Issues.&lt;br /&gt;
*:Just specifying a value and not Fixing it. Should it be possible? &lt;br /&gt;
*: How to make additions of equations to the MODEL more intuitive.&lt;br /&gt;
&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}} (NOTE: see also {{src|models/johnpye/fprops/rankine_fprops.a4c}} for newer version using [[FPROPS]] instead of [[freesteam]] -- JP). We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece. In addition take care of the ALIASES keyword used in the text model. TODO&lt;br /&gt;
*Elimination of redundant equations in closed loop flows.&lt;br /&gt;
*:Multiple loops present in the system.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Still needs to be discussed. TODO&lt;br /&gt;
*Specifications of flow streams. &lt;br /&gt;
*:It should be possible to switch between stream components, water to CO2 to toluene for example.&lt;br /&gt;
*:This however should &#039;&#039;&#039;not&#039;&#039;&#039; involve redrawing the whole model again.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Streams can be defined in the canvas by selecting the particular connections and specifying the stream component, the connections to these components at the ports must use the values of stream component provided. TODO&lt;br /&gt;
*Providing complex flow streams.&lt;br /&gt;
*:A regenerative cycle requires to specify the fraction of steam extracted at the &#039;&#039;bled&#039;&#039; point, that is a TEE in our sense. Such a fraction must be supplied by the user while making such connections. Assuming an open feedwater scheme.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; This should be easy as a simple TEE component must have a fixable variable &#039;fraction&#039;.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*In this case connections may need to be manually specified in order to provide complex flows as required.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious.&lt;br /&gt;
**For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling of Servo Motor with backlash and PID control===&lt;br /&gt;
*TODO : Add description&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The new Gapahs 0.7.2 release till now seems to work fine.&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head 0.7.1. &lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
TODO : Keep adding details&lt;br /&gt;
&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
==Improvements on the Solving Process==&lt;br /&gt;
Since we have no Type informations the solving is done primarily by first generating a string representation of the complete MODEL and then exported to the solver. This can lead to problems while trying to solve complex models requiring a large time to solve, because each time a variable is changed the complete model has to solved again. In case of PyGTK GUI we have a more powerful interaction with the solver and thus can change parameters without discarding the already solved model. The basic problem here lies in the fact that we don&#039;t instantiate the model first and then solve it.&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified. This provides and excellent way to have the same model provide simulation for any number of streams. Two implementations have to be taken care of to specify streams;&lt;br /&gt;
*GUI implementation:&lt;br /&gt;
*:This would provide a suitable GUI to select the stream.&lt;br /&gt;
*Application level implementation&lt;br /&gt;
*:This would add actual stream modifications to the block code.&lt;br /&gt;
The [[#Simple Rankine Cycle]] could be solved simply by connecting steam_port connectors. The {{src|models/johnpye/rankine.a4c}} uses Steam as the only modelling stream. This model needs to be evolved to use generic port types so that a better and more deep understanding is achieved in the problem of specifying flow streams.&lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now.&lt;br /&gt;
&lt;br /&gt;
*To have highlighting of connectible ports while connecting two ports we need to:&lt;br /&gt;
*#Find all suitable (IN/OUT/BOTH) ports available for connection.&lt;br /&gt;
*#Create a set their Types.&lt;br /&gt;
*#Check connect-ability for each of those types.&lt;br /&gt;
*#Highlight only the connectible ones.&lt;br /&gt;
&lt;br /&gt;
*To give a set of units that can be selected from a drop down menu in block properties:&lt;br /&gt;
*#Scan for the Type of the parameter.&lt;br /&gt;
*#Get the dimensions of the type.&lt;br /&gt;
*#Scan for the units available. &lt;br /&gt;
&lt;br /&gt;
*Implementation&lt;br /&gt;
**Some testing has been done of the functions, see &amp;lt;code&amp;gt;test_type_info()&amp;lt;/code&amp;gt; function inside /compiler/test/test_basics.c&lt;br /&gt;
**The test can be run on any file, using &amp;lt;code&amp;gt;scons test &amp;amp;&amp;amp; test/test compiler_basics.type_info&amp;lt;/code&amp;gt;&lt;br /&gt;
**From the observations, it is clear that the function &amp;lt;code&amp;gt;GetChildList()&amp;lt;/code&amp;gt; works as it should in case of all user generated foreseeable canvas models.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Weekly Reports GSOC 2011==&lt;br /&gt;
&lt;br /&gt;
The weekly reports will be filed here.&lt;br /&gt;
&lt;br /&gt;
====Week 0====&lt;br /&gt;
23th-May-11 to 39th-May-11&lt;br /&gt;
*Necessary changes for libavoid bindings.&lt;br /&gt;
**Still needs some work on the connection mechanism.&lt;br /&gt;
&lt;br /&gt;
====Week 1====&lt;br /&gt;
30st-May-11 to 5th-June-11&lt;br /&gt;
&lt;br /&gt;
====Week 2====&lt;br /&gt;
6th-June-11 to 12th-June-11&lt;br /&gt;
*Some progress towards having methods to set the default values.r3474&lt;br /&gt;
*Some unusual behavior while updating to use of SWIG 2, some quick fixes. r3482&lt;br /&gt;
*Some work towards getting stream into the canvas.&lt;br /&gt;
&lt;br /&gt;
====Week 3====&lt;br /&gt;
13th-June-11 to 19th-June-11&lt;br /&gt;
&lt;br /&gt;
Goals:&lt;br /&gt;
*Set up some mechanism of setting of default values.&lt;br /&gt;
*Get implementation ideas on setting up of globals and streams on the canvas. Possibly begin some work on them.&lt;br /&gt;
&lt;br /&gt;
====Week 4====&lt;br /&gt;
20st-June-11 to 26th-June-11&lt;br /&gt;
&lt;br /&gt;
====Week 5====&lt;br /&gt;
27th-June-11 to 3th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 6====&lt;br /&gt;
4th-July-11 to 10th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 7====&lt;br /&gt;
11th-July-11 to 17th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 8====&lt;br /&gt;
18th-July-11 to 24th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 9====&lt;br /&gt;
25th-July-11 to 31st-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 10====&lt;br /&gt;
1st-August-11 to 7th-August-11&lt;br /&gt;
&lt;br /&gt;
====Week 11====&lt;br /&gt;
8th-August-11 to 15th-August-11&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2580</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2580"/>
		<updated>2011-06-13T21:43:01Z</updated>

		<summary type="html">&lt;p&gt;Grivan: /* Week 3 */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 and current development carried out by [[Grivan Thapar]]. The goals and tasks for the GSoC period are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. The concerns are right now at setting up better mechanisms for parameter handling and design enhancements like handling of stream objects, globals etc.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
TODO : Add more ideas, put a concrete solution overview to each Case. Add new use cases based upon electronic circuit models sent over by Divyanshu.&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
*Global Model equations.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
*Block rotation.&lt;br /&gt;
*:It would be nice if blocks could be rotated, it makes the canvas look more tidy.&lt;br /&gt;
*Other Issues.&lt;br /&gt;
*:Just specifying a value and not Fixing it. Should it be possible? &lt;br /&gt;
*: How to make additions of equations to the MODEL more intuitive.&lt;br /&gt;
&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}} (NOTE: see also {{src|models/johnpye/fprops/rankine_fprops.a4c}} for newer version using [[FPROPS]] instead of [[freesteam]] -- JP). We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece. In addition take care of the ALIASES keyword used in the text model. TODO&lt;br /&gt;
*Elimination of redundant equations in closed loop flows.&lt;br /&gt;
*:Multiple loops present in the system.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Still needs to be discussed. TODO&lt;br /&gt;
*Specifications of flow streams. &lt;br /&gt;
*:It should be possible to switch between stream components, water to CO2 to toluene for example.&lt;br /&gt;
*:This however should &#039;&#039;&#039;not&#039;&#039;&#039; involve redrawing the whole model again.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Streams can be defined in the canvas by selecting the particular connections and specifying the stream component, the connections to these components at the ports must use the values of stream component provided. TODO&lt;br /&gt;
*Providing complex flow streams.&lt;br /&gt;
*:A regenerative cycle requires to specify the fraction of steam extracted at the &#039;&#039;bled&#039;&#039; point, that is a TEE in our sense. Such a fraction must be supplied by the user while making such connections. Assuming an open feedwater scheme.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; This should be easy as a simple TEE component must have a fixable variable &#039;fraction&#039;.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*In this case connections may need to be manually specified in order to provide complex flows as required.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious.&lt;br /&gt;
**For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling of Servo Motor with backlash and PID control===&lt;br /&gt;
*TODO : Add description&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The new Gapahs 0.7.2 release till now seems to work fine.&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head 0.7.1. &lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
TODO : Keep adding details&lt;br /&gt;
&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
==Improvements on the Solving Process==&lt;br /&gt;
Since we have no Type informations the solving is done primarily by first generating a string representation of the complete MODEL and then exported to the solver. This can lead to problems while trying to solve complex models requiring a large time to solve, because each time a variable is changed the complete model has to solved again. In case of PyGTK GUI we have a more powerful interaction with the solver and thus can change parameters without discarding the already solved model. The basic problem here lies in the fact that we don&#039;t instantiate the model first and then solve it.&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified. This provides and excellent way to have the same model provide simulation for any number of streams. Two implementations have to be taken care of to specify streams;&lt;br /&gt;
*GUI implementation:&lt;br /&gt;
*:This would provide a suitable GUI to select the stream.&lt;br /&gt;
*Application level implementation&lt;br /&gt;
*:This would add actual stream modifications to the block code.&lt;br /&gt;
The [[#Simple Rankine Cycle]] could be solved simply by connecting steam_port connectors. The {{src|models/johnpye/rankine.a4c}} uses Steam as the only modelling stream. This model needs to be evolved to use generic port types so that a better and more deep understanding is achieved in the problem of specifying flow streams.&lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now.&lt;br /&gt;
&lt;br /&gt;
*To have highlighting of connectible ports while connecting two ports we need to:&lt;br /&gt;
*#Find all suitable (IN/OUT/BOTH) ports available for connection.&lt;br /&gt;
*#Create a set their Types.&lt;br /&gt;
*#Check connect-ability for each of those types.&lt;br /&gt;
*#Highlight only the connectible ones.&lt;br /&gt;
&lt;br /&gt;
*To give a set of units that can be selected from a drop down menu in block properties:&lt;br /&gt;
*#Scan for the Type of the parameter.&lt;br /&gt;
*#Get the dimensions of the type.&lt;br /&gt;
*#Scan for the units available. &lt;br /&gt;
&lt;br /&gt;
*Implementation&lt;br /&gt;
**Some testing has been done of the functions, see &amp;lt;code&amp;gt;test_type_info()&amp;lt;/code&amp;gt; function inside /compiler/test/test_basics.c&lt;br /&gt;
**The test can be run on any file, using &amp;lt;code&amp;gt;scons test &amp;amp;&amp;amp; test/test compiler_basics.type_info&amp;lt;/code&amp;gt;&lt;br /&gt;
**From the observations, it is clear that the function &amp;lt;code&amp;gt;GetChildList()&amp;lt;/code&amp;gt; works as it should in case of all user generated foreseeable canvas models.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Weekly Reports GSOC 2011==&lt;br /&gt;
&lt;br /&gt;
The weekly reports will be filed here.&lt;br /&gt;
&lt;br /&gt;
====Week 0====&lt;br /&gt;
23th-May-11 to 39th-May-11&lt;br /&gt;
*Necessary changes for libavoid bindings.&lt;br /&gt;
**Still needs some work on the connection mechanism.&lt;br /&gt;
&lt;br /&gt;
====Week 1====&lt;br /&gt;
30st-May-11 to 5th-June-11&lt;br /&gt;
&lt;br /&gt;
====Week 2====&lt;br /&gt;
6th-June-11 to 12th-June-11&lt;br /&gt;
*Some progress towards having methods to set the default values.r3474&lt;br /&gt;
*Some unusual behavior while updating to use of SWIG 2, some quick fixes. r3482&lt;br /&gt;
*Some work towards getting stream into the canvas.&lt;br /&gt;
&lt;br /&gt;
====Week 3====&lt;br /&gt;
13th-June-11 to 19th-June-11&lt;br /&gt;
Goals:&lt;br /&gt;
*Set up some mechanism of setting of default values.&lt;br /&gt;
*Get implementation ideas on setting up of globals and streams on the canvas. Possibly begin some work on them.&lt;br /&gt;
&lt;br /&gt;
====Week 4====&lt;br /&gt;
20st-June-11 to 26th-June-11&lt;br /&gt;
&lt;br /&gt;
====Week 5====&lt;br /&gt;
27th-June-11 to 3th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 6====&lt;br /&gt;
4th-July-11 to 10th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 7====&lt;br /&gt;
11th-July-11 to 17th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 8====&lt;br /&gt;
18th-July-11 to 24th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 9====&lt;br /&gt;
25th-July-11 to 31st-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 10====&lt;br /&gt;
1st-August-11 to 7th-August-11&lt;br /&gt;
&lt;br /&gt;
====Week 11====&lt;br /&gt;
8th-August-11 to 15th-August-11&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2579</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2579"/>
		<updated>2011-06-13T21:40:35Z</updated>

		<summary type="html">&lt;p&gt;Grivan: /* Week 2 */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 and current development carried out by [[Grivan Thapar]]. The goals and tasks for the GSoC period are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. The concerns are right now at setting up better mechanisms for parameter handling and design enhancements like handling of stream objects, globals etc.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
TODO : Add more ideas, put a concrete solution overview to each Case. Add new use cases based upon electronic circuit models sent over by Divyanshu.&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
*Global Model equations.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
*Block rotation.&lt;br /&gt;
*:It would be nice if blocks could be rotated, it makes the canvas look more tidy.&lt;br /&gt;
*Other Issues.&lt;br /&gt;
*:Just specifying a value and not Fixing it. Should it be possible? &lt;br /&gt;
*: How to make additions of equations to the MODEL more intuitive.&lt;br /&gt;
&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}} (NOTE: see also {{src|models/johnpye/fprops/rankine_fprops.a4c}} for newer version using [[FPROPS]] instead of [[freesteam]] -- JP). We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece. In addition take care of the ALIASES keyword used in the text model. TODO&lt;br /&gt;
*Elimination of redundant equations in closed loop flows.&lt;br /&gt;
*:Multiple loops present in the system.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Still needs to be discussed. TODO&lt;br /&gt;
*Specifications of flow streams. &lt;br /&gt;
*:It should be possible to switch between stream components, water to CO2 to toluene for example.&lt;br /&gt;
*:This however should &#039;&#039;&#039;not&#039;&#039;&#039; involve redrawing the whole model again.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Streams can be defined in the canvas by selecting the particular connections and specifying the stream component, the connections to these components at the ports must use the values of stream component provided. TODO&lt;br /&gt;
*Providing complex flow streams.&lt;br /&gt;
*:A regenerative cycle requires to specify the fraction of steam extracted at the &#039;&#039;bled&#039;&#039; point, that is a TEE in our sense. Such a fraction must be supplied by the user while making such connections. Assuming an open feedwater scheme.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; This should be easy as a simple TEE component must have a fixable variable &#039;fraction&#039;.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*In this case connections may need to be manually specified in order to provide complex flows as required.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious.&lt;br /&gt;
**For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling of Servo Motor with backlash and PID control===&lt;br /&gt;
*TODO : Add description&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The new Gapahs 0.7.2 release till now seems to work fine.&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head 0.7.1. &lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
TODO : Keep adding details&lt;br /&gt;
&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
==Improvements on the Solving Process==&lt;br /&gt;
Since we have no Type informations the solving is done primarily by first generating a string representation of the complete MODEL and then exported to the solver. This can lead to problems while trying to solve complex models requiring a large time to solve, because each time a variable is changed the complete model has to solved again. In case of PyGTK GUI we have a more powerful interaction with the solver and thus can change parameters without discarding the already solved model. The basic problem here lies in the fact that we don&#039;t instantiate the model first and then solve it.&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified. This provides and excellent way to have the same model provide simulation for any number of streams. Two implementations have to be taken care of to specify streams;&lt;br /&gt;
*GUI implementation:&lt;br /&gt;
*:This would provide a suitable GUI to select the stream.&lt;br /&gt;
*Application level implementation&lt;br /&gt;
*:This would add actual stream modifications to the block code.&lt;br /&gt;
The [[#Simple Rankine Cycle]] could be solved simply by connecting steam_port connectors. The {{src|models/johnpye/rankine.a4c}} uses Steam as the only modelling stream. This model needs to be evolved to use generic port types so that a better and more deep understanding is achieved in the problem of specifying flow streams.&lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now.&lt;br /&gt;
&lt;br /&gt;
*To have highlighting of connectible ports while connecting two ports we need to:&lt;br /&gt;
*#Find all suitable (IN/OUT/BOTH) ports available for connection.&lt;br /&gt;
*#Create a set their Types.&lt;br /&gt;
*#Check connect-ability for each of those types.&lt;br /&gt;
*#Highlight only the connectible ones.&lt;br /&gt;
&lt;br /&gt;
*To give a set of units that can be selected from a drop down menu in block properties:&lt;br /&gt;
*#Scan for the Type of the parameter.&lt;br /&gt;
*#Get the dimensions of the type.&lt;br /&gt;
*#Scan for the units available. &lt;br /&gt;
&lt;br /&gt;
*Implementation&lt;br /&gt;
**Some testing has been done of the functions, see &amp;lt;code&amp;gt;test_type_info()&amp;lt;/code&amp;gt; function inside /compiler/test/test_basics.c&lt;br /&gt;
**The test can be run on any file, using &amp;lt;code&amp;gt;scons test &amp;amp;&amp;amp; test/test compiler_basics.type_info&amp;lt;/code&amp;gt;&lt;br /&gt;
**From the observations, it is clear that the function &amp;lt;code&amp;gt;GetChildList()&amp;lt;/code&amp;gt; works as it should in case of all user generated foreseeable canvas models.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Weekly Reports GSOC 2011==&lt;br /&gt;
&lt;br /&gt;
The weekly reports will be filed here.&lt;br /&gt;
&lt;br /&gt;
====Week 0====&lt;br /&gt;
23th-May-11 to 39th-May-11&lt;br /&gt;
*Necessary changes for libavoid bindings.&lt;br /&gt;
**Still needs some work on the connection mechanism.&lt;br /&gt;
&lt;br /&gt;
====Week 1====&lt;br /&gt;
30st-May-11 to 5th-June-11&lt;br /&gt;
&lt;br /&gt;
====Week 2====&lt;br /&gt;
6th-June-11 to 12th-June-11&lt;br /&gt;
*Some progress towards having methods to set the default values.r3474&lt;br /&gt;
*Some unusual behavior while updating to use of SWIG 2, some quick fixes. r3482&lt;br /&gt;
*Some work towards getting stream into the canvas.&lt;br /&gt;
&lt;br /&gt;
====Week 3====&lt;br /&gt;
13th-June-11 to 19th-June-11&lt;br /&gt;
&lt;br /&gt;
====Week 4====&lt;br /&gt;
20st-June-11 to 26th-June-11&lt;br /&gt;
&lt;br /&gt;
====Week 5====&lt;br /&gt;
27th-June-11 to 3th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 6====&lt;br /&gt;
4th-July-11 to 10th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 7====&lt;br /&gt;
11th-July-11 to 17th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 8====&lt;br /&gt;
18th-July-11 to 24th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 9====&lt;br /&gt;
25th-July-11 to 31st-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 10====&lt;br /&gt;
1st-August-11 to 7th-August-11&lt;br /&gt;
&lt;br /&gt;
====Week 11====&lt;br /&gt;
8th-August-11 to 15th-August-11&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2549</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2549"/>
		<updated>2011-06-06T22:01:36Z</updated>

		<summary type="html">&lt;p&gt;Grivan: /* Week 0 */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 and current development carried out by [[Grivan Thapar]]. The goals and tasks for the GSoC period are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. The concerns are right now at setting up better mechanisms for parameter handling and design enhancements like handling of stream objects, globals etc.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
TODO : Add more ideas, put a concrete solution overview to each Case. Add new use cases based upon electronic circuit models sent over by Divyanshu.&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
*Global Model equations.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
*Block rotation.&lt;br /&gt;
*:It would be nice if blocks could be rotated, it makes the canvas look more tidy.&lt;br /&gt;
*Other Issues.&lt;br /&gt;
*:Just specifying a value and not Fixing it. Should it be possible? &lt;br /&gt;
*: How to make additions of equations to the MODEL more intuitive.&lt;br /&gt;
&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}} (NOTE: see also {{src|models/johnpye/fprops/rankine_fprops.a4c}} for newer version using [[FPROPS]] instead of [[freesteam]] -- JP). We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece. In addition take care of the ALIASES keyword used in the text model. TODO&lt;br /&gt;
*Elimination of redundant equations in closed loop flows.&lt;br /&gt;
*:Multiple loops present in the system.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Still needs to be discussed. TODO&lt;br /&gt;
*Specifications of flow streams. &lt;br /&gt;
*:It should be possible to switch between stream components, water to CO2 to toluene for example.&lt;br /&gt;
*:This however should &#039;&#039;&#039;not&#039;&#039;&#039; involve redrawing the whole model again.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Streams can be defined in the canvas by selecting the particular connections and specifying the stream component, the connections to these components at the ports must use the values of stream component provided. TODO&lt;br /&gt;
*Providing complex flow streams.&lt;br /&gt;
*:A regenerative cycle requires to specify the fraction of steam extracted at the &#039;&#039;bled&#039;&#039; point, that is a TEE in our sense. Such a fraction must be supplied by the user while making such connections. Assuming an open feedwater scheme.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; This should be easy as a simple TEE component must have a fixable variable &#039;fraction&#039;.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*In this case connections may need to be manually specified in order to provide complex flows as required.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious.&lt;br /&gt;
**For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling of Servo Motor with backlash and PID control===&lt;br /&gt;
*TODO : Add description&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The new Gapahs 0.7.2 release till now seems to work fine.&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head 0.7.1. &lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
TODO : Keep adding details&lt;br /&gt;
&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
==Improvements on the Solving Process==&lt;br /&gt;
Since we have no Type informations the solving is done primarily by first generating a string representation of the complete MODEL and then exported to the solver. This can lead to problems while trying to solve complex models requiring a large time to solve, because each time a variable is changed the complete model has to solved again. In case of PyGTK GUI we have a more powerful interaction with the solver and thus can change parameters without discarding the already solved model. The basic problem here lies in the fact that we don&#039;t instantiate the model first and then solve it.&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified. This provides and excellent way to have the same model provide simulation for any number of streams. Two implementations have to be taken care of to specify streams;&lt;br /&gt;
*GUI implementation:&lt;br /&gt;
*:This would provide a suitable GUI to select the stream.&lt;br /&gt;
*Application level implementation&lt;br /&gt;
*:This would add actual stream modifications to the block code.&lt;br /&gt;
The [[#Simple Rankine Cycle]] could be solved simply by connecting steam_port connectors. The {{src|models/johnpye/rankine.a4c}} uses Steam as the only modelling stream. This model needs to be evolved to use generic port types so that a better and more deep understanding is achieved in the problem of specifying flow streams.&lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now.&lt;br /&gt;
&lt;br /&gt;
*To have highlighting of connectible ports while connecting two ports we need to:&lt;br /&gt;
*#Find all suitable (IN/OUT/BOTH) ports available for connection.&lt;br /&gt;
*#Create a set their Types.&lt;br /&gt;
*#Check connect-ability for each of those types.&lt;br /&gt;
*#Highlight only the connectible ones.&lt;br /&gt;
&lt;br /&gt;
*To give a set of units that can be selected from a drop down menu in block properties:&lt;br /&gt;
*#Scan for the Type of the parameter.&lt;br /&gt;
*#Get the dimensions of the type.&lt;br /&gt;
*#Scan for the units available. &lt;br /&gt;
&lt;br /&gt;
*Implementation&lt;br /&gt;
**Some testing has been done of the functions, see &amp;lt;code&amp;gt;test_type_info()&amp;lt;/code&amp;gt; function inside /compiler/test/test_basics.c&lt;br /&gt;
**The test can be run on any file, using &amp;lt;code&amp;gt;scons test &amp;amp;&amp;amp; test/test compiler_basics.type_info&amp;lt;/code&amp;gt;&lt;br /&gt;
**From the observations, it is clear that the function &amp;lt;code&amp;gt;GetChildList()&amp;lt;/code&amp;gt; works as it should in case of all user generated foreseeable canvas models.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Weekly Reports GSOC 2011==&lt;br /&gt;
&lt;br /&gt;
The weekly reports will be filed here.&lt;br /&gt;
&lt;br /&gt;
====Week 0====&lt;br /&gt;
23th-May-11 to 39th-May-11&lt;br /&gt;
*Necessary changes for libavoid bindings.&lt;br /&gt;
**Still needs some work on the connection mechanism.&lt;br /&gt;
&lt;br /&gt;
====Week 1====&lt;br /&gt;
30st-May-11 to 5th-June-11&lt;br /&gt;
&lt;br /&gt;
====Week 2====&lt;br /&gt;
6th-June-11 to 12th-June-11&lt;br /&gt;
&lt;br /&gt;
====Week 3====&lt;br /&gt;
13th-June-11 to 19th-June-11&lt;br /&gt;
&lt;br /&gt;
====Week 4====&lt;br /&gt;
20st-June-11 to 26th-June-11&lt;br /&gt;
&lt;br /&gt;
====Week 5====&lt;br /&gt;
27th-June-11 to 3th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 6====&lt;br /&gt;
4th-July-11 to 10th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 7====&lt;br /&gt;
11th-July-11 to 17th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 8====&lt;br /&gt;
18th-July-11 to 24th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 9====&lt;br /&gt;
25th-July-11 to 31st-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 10====&lt;br /&gt;
1st-August-11 to 7th-August-11&lt;br /&gt;
&lt;br /&gt;
====Week 11====&lt;br /&gt;
8th-August-11 to 15th-August-11&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2548</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2548"/>
		<updated>2011-06-06T21:48:41Z</updated>

		<summary type="html">&lt;p&gt;Grivan: /* Weekly Reports GSOC 2011 */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 and current development carried out by [[Grivan Thapar]]. The goals and tasks for the GSoC period are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. The concerns are right now at setting up better mechanisms for parameter handling and design enhancements like handling of stream objects, globals etc.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
TODO : Add more ideas, put a concrete solution overview to each Case. Add new use cases based upon electronic circuit models sent over by Divyanshu.&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
*Global Model equations.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
*Block rotation.&lt;br /&gt;
*:It would be nice if blocks could be rotated, it makes the canvas look more tidy.&lt;br /&gt;
*Other Issues.&lt;br /&gt;
*:Just specifying a value and not Fixing it. Should it be possible? &lt;br /&gt;
*: How to make additions of equations to the MODEL more intuitive.&lt;br /&gt;
&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}} (NOTE: see also {{src|models/johnpye/fprops/rankine_fprops.a4c}} for newer version using [[FPROPS]] instead of [[freesteam]] -- JP). We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece. In addition take care of the ALIASES keyword used in the text model. TODO&lt;br /&gt;
*Elimination of redundant equations in closed loop flows.&lt;br /&gt;
*:Multiple loops present in the system.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Still needs to be discussed. TODO&lt;br /&gt;
*Specifications of flow streams. &lt;br /&gt;
*:It should be possible to switch between stream components, water to CO2 to toluene for example.&lt;br /&gt;
*:This however should &#039;&#039;&#039;not&#039;&#039;&#039; involve redrawing the whole model again.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Streams can be defined in the canvas by selecting the particular connections and specifying the stream component, the connections to these components at the ports must use the values of stream component provided. TODO&lt;br /&gt;
*Providing complex flow streams.&lt;br /&gt;
*:A regenerative cycle requires to specify the fraction of steam extracted at the &#039;&#039;bled&#039;&#039; point, that is a TEE in our sense. Such a fraction must be supplied by the user while making such connections. Assuming an open feedwater scheme.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; This should be easy as a simple TEE component must have a fixable variable &#039;fraction&#039;.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*In this case connections may need to be manually specified in order to provide complex flows as required.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious.&lt;br /&gt;
**For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling of Servo Motor with backlash and PID control===&lt;br /&gt;
*TODO : Add description&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The new Gapahs 0.7.2 release till now seems to work fine.&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head 0.7.1. &lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
TODO : Keep adding details&lt;br /&gt;
&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
==Improvements on the Solving Process==&lt;br /&gt;
Since we have no Type informations the solving is done primarily by first generating a string representation of the complete MODEL and then exported to the solver. This can lead to problems while trying to solve complex models requiring a large time to solve, because each time a variable is changed the complete model has to solved again. In case of PyGTK GUI we have a more powerful interaction with the solver and thus can change parameters without discarding the already solved model. The basic problem here lies in the fact that we don&#039;t instantiate the model first and then solve it.&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified. This provides and excellent way to have the same model provide simulation for any number of streams. Two implementations have to be taken care of to specify streams;&lt;br /&gt;
*GUI implementation:&lt;br /&gt;
*:This would provide a suitable GUI to select the stream.&lt;br /&gt;
*Application level implementation&lt;br /&gt;
*:This would add actual stream modifications to the block code.&lt;br /&gt;
The [[#Simple Rankine Cycle]] could be solved simply by connecting steam_port connectors. The {{src|models/johnpye/rankine.a4c}} uses Steam as the only modelling stream. This model needs to be evolved to use generic port types so that a better and more deep understanding is achieved in the problem of specifying flow streams.&lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now.&lt;br /&gt;
&lt;br /&gt;
*To have highlighting of connectible ports while connecting two ports we need to:&lt;br /&gt;
*#Find all suitable (IN/OUT/BOTH) ports available for connection.&lt;br /&gt;
*#Create a set their Types.&lt;br /&gt;
*#Check connect-ability for each of those types.&lt;br /&gt;
*#Highlight only the connectible ones.&lt;br /&gt;
&lt;br /&gt;
*To give a set of units that can be selected from a drop down menu in block properties:&lt;br /&gt;
*#Scan for the Type of the parameter.&lt;br /&gt;
*#Get the dimensions of the type.&lt;br /&gt;
*#Scan for the units available. &lt;br /&gt;
&lt;br /&gt;
*Implementation&lt;br /&gt;
**Some testing has been done of the functions, see &amp;lt;code&amp;gt;test_type_info()&amp;lt;/code&amp;gt; function inside /compiler/test/test_basics.c&lt;br /&gt;
**The test can be run on any file, using &amp;lt;code&amp;gt;scons test &amp;amp;&amp;amp; test/test compiler_basics.type_info&amp;lt;/code&amp;gt;&lt;br /&gt;
**From the observations, it is clear that the function &amp;lt;code&amp;gt;GetChildList()&amp;lt;/code&amp;gt; works as it should in case of all user generated foreseeable canvas models.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Weekly Reports GSOC 2011==&lt;br /&gt;
&lt;br /&gt;
The weekly reports will be filed here.&lt;br /&gt;
&lt;br /&gt;
====Week 0====&lt;br /&gt;
23th-May-11 to 39th-May-11&lt;br /&gt;
&lt;br /&gt;
====Week 1====&lt;br /&gt;
30st-May-11 to 5th-June-11&lt;br /&gt;
&lt;br /&gt;
====Week 2====&lt;br /&gt;
6th-June-11 to 12th-June-11&lt;br /&gt;
&lt;br /&gt;
====Week 3====&lt;br /&gt;
13th-June-11 to 19th-June-11&lt;br /&gt;
&lt;br /&gt;
====Week 4====&lt;br /&gt;
20st-June-11 to 26th-June-11&lt;br /&gt;
&lt;br /&gt;
====Week 5====&lt;br /&gt;
27th-June-11 to 3th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 6====&lt;br /&gt;
4th-July-11 to 10th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 7====&lt;br /&gt;
11th-July-11 to 17th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 8====&lt;br /&gt;
18th-July-11 to 24th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 9====&lt;br /&gt;
25th-July-11 to 31st-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 10====&lt;br /&gt;
1st-August-11 to 7th-August-11&lt;br /&gt;
&lt;br /&gt;
====Week 11====&lt;br /&gt;
8th-August-11 to 15th-August-11&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2547</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2547"/>
		<updated>2011-06-06T21:48:15Z</updated>

		<summary type="html">&lt;p&gt;Grivan: /* Weekly Reports GSOC 2011 */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 and current development carried out by [[Grivan Thapar]]. The goals and tasks for the GSoC period are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. The concerns are right now at setting up better mechanisms for parameter handling and design enhancements like handling of stream objects, globals etc.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
TODO : Add more ideas, put a concrete solution overview to each Case. Add new use cases based upon electronic circuit models sent over by Divyanshu.&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
*Global Model equations.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
*Block rotation.&lt;br /&gt;
*:It would be nice if blocks could be rotated, it makes the canvas look more tidy.&lt;br /&gt;
*Other Issues.&lt;br /&gt;
*:Just specifying a value and not Fixing it. Should it be possible? &lt;br /&gt;
*: How to make additions of equations to the MODEL more intuitive.&lt;br /&gt;
&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}} (NOTE: see also {{src|models/johnpye/fprops/rankine_fprops.a4c}} for newer version using [[FPROPS]] instead of [[freesteam]] -- JP). We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece. In addition take care of the ALIASES keyword used in the text model. TODO&lt;br /&gt;
*Elimination of redundant equations in closed loop flows.&lt;br /&gt;
*:Multiple loops present in the system.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Still needs to be discussed. TODO&lt;br /&gt;
*Specifications of flow streams. &lt;br /&gt;
*:It should be possible to switch between stream components, water to CO2 to toluene for example.&lt;br /&gt;
*:This however should &#039;&#039;&#039;not&#039;&#039;&#039; involve redrawing the whole model again.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Streams can be defined in the canvas by selecting the particular connections and specifying the stream component, the connections to these components at the ports must use the values of stream component provided. TODO&lt;br /&gt;
*Providing complex flow streams.&lt;br /&gt;
*:A regenerative cycle requires to specify the fraction of steam extracted at the &#039;&#039;bled&#039;&#039; point, that is a TEE in our sense. Such a fraction must be supplied by the user while making such connections. Assuming an open feedwater scheme.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; This should be easy as a simple TEE component must have a fixable variable &#039;fraction&#039;.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*In this case connections may need to be manually specified in order to provide complex flows as required.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious.&lt;br /&gt;
**For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling of Servo Motor with backlash and PID control===&lt;br /&gt;
*TODO : Add description&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The new Gapahs 0.7.2 release till now seems to work fine.&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head 0.7.1. &lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
TODO : Keep adding details&lt;br /&gt;
&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
==Improvements on the Solving Process==&lt;br /&gt;
Since we have no Type informations the solving is done primarily by first generating a string representation of the complete MODEL and then exported to the solver. This can lead to problems while trying to solve complex models requiring a large time to solve, because each time a variable is changed the complete model has to solved again. In case of PyGTK GUI we have a more powerful interaction with the solver and thus can change parameters without discarding the already solved model. The basic problem here lies in the fact that we don&#039;t instantiate the model first and then solve it.&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified. This provides and excellent way to have the same model provide simulation for any number of streams. Two implementations have to be taken care of to specify streams;&lt;br /&gt;
*GUI implementation:&lt;br /&gt;
*:This would provide a suitable GUI to select the stream.&lt;br /&gt;
*Application level implementation&lt;br /&gt;
*:This would add actual stream modifications to the block code.&lt;br /&gt;
The [[#Simple Rankine Cycle]] could be solved simply by connecting steam_port connectors. The {{src|models/johnpye/rankine.a4c}} uses Steam as the only modelling stream. This model needs to be evolved to use generic port types so that a better and more deep understanding is achieved in the problem of specifying flow streams.&lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now.&lt;br /&gt;
&lt;br /&gt;
*To have highlighting of connectible ports while connecting two ports we need to:&lt;br /&gt;
*#Find all suitable (IN/OUT/BOTH) ports available for connection.&lt;br /&gt;
*#Create a set their Types.&lt;br /&gt;
*#Check connect-ability for each of those types.&lt;br /&gt;
*#Highlight only the connectible ones.&lt;br /&gt;
&lt;br /&gt;
*To give a set of units that can be selected from a drop down menu in block properties:&lt;br /&gt;
*#Scan for the Type of the parameter.&lt;br /&gt;
*#Get the dimensions of the type.&lt;br /&gt;
*#Scan for the units available. &lt;br /&gt;
&lt;br /&gt;
*Implementation&lt;br /&gt;
**Some testing has been done of the functions, see &amp;lt;code&amp;gt;test_type_info()&amp;lt;/code&amp;gt; function inside /compiler/test/test_basics.c&lt;br /&gt;
**The test can be run on any file, using &amp;lt;code&amp;gt;scons test &amp;amp;&amp;amp; test/test compiler_basics.type_info&amp;lt;/code&amp;gt;&lt;br /&gt;
**From the observations, it is clear that the function &amp;lt;code&amp;gt;GetChildList()&amp;lt;/code&amp;gt; works as it should in case of all user generated foreseeable canvas models.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Weekly Reports GSOC 2011==&lt;br /&gt;
&lt;br /&gt;
The weekly reports will be filed here. Week 0 starts from 24th of May up-to 30th of May and so on.&lt;br /&gt;
&lt;br /&gt;
====Week 0====&lt;br /&gt;
23th-May-11 to 39th-May-11&lt;br /&gt;
&lt;br /&gt;
====Week 1====&lt;br /&gt;
30st-May-11 to 5th-June-11&lt;br /&gt;
&lt;br /&gt;
====Week 2====&lt;br /&gt;
6th-June-11 to 12th-June-11&lt;br /&gt;
&lt;br /&gt;
====Week 3====&lt;br /&gt;
13th-June-11 to 19th-June-11&lt;br /&gt;
&lt;br /&gt;
====Week 4====&lt;br /&gt;
20st-June-11 to 26th-June-11&lt;br /&gt;
&lt;br /&gt;
====Week 5====&lt;br /&gt;
27th-June-11 to 3th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 6====&lt;br /&gt;
4th-July-11 to 10th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 7====&lt;br /&gt;
11th-July-11 to 17th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 8====&lt;br /&gt;
18th-July-11 to 24th-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 9====&lt;br /&gt;
25th-July-11 to 31st-July-11&lt;br /&gt;
&lt;br /&gt;
====Week 10====&lt;br /&gt;
1st-August-11 to 7th-August-11&lt;br /&gt;
&lt;br /&gt;
====Week 11====&lt;br /&gt;
8th-August-11 to 15th-August-11&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2546</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2546"/>
		<updated>2011-06-06T21:43:40Z</updated>

		<summary type="html">&lt;p&gt;Grivan: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 and current development carried out by [[Grivan Thapar]]. The goals and tasks for the GSoC period are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. The concerns are right now at setting up better mechanisms for parameter handling and design enhancements like handling of stream objects, globals etc.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
TODO : Add more ideas, put a concrete solution overview to each Case. Add new use cases based upon electronic circuit models sent over by Divyanshu.&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
*Global Model equations.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
*Block rotation.&lt;br /&gt;
*:It would be nice if blocks could be rotated, it makes the canvas look more tidy.&lt;br /&gt;
*Other Issues.&lt;br /&gt;
*:Just specifying a value and not Fixing it. Should it be possible? &lt;br /&gt;
*: How to make additions of equations to the MODEL more intuitive.&lt;br /&gt;
&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}} (NOTE: see also {{src|models/johnpye/fprops/rankine_fprops.a4c}} for newer version using [[FPROPS]] instead of [[freesteam]] -- JP). We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece. In addition take care of the ALIASES keyword used in the text model. TODO&lt;br /&gt;
*Elimination of redundant equations in closed loop flows.&lt;br /&gt;
*:Multiple loops present in the system.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Still needs to be discussed. TODO&lt;br /&gt;
*Specifications of flow streams. &lt;br /&gt;
*:It should be possible to switch between stream components, water to CO2 to toluene for example.&lt;br /&gt;
*:This however should &#039;&#039;&#039;not&#039;&#039;&#039; involve redrawing the whole model again.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Streams can be defined in the canvas by selecting the particular connections and specifying the stream component, the connections to these components at the ports must use the values of stream component provided. TODO&lt;br /&gt;
*Providing complex flow streams.&lt;br /&gt;
*:A regenerative cycle requires to specify the fraction of steam extracted at the &#039;&#039;bled&#039;&#039; point, that is a TEE in our sense. Such a fraction must be supplied by the user while making such connections. Assuming an open feedwater scheme.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; This should be easy as a simple TEE component must have a fixable variable &#039;fraction&#039;.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*In this case connections may need to be manually specified in order to provide complex flows as required.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious.&lt;br /&gt;
**For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling of Servo Motor with backlash and PID control===&lt;br /&gt;
*TODO : Add description&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The new Gapahs 0.7.2 release till now seems to work fine.&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head 0.7.1. &lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
TODO : Keep adding details&lt;br /&gt;
&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
==Improvements on the Solving Process==&lt;br /&gt;
Since we have no Type informations the solving is done primarily by first generating a string representation of the complete MODEL and then exported to the solver. This can lead to problems while trying to solve complex models requiring a large time to solve, because each time a variable is changed the complete model has to solved again. In case of PyGTK GUI we have a more powerful interaction with the solver and thus can change parameters without discarding the already solved model. The basic problem here lies in the fact that we don&#039;t instantiate the model first and then solve it.&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified. This provides and excellent way to have the same model provide simulation for any number of streams. Two implementations have to be taken care of to specify streams;&lt;br /&gt;
*GUI implementation:&lt;br /&gt;
*:This would provide a suitable GUI to select the stream.&lt;br /&gt;
*Application level implementation&lt;br /&gt;
*:This would add actual stream modifications to the block code.&lt;br /&gt;
The [[#Simple Rankine Cycle]] could be solved simply by connecting steam_port connectors. The {{src|models/johnpye/rankine.a4c}} uses Steam as the only modelling stream. This model needs to be evolved to use generic port types so that a better and more deep understanding is achieved in the problem of specifying flow streams.&lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now.&lt;br /&gt;
&lt;br /&gt;
*To have highlighting of connectible ports while connecting two ports we need to:&lt;br /&gt;
*#Find all suitable (IN/OUT/BOTH) ports available for connection.&lt;br /&gt;
*#Create a set their Types.&lt;br /&gt;
*#Check connect-ability for each of those types.&lt;br /&gt;
*#Highlight only the connectible ones.&lt;br /&gt;
&lt;br /&gt;
*To give a set of units that can be selected from a drop down menu in block properties:&lt;br /&gt;
*#Scan for the Type of the parameter.&lt;br /&gt;
*#Get the dimensions of the type.&lt;br /&gt;
*#Scan for the units available. &lt;br /&gt;
&lt;br /&gt;
*Implementation&lt;br /&gt;
**Some testing has been done of the functions, see &amp;lt;code&amp;gt;test_type_info()&amp;lt;/code&amp;gt; function inside /compiler/test/test_basics.c&lt;br /&gt;
**The test can be run on any file, using &amp;lt;code&amp;gt;scons test &amp;amp;&amp;amp; test/test compiler_basics.type_info&amp;lt;/code&amp;gt;&lt;br /&gt;
**From the observations, it is clear that the function &amp;lt;code&amp;gt;GetChildList()&amp;lt;/code&amp;gt; works as it should in case of all user generated foreseeable canvas models.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
==Weekly Reports GSOC 2011==&lt;br /&gt;
&lt;br /&gt;
The weekly reports will be filed here. Week 0 starts from 24th of May up-to 30th of May and so on.&lt;br /&gt;
&lt;br /&gt;
====Week 0====&lt;br /&gt;
24th-May-10 to 30th-May-10&lt;br /&gt;
&lt;br /&gt;
====Week 1====&lt;br /&gt;
31st-May-10 to 6th-June-10&lt;br /&gt;
&lt;br /&gt;
====Week 2====&lt;br /&gt;
7th-June-10 to 13th-June-10&lt;br /&gt;
&lt;br /&gt;
====Week 3====&lt;br /&gt;
14th-June-10 to 20th-June-10&lt;br /&gt;
&lt;br /&gt;
====Week 4====&lt;br /&gt;
21st-June-10 to 27th-June-10&lt;br /&gt;
&lt;br /&gt;
====Week 5====&lt;br /&gt;
28th-June-10 to 4th-July-10&lt;br /&gt;
&lt;br /&gt;
====Week 6====&lt;br /&gt;
5th-July-10 to 11th-July-10&lt;br /&gt;
&lt;br /&gt;
====Week 7====&lt;br /&gt;
12th-July-10 to 18th-July-10&lt;br /&gt;
&lt;br /&gt;
====Week 8====&lt;br /&gt;
19th-July-10 to 25th-July-10&lt;br /&gt;
&lt;br /&gt;
====Week 9====&lt;br /&gt;
26th-July-10 to 1st-August-10&lt;br /&gt;
&lt;br /&gt;
====Week 10====&lt;br /&gt;
2nd-August-10 to 8th-August-10&lt;br /&gt;
&lt;br /&gt;
====Week 11====&lt;br /&gt;
9th-August-10 to 16th-August-10&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2545</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2545"/>
		<updated>2011-06-06T21:39:49Z</updated>

		<summary type="html">&lt;p&gt;Grivan: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 and current development carried out by [[Grivan Thapar]]. The goals and tasks for the GSoC period are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. The concerns are right now at setting up better mechanisms for parameter handling and design enhancements like handling of stream objects, globals etc.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
TODO : Add more ideas, put a concrete solution overview to each Case. Add new use cases based upon electronic circuit models sent over by Divyanshu.&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
*Global Model equations.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
*Block rotation.&lt;br /&gt;
*:It would be nice if blocks could be rotated, it makes the canvas look more tidy.&lt;br /&gt;
*Other Issues.&lt;br /&gt;
*:Just specifying a value and not Fixing it. Should it be possible? &lt;br /&gt;
*: How to make additions of equations to the MODEL more intuitive.&lt;br /&gt;
&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}} (NOTE: see also {{src|models/johnpye/fprops/rankine_fprops.a4c}} for newer version using [[FPROPS]] instead of [[freesteam]] -- JP). We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece. In addition take care of the ALIASES keyword used in the text model. TODO&lt;br /&gt;
*Elimination of redundant equations in closed loop flows.&lt;br /&gt;
*:Multiple loops present in the system.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Still needs to be discussed. TODO&lt;br /&gt;
*Specifications of flow streams. &lt;br /&gt;
*:It should be possible to switch between stream components, water to CO2 to toluene for example.&lt;br /&gt;
*:This however should &#039;&#039;&#039;not&#039;&#039;&#039; involve redrawing the whole model again.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Streams can be defined in the canvas by selecting the particular connections and specifying the stream component, the connections to these components at the ports must use the values of stream component provided. TODO&lt;br /&gt;
*Providing complex flow streams.&lt;br /&gt;
*:A regenerative cycle requires to specify the fraction of steam extracted at the &#039;&#039;bled&#039;&#039; point, that is a TEE in our sense. Such a fraction must be supplied by the user while making such connections. Assuming an open feedwater scheme.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; This should be easy as a simple TEE component must have a fixable variable &#039;fraction&#039;.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*In this case connections may need to be manually specified in order to provide complex flows as required.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious.&lt;br /&gt;
**For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling of Servo Motor with backlash and PID control===&lt;br /&gt;
*TODO : Add description&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The new Gapahs 0.7.2 release till now seems to work fine.&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head 0.7.1. &lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
TODO : Keep adding details&lt;br /&gt;
&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
==Improvements on the Solving Process==&lt;br /&gt;
Since we have no Type informations the solving is done primarily by first generating a string representation of the complete MODEL and then exported to the solver. This can lead to problems while trying to solve complex models requiring a large time to solve, because each time a variable is changed the complete model has to solved again. In case of PyGTK GUI we have a more powerful interaction with the solver and thus can change parameters without discarding the already solved model. The basic problem here lies in the fact that we don&#039;t instantiate the model first and then solve it.&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified. This provides and excellent way to have the same model provide simulation for any number of streams. Two implementations have to be taken care of to specify streams;&lt;br /&gt;
*GUI implementation:&lt;br /&gt;
*:This would provide a suitable GUI to select the stream.&lt;br /&gt;
*Application level implementation&lt;br /&gt;
*:This would add actual stream modifications to the block code.&lt;br /&gt;
The [[#Simple Rankine Cycle]] could be solved simply by connecting steam_port connectors. The {{src|models/johnpye/rankine.a4c}} uses Steam as the only modelling stream. This model needs to be evolved to use generic port types so that a better and more deep understanding is achieved in the problem of specifying flow streams.&lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now.&lt;br /&gt;
&lt;br /&gt;
*To have highlighting of connectible ports while connecting two ports we need to:&lt;br /&gt;
*#Find all suitable (IN/OUT/BOTH) ports available for connection.&lt;br /&gt;
*#Create a set their Types.&lt;br /&gt;
*#Check connect-ability for each of those types.&lt;br /&gt;
*#Highlight only the connectible ones.&lt;br /&gt;
&lt;br /&gt;
*To give a set of units that can be selected from a drop down menu in block properties:&lt;br /&gt;
*#Scan for the Type of the parameter.&lt;br /&gt;
*#Get the dimensions of the type.&lt;br /&gt;
*#Scan for the units available. &lt;br /&gt;
&lt;br /&gt;
*Implementation&lt;br /&gt;
**Some testing has been done of the functions, see &amp;lt;code&amp;gt;test_type_info()&amp;lt;/code&amp;gt; function inside /compiler/test/test_basics.c&lt;br /&gt;
**The test can be run on any file, using &amp;lt;code&amp;gt;scons test &amp;amp;&amp;amp; test/test compiler_basics.type_info&amp;lt;/code&amp;gt;&lt;br /&gt;
**From the observations, it is clear that the function &amp;lt;code&amp;gt;GetChildList()&amp;lt;/code&amp;gt; works as it should in case of all user generated foreseeable canvas models.&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Using_Gaphas_with_libavoid&amp;diff=2407</id>
		<title>Using Gaphas with libavoid</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Using_Gaphas_with_libavoid&amp;diff=2407"/>
		<updated>2011-05-21T21:40:21Z</updated>

		<summary type="html">&lt;p&gt;Grivan: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[http://adaptagrams.sourceforge.net/libavoid/ Libavoid] is a library that does 2D line-routing to avoid obstacles. [https://github.com/amolenaar/gaphas#readme Gaphas] is a canvas widget written in Python using [http://www.cairographics.org/ Cairo]. We use Gaphas in our [[canvas-based modeller]]. We would like now to incorporate Gaphas&#039; support for libavoid so that building diagrams on our canvas-based modeller is much easier to do.&lt;br /&gt;
&lt;br /&gt;
Gaphas is by Arjan Molenaar; Adaptagrams is by Michael Wybrow.&lt;br /&gt;
&lt;br /&gt;
This is still work in progress, so expect the instructions to change!&lt;br /&gt;
&lt;br /&gt;
== Building the Python wrapper of libavoid ==&lt;br /&gt;
&lt;br /&gt;
* Install Cython. You need 0.14 or later. For Ubuntu 10.04, you can use a PPA build [https://bugs.launchpad.net/~ukplc-team/+archive/ppa/+buildjob/2242269 from here]. It seems to also work with Ubuntu 9.10.&lt;br /&gt;
&lt;br /&gt;
* Obtain latest patched libavoid code from Arjan Molenaar using&lt;br /&gt;
&lt;br /&gt;
&amp;lt;source lang=sh&amp;gt;&lt;br /&gt;
git clone https://github.com/amolenaar/adaptagrams.git&lt;br /&gt;
cd adaptagrams/cola&lt;br /&gt;
git checkout -b cython origin/cython&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
&lt;br /&gt;
You will need to make a small change (tested on Ubuntu 9.10 and 10.04): add &amp;quot;#include &amp;lt;stdlib.h&amp;gt;&amp;quot; to assertions.h, just before &#039;#ifdef NDEBUG&#039;.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;source lang=sh&amp;gt;&lt;br /&gt;
python setup.py build_ext&lt;br /&gt;
sudo python setup.py install&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Building the patched version of Gaphas ==&lt;br /&gt;
&lt;br /&gt;
&amp;lt;source lang=sh&amp;gt;&lt;br /&gt;
git clone https://github.com/amolenaar/gaphas.git&lt;br /&gt;
cd gaphas&lt;br /&gt;
git checkout -b avoid origin/avoid&lt;br /&gt;
python setup.py build_ext&lt;br /&gt;
sudo python setup.py install&lt;br /&gt;
&amp;lt;/source&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Test libavoid with Gaphas ==&lt;br /&gt;
&lt;br /&gt;
From the &amp;lt;tt&amp;gt;gaphas&amp;lt;/tt&amp;gt; director avoid, just run &amp;quot;python avoid-demo.py&amp;quot;&lt;br /&gt;
&lt;br /&gt;
[[Category:Development]]&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=User:Grivan&amp;diff=2191</id>
		<title>User:Grivan</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=User:Grivan&amp;diff=2191"/>
		<updated>2011-04-19T16:47:32Z</updated>

		<summary type="html">&lt;p&gt;Grivan: /* Solving Process */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;&#039;Grivan Thapar&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Subversion Branch {{srcbranchdir|grivan|}} and {{srcbranchdir|grivan2|}}&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Current Work=&lt;br /&gt;
==Canvas==&lt;br /&gt;
===Parameter Handling===&lt;br /&gt;
There seems a possibility of using the NOTES and METHODS together to allow a suitable design solution to parameter handling.&lt;br /&gt;
&lt;br /&gt;
Using NOTES to make distinction between the parameters:&lt;br /&gt;
*How to best organize the parameters, required, standard etc&lt;br /&gt;
*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 &#039;front end&#039; for displaying the parameters&lt;br /&gt;
*There would be some changes in the BlockType class, but that would be easy.&lt;br /&gt;
&lt;br /&gt;
Using default METHODS for scaling and specifying default values for parameters:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 METHOD canvas_default;&lt;br /&gt;
  RUN pump1.default_self;&lt;br /&gt;
  RUN condenser1.default_self;&lt;br /&gt;
 END canvas_default;&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Here the &amp;lt;code&amp;gt;pump1.default_self&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;condenser1.default_self&amp;lt;/code&amp;gt; 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.&lt;br /&gt;
&lt;br /&gt;
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:&lt;br /&gt;
&lt;br /&gt;
*How to use both the default methods and the parameter tab in blockproperties?&lt;br /&gt;
*What if the user selects the a default method and also fixes a parameter separately?&lt;br /&gt;
*What if the default method fails in some different configuration of a canvas model?&lt;br /&gt;
*What if something we have set as required can also be solved for?&lt;br /&gt;
&lt;br /&gt;
Using the two above things together will let us into hopefully a good design solution for the parameters.&lt;br /&gt;
&lt;br /&gt;
===Solving Process===&lt;br /&gt;
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.&lt;br /&gt;
*Have to deal with the &#039;instances&#039; 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.&lt;br /&gt;
*Checks for unconnected ports and line connectors.&lt;br /&gt;
*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).&lt;br /&gt;
&lt;br /&gt;
===Other Tasks===&lt;br /&gt;
#Set up canvas to use the new libavoid bindings. Although could be done before, in case the libavoid bindings are completed.&lt;br /&gt;
#For Undo need to look for better method for segregating transactions, only some more tweaking should be necessary.&lt;br /&gt;
#We have&#039;t applied proper Type checking, its just the string names that are being compared, we could use much earlier Ben&#039;s suggestion of having a GUI policy that supports Type checking at the ASCEND level.&lt;br /&gt;
#User defined shapes of the &#039;blocks&#039;, this was proposed last year but not completed, we will have to take care though of libavoid limitations here though.&lt;br /&gt;
#Other smaller GUI improvements, embedding the Canvas into main GUI, more model libraries etc.&lt;br /&gt;
&lt;br /&gt;
=Past Work=&lt;br /&gt;
&lt;br /&gt;
==GSoC 2010 Participation==&lt;br /&gt;
GSoC 2010 Proposal: [http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/ascend/t127230757715 Improvement on Canvas-based modelling for Ascend] &amp;lt;br&amp;gt; See [[Canvas-based modeller for ASCEND]] for more information.&lt;br /&gt;
&amp;lt;br&amp;gt;Mentor: [[John Pye]]&lt;br /&gt;
&lt;br /&gt;
=== Goals ===&lt;br /&gt;
&lt;br /&gt;
Improvement on Canvas-based modeling:&lt;br /&gt;
* Updating the graphical flow sheet modeler.&lt;br /&gt;
* Enhancing its usability and functionality.&lt;br /&gt;
* Making it more robust.&lt;br /&gt;
&lt;br /&gt;
=== Tasks ===&lt;br /&gt;
&lt;br /&gt;
* Initially before coding address the necessary prerequisites that I will discuss with the Ascend team and have solutions ready to be implemented as follows;&lt;br /&gt;
* 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.&lt;br /&gt;
* Solution of the redundant equations in case of equality loops. The current method of &#039;Methods&#039; be either modified or updated, for easy debugging of the models.&lt;br /&gt;
* To specify the &#039;global&#039; variables for generic models, like streams in a turbine. Every such &#039;general&#039; 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.&lt;br /&gt;
* 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.&lt;br /&gt;
* Define a set number of generic models that could added so that using Ascend Canvas based modeler becomes a head-start process.&lt;br /&gt;
* 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.&lt;br /&gt;
&lt;br /&gt;
By mid-term review:&lt;br /&gt;
* 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.&lt;br /&gt;
* Do the GUI usability improvements. Undo, Redo, Save image etc.&lt;br /&gt;
* Code for a suitable framework for importing new models into the pallet from a specified location.&lt;br /&gt;
* Code for the solution of the type checking problem.&lt;br /&gt;
* Unit tests of features implemented.&lt;br /&gt;
* Start to code for defining the global variables for each of the generic block sub-model.&lt;br /&gt;
&lt;br /&gt;
By final-term review:&lt;br /&gt;
* Complete the code for setting the global variables for generic models.&lt;br /&gt;
* Code for efficient debugging of models with closed circulation loops.&lt;br /&gt;
* Code for the type checking.&lt;br /&gt;
* Unit tests of features implemented.&lt;br /&gt;
* Add new blocks of models.&lt;br /&gt;
* Final testing of the code, final integration to the /trunk code, documentation.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
 &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Category:GSOC2010]]&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=User:Grivan&amp;diff=2109</id>
		<title>User:Grivan</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=User:Grivan&amp;diff=2109"/>
		<updated>2011-04-07T22:17:21Z</updated>

		<summary type="html">&lt;p&gt;Grivan: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;&#039;Grivan Thapar&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Subversion Branch {{srcbranch|grivan|}} and {{srcbranch|grivan2|}}&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Current Work=&lt;br /&gt;
==Canvas==&lt;br /&gt;
===Parameter Handling===&lt;br /&gt;
There seems a possibility of using the NOTES and METHODS together to allow a suitable design solution to parameter handling.&lt;br /&gt;
&lt;br /&gt;
Using NOTES to make distinction between the parameters:&lt;br /&gt;
*How to best organize the parameters, required, standard etc&lt;br /&gt;
*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 &#039;front end&#039; for displaying the parameters&lt;br /&gt;
*There would be some changes in the BlockType class, but that would be easy.&lt;br /&gt;
&lt;br /&gt;
Using default METHODS for scaling and specifying default values for parameters:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 METHOD canvas_default;&lt;br /&gt;
  RUN pump1.default_self;&lt;br /&gt;
  RUN condenser1.default_self;&lt;br /&gt;
 END canvas_default;&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Here the &amp;lt;code&amp;gt;pump1.default_self&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;condenser1.default_self&amp;lt;/code&amp;gt; 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.&lt;br /&gt;
&lt;br /&gt;
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:&lt;br /&gt;
&lt;br /&gt;
*How to use both the default methods and the parameter tab in blockproperties?&lt;br /&gt;
*What if the user selects the a default method and also fixes a parameter separately?&lt;br /&gt;
*What if the default method fails in some different configuration of a canvas model?&lt;br /&gt;
*What if something we have set as required can also be solved for?&lt;br /&gt;
&lt;br /&gt;
Using the two above things together will let us into hopefully a good design solution for the parameters.&lt;br /&gt;
&lt;br /&gt;
===Solving Process===&lt;br /&gt;
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.&lt;br /&gt;
*Checks for unconnected ports and line connectors.&lt;br /&gt;
*Making solving Undo proof, last year I did not have enough time to &#039;unsolve&#039; the model if there is an Undo just after solving process.&lt;br /&gt;
*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).&lt;br /&gt;
&lt;br /&gt;
===Other Tasks===&lt;br /&gt;
#Set up canvas to use the new libavoid bindings. Although could be done before, in case the libavoid bindings are completed.&lt;br /&gt;
#For Undo need to look for better method for segregating transactions, only some more tweaking should be necessary.&lt;br /&gt;
#We have&#039;t applied proper Type checking, its just the string names that are being compared, we could use much earlier Ben&#039;s suggestion of having a GUI policy that supports Type checking at the ASCEND level.&lt;br /&gt;
#User defined shapes of the &#039;blocks&#039;, this was proposed last year but not completed, we will have to take care though of libavoid limitations here though.&lt;br /&gt;
#Other smaller GUI improvements, embedding the Canvas into main GUI, more model libraries etc.&lt;br /&gt;
&lt;br /&gt;
=Past Work=&lt;br /&gt;
&lt;br /&gt;
==GSoC 2010 Participation==&lt;br /&gt;
GSoC 2010 Proposal: [http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/ascend/t127230757715 Improvement on Canvas-based modelling for Ascend] &amp;lt;br&amp;gt; See [[Canvas-based modeller for ASCEND]] for more information.&lt;br /&gt;
&amp;lt;br&amp;gt;Mentor: [[John Pye]]&lt;br /&gt;
&lt;br /&gt;
=== Goals ===&lt;br /&gt;
&lt;br /&gt;
Improvement on Canvas-based modeling:&lt;br /&gt;
* Updating the graphical flow sheet modeler.&lt;br /&gt;
* Enhancing its usability and functionality.&lt;br /&gt;
* Making it more robust.&lt;br /&gt;
&lt;br /&gt;
=== Tasks ===&lt;br /&gt;
&lt;br /&gt;
* Initially before coding address the necessary prerequisites that I will discuss with the Ascend team and have solutions ready to be implemented as follows;&lt;br /&gt;
* 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.&lt;br /&gt;
* Solution of the redundant equations in case of equality loops. The current method of &#039;Methods&#039; be either modified or updated, for easy debugging of the models.&lt;br /&gt;
* To specify the &#039;global&#039; variables for generic models, like streams in a turbine. Every such &#039;general&#039; 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.&lt;br /&gt;
* 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.&lt;br /&gt;
* Define a set number of generic models that could added so that using Ascend Canvas based modeler becomes a head-start process.&lt;br /&gt;
* 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.&lt;br /&gt;
&lt;br /&gt;
By mid-term review:&lt;br /&gt;
* 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.&lt;br /&gt;
* Do the GUI usability improvements. Undo, Redo, Save image etc.&lt;br /&gt;
* Code for a suitable framework for importing new models into the pallet from a specified location.&lt;br /&gt;
* Code for the solution of the type checking problem.&lt;br /&gt;
* Unit tests of features implemented.&lt;br /&gt;
* Start to code for defining the global variables for each of the generic block sub-model.&lt;br /&gt;
&lt;br /&gt;
By final-term review:&lt;br /&gt;
* Complete the code for setting the global variables for generic models.&lt;br /&gt;
* Code for efficient debugging of models with closed circulation loops.&lt;br /&gt;
* Code for the type checking.&lt;br /&gt;
* Unit tests of features implemented.&lt;br /&gt;
* Add new blocks of models.&lt;br /&gt;
* Final testing of the code, final integration to the /trunk code, documentation.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
 &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Category:GSOC2010]]&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=User:Grivan&amp;diff=2108</id>
		<title>User:Grivan</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=User:Grivan&amp;diff=2108"/>
		<updated>2011-04-07T22:15:36Z</updated>

		<summary type="html">&lt;p&gt;Grivan: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;&#039;Grivan Thapar&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
GSoC 2010 Proposal: [http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/ascend/t127230757715 Improvement on Canvas-based modelling for Ascend] &amp;lt;br&amp;gt; See [[Canvas-based modeller for ASCEND]] for more information.&lt;br /&gt;
&lt;br /&gt;
Mentor: [[John Pye]]&lt;br /&gt;
&lt;br /&gt;
Subversion Branch {{srcbranch|grivan|}} and {{srcbranch|grivan2|}}&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Current Work=&lt;br /&gt;
==Canvas==&lt;br /&gt;
===Parameter Handling===&lt;br /&gt;
There seems a possibility of using the NOTES and METHODS together to allow a suitable design solution to parameter handling.&lt;br /&gt;
&lt;br /&gt;
Using NOTES to make distinction between the parameters:&lt;br /&gt;
*How to best organize the parameters, required, standard etc&lt;br /&gt;
*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 &#039;front end&#039; for displaying the parameters&lt;br /&gt;
*There would be some changes in the BlockType class, but that would be easy.&lt;br /&gt;
&lt;br /&gt;
Using default METHODS for scaling and specifying default values for parameters:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 METHOD canvas_default;&lt;br /&gt;
  RUN pump1.default_self;&lt;br /&gt;
  RUN condenser1.default_self;&lt;br /&gt;
 END canvas_default;&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Here the &amp;lt;code&amp;gt;pump1.default_self&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;condenser1.default_self&amp;lt;/code&amp;gt; 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.&lt;br /&gt;
&lt;br /&gt;
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:&lt;br /&gt;
&lt;br /&gt;
*How to use both the default methods and the parameter tab in blockproperties?&lt;br /&gt;
*What if the user selects the a default method and also fixes a parameter separately?&lt;br /&gt;
*What if the default method fails in some different configuration of a canvas model?&lt;br /&gt;
*What if something we have set as required can also be solved for?&lt;br /&gt;
&lt;br /&gt;
Using the two above things together will let us into hopefully a good design solution for the parameters.&lt;br /&gt;
&lt;br /&gt;
===Solving Process===&lt;br /&gt;
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.&lt;br /&gt;
*Checks for unconnected ports and line connectors.&lt;br /&gt;
*Making solving Undo proof, last year I did not have enough time to &#039;unsolve&#039; the model if there is an Undo just after solving process.&lt;br /&gt;
*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).&lt;br /&gt;
&lt;br /&gt;
===Other Tasks===&lt;br /&gt;
#Set up canvas to use the new libavoid bindings. Although could be done before, in case the libavoid bindings are completed.&lt;br /&gt;
#For Undo need to look for better method for segregating transactions, only some more tweaking should be necessary.&lt;br /&gt;
#We have&#039;t applied proper Type checking, its just the string names that are being compared, we could use much earlier Ben&#039;s suggestion of having a GUI policy that supports Type checking at the ASCEND level.&lt;br /&gt;
#User defined shapes of the &#039;blocks&#039;, this was proposed last year but not completed, we will have to take care though of libavoid limitations here though.&lt;br /&gt;
#Other smaller GUI improvements, embedding the Canvas into main GUI, more model libraries etc.&lt;br /&gt;
&lt;br /&gt;
=Past Work=&lt;br /&gt;
&lt;br /&gt;
==GSoC 2010 Participation==&lt;br /&gt;
&lt;br /&gt;
=== Goals ===&lt;br /&gt;
&lt;br /&gt;
Improvement on Canvas-based modeling:&lt;br /&gt;
* Updating the graphical flow sheet modeler.&lt;br /&gt;
* Enhancing its usability and functionality.&lt;br /&gt;
* Making it more robust.&lt;br /&gt;
&lt;br /&gt;
=== Tasks ===&lt;br /&gt;
&lt;br /&gt;
* Initially before coding address the necessary prerequisites that I will discuss with the Ascend team and have solutions ready to be implemented as follows;&lt;br /&gt;
* 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.&lt;br /&gt;
* Solution of the redundant equations in case of equality loops. The current method of &#039;Methods&#039; be either modified or updated, for easy debugging of the models.&lt;br /&gt;
* To specify the &#039;global&#039; variables for generic models, like streams in a turbine. Every such &#039;general&#039; 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.&lt;br /&gt;
* 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.&lt;br /&gt;
* Define a set number of generic models that could added so that using Ascend Canvas based modeler becomes a head-start process.&lt;br /&gt;
* 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.&lt;br /&gt;
&lt;br /&gt;
By mid-term review:&lt;br /&gt;
* 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.&lt;br /&gt;
* Do the GUI usability improvements. Undo, Redo, Save image etc.&lt;br /&gt;
* Code for a suitable framework for importing new models into the pallet from a specified location.&lt;br /&gt;
* Code for the solution of the type checking problem.&lt;br /&gt;
* Unit tests of features implemented.&lt;br /&gt;
* Start to code for defining the global variables for each of the generic block sub-model.&lt;br /&gt;
&lt;br /&gt;
By final-term review:&lt;br /&gt;
* Complete the code for setting the global variables for generic models.&lt;br /&gt;
* Code for efficient debugging of models with closed circulation loops.&lt;br /&gt;
* Code for the type checking.&lt;br /&gt;
* Unit tests of features implemented.&lt;br /&gt;
* Add new blocks of models.&lt;br /&gt;
* Final testing of the code, final integration to the /trunk code, documentation.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
 &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Category:GSOC2010]]&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=User:Grivan&amp;diff=2107</id>
		<title>User:Grivan</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=User:Grivan&amp;diff=2107"/>
		<updated>2011-04-07T22:13:57Z</updated>

		<summary type="html">&lt;p&gt;Grivan: /* Canvas */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;&#039;Grivan Thapar&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
GSoC 2010 Proposal: [http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/ascend/t127230757715 Improvement on Canvas-based modelling for Ascend] &amp;lt;br&amp;gt; See [[Canvas-based modeller for ASCEND]] for more information.&lt;br /&gt;
&lt;br /&gt;
Mentor: [[John Pye]]&lt;br /&gt;
&lt;br /&gt;
Subversion Branch {{srcbranch|grivan|}} and {{srcbranch|grivan2|}}&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Current Work=&lt;br /&gt;
==Canvas==&lt;br /&gt;
===Parameter Handling===&lt;br /&gt;
There seems a possibility of using the NOTES and METHODS together to allow a suitable design solution to parameter handling.&lt;br /&gt;
&lt;br /&gt;
Using NOTES to make distinction between the parameters:&lt;br /&gt;
*How to best organize the parameters, required, standard etc&lt;br /&gt;
*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 &#039;front end&#039; for displaying the parameters&lt;br /&gt;
*There would be some changes in the BlockType class, but that would be easy.&lt;br /&gt;
&lt;br /&gt;
Using default METHODS for scaling and specifying default values for parameters:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 METHOD canvas_default;&lt;br /&gt;
  RUN pump1.default_self;&lt;br /&gt;
  RUN condenser1.default_self;&lt;br /&gt;
 END canvas_default;&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Here the &amp;lt;code&amp;gt;pump1.default_self&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;condenser1.default_self&amp;lt;/code&amp;gt; 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.&lt;br /&gt;
&lt;br /&gt;
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:&lt;br /&gt;
&lt;br /&gt;
*How to use both the default methods and the parameter tab in blockproperties?&lt;br /&gt;
*What if the user selects the a default method and also fixes a parameter separately?&lt;br /&gt;
*What if the default method fails in some different configuration of a canvas model?&lt;br /&gt;
*What if something we have set as required can also be solved for?&lt;br /&gt;
&lt;br /&gt;
Using the two above things together will let us into hopefully a good design solution for the parameters.&lt;br /&gt;
&lt;br /&gt;
===Solving Process===&lt;br /&gt;
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.&lt;br /&gt;
*Checks for unconnected ports and line connectors.&lt;br /&gt;
*Making solving Undo proof, last year I did not have enough time to &#039;unsolve&#039; the model if there is an Undo just after solving process.&lt;br /&gt;
*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).&lt;br /&gt;
&lt;br /&gt;
===Other Tasks===&lt;br /&gt;
#Set up canvas to use the new libavoid bindings. Although could be done before, in case the libavoid bindings are completed.&lt;br /&gt;
#For Undo need to look for better method for segregating transactions, only some more tweaking should be necessary.&lt;br /&gt;
#We have&#039;t applied proper Type checking, its just the string names that are being compared, we could use much earlier Ben&#039;s suggestion of having a GUI policy that supports Type checking at the ASCEND level.&lt;br /&gt;
#User defined shapes of the &#039;blocks&#039;, this was proposed last year but not completed, we will have to take care though of libavoid limitations here though.&lt;br /&gt;
#Other smaller GUI improvements, embedding the Canvas into main GUI, more model libraries etc.&lt;br /&gt;
&lt;br /&gt;
=GSoC 2010 Participation=&lt;br /&gt;
&lt;br /&gt;
== Goals ==&lt;br /&gt;
&lt;br /&gt;
Improvement on Canvas-based modeling:&lt;br /&gt;
* Updating the graphical flow sheet modeler.&lt;br /&gt;
* Enhancing its usability and functionality.&lt;br /&gt;
* Making it more robust.&lt;br /&gt;
&lt;br /&gt;
== Tasks ==&lt;br /&gt;
&lt;br /&gt;
* Initially before coding address the necessary prerequisites that I will discuss with the Ascend team and have solutions ready to be implemented as follows;&lt;br /&gt;
* 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.&lt;br /&gt;
* Solution of the redundant equations in case of equality loops. The current method of &#039;Methods&#039; be either modified or updated, for easy debugging of the models.&lt;br /&gt;
* To specify the &#039;global&#039; variables for generic models, like streams in a turbine. Every such &#039;general&#039; 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.&lt;br /&gt;
* 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.&lt;br /&gt;
* Define a set number of generic models that could added so that using Ascend Canvas based modeler becomes a head-start process.&lt;br /&gt;
* 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.&lt;br /&gt;
&lt;br /&gt;
By mid-term review:&lt;br /&gt;
* 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.&lt;br /&gt;
* Do the GUI usability improvements. Undo, Redo, Save image etc.&lt;br /&gt;
* Code for a suitable framework for importing new models into the pallet from a specified location.&lt;br /&gt;
* Code for the solution of the type checking problem.&lt;br /&gt;
* Unit tests of features implemented.&lt;br /&gt;
* Start to code for defining the global variables for each of the generic block sub-model.&lt;br /&gt;
&lt;br /&gt;
By final-term review:&lt;br /&gt;
* Complete the code for setting the global variables for generic models.&lt;br /&gt;
* Code for efficient debugging of models with closed circulation loops.&lt;br /&gt;
* Code for the type checking.&lt;br /&gt;
* Unit tests of features implemented.&lt;br /&gt;
* Add new blocks of models.&lt;br /&gt;
* Final testing of the code, final integration to the /trunk code, documentation.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
 &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Category:GSOC2010]]&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=User:Grivan&amp;diff=2106</id>
		<title>User:Grivan</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=User:Grivan&amp;diff=2106"/>
		<updated>2011-04-07T22:08:54Z</updated>

		<summary type="html">&lt;p&gt;Grivan: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;&#039;Grivan Thapar&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
GSoC 2010 Proposal: [http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/ascend/t127230757715 Improvement on Canvas-based modelling for Ascend] &amp;lt;br&amp;gt; See [[Canvas-based modeller for ASCEND]] for more information.&lt;br /&gt;
&lt;br /&gt;
Mentor: [[John Pye]]&lt;br /&gt;
&lt;br /&gt;
Subversion Branch {{srcbranch|grivan|}} and {{srcbranch|grivan2|}}&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Current Work=&lt;br /&gt;
==Canvas==&lt;br /&gt;
===Parameter Handling===&lt;br /&gt;
There seems a possibility of using the NOTES and METHODS together to allow a suitable design solution to parameter handling.&lt;br /&gt;
&lt;br /&gt;
Using NOTES to make distinction between the parameters:&lt;br /&gt;
*How to best organize the parameters, required, standard etc&lt;br /&gt;
*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 &#039;front end&#039; for displaying the parameters&lt;br /&gt;
*There would be some changes in the BlockType class, but that would be easy.&lt;br /&gt;
&lt;br /&gt;
Using default METHODS for scaling and specifying default values for parameters:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 METHOD canvas_default;&lt;br /&gt;
  RUN pump1.default_self;&lt;br /&gt;
  RUN condenser1.default_self;&lt;br /&gt;
 END canvas_default;&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Here the &amp;lt;code&amp;gt;pump1.default_self&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;condenser1.default_self&amp;lt;/code&amp;gt; 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.&lt;br /&gt;
&lt;br /&gt;
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:&lt;br /&gt;
&lt;br /&gt;
*How to use both the default methods and the parameter tab in blockproperties?&lt;br /&gt;
*What if the user selects the a default method and also fixes a parameter separately?&lt;br /&gt;
*What if the default method fails in some different configuration of a canvas model?&lt;br /&gt;
*What if something we have set as required can also be solved for?&lt;br /&gt;
&lt;br /&gt;
Using the two above things together will let us into hopefully a good design solution for the parameters.&lt;br /&gt;
&lt;br /&gt;
===Solving Process===&lt;br /&gt;
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.&lt;br /&gt;
*Checks for unconnected ports and line connectors.&lt;br /&gt;
*Making solving Undo proof, last year I did not have enough time to &#039;unsolve&#039; the model if there is an Undo just after solving process.&lt;br /&gt;
*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).&lt;br /&gt;
&lt;br /&gt;
=GSoC 2010 Participation=&lt;br /&gt;
&lt;br /&gt;
== Goals ==&lt;br /&gt;
&lt;br /&gt;
Improvement on Canvas-based modeling:&lt;br /&gt;
* Updating the graphical flow sheet modeler.&lt;br /&gt;
* Enhancing its usability and functionality.&lt;br /&gt;
* Making it more robust.&lt;br /&gt;
&lt;br /&gt;
== Tasks ==&lt;br /&gt;
&lt;br /&gt;
* Initially before coding address the necessary prerequisites that I will discuss with the Ascend team and have solutions ready to be implemented as follows;&lt;br /&gt;
* 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.&lt;br /&gt;
* Solution of the redundant equations in case of equality loops. The current method of &#039;Methods&#039; be either modified or updated, for easy debugging of the models.&lt;br /&gt;
* To specify the &#039;global&#039; variables for generic models, like streams in a turbine. Every such &#039;general&#039; 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.&lt;br /&gt;
* 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.&lt;br /&gt;
* Define a set number of generic models that could added so that using Ascend Canvas based modeler becomes a head-start process.&lt;br /&gt;
* 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.&lt;br /&gt;
&lt;br /&gt;
By mid-term review:&lt;br /&gt;
* 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.&lt;br /&gt;
* Do the GUI usability improvements. Undo, Redo, Save image etc.&lt;br /&gt;
* Code for a suitable framework for importing new models into the pallet from a specified location.&lt;br /&gt;
* Code for the solution of the type checking problem.&lt;br /&gt;
* Unit tests of features implemented.&lt;br /&gt;
* Start to code for defining the global variables for each of the generic block sub-model.&lt;br /&gt;
&lt;br /&gt;
By final-term review:&lt;br /&gt;
* Complete the code for setting the global variables for generic models.&lt;br /&gt;
* Code for efficient debugging of models with closed circulation loops.&lt;br /&gt;
* Code for the type checking.&lt;br /&gt;
* Unit tests of features implemented.&lt;br /&gt;
* Add new blocks of models.&lt;br /&gt;
* Final testing of the code, final integration to the /trunk code, documentation.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
 &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Category:GSOC2010]]&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=User:Grivan&amp;diff=2105</id>
		<title>User:Grivan</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=User:Grivan&amp;diff=2105"/>
		<updated>2011-04-07T22:08:20Z</updated>

		<summary type="html">&lt;p&gt;Grivan: /* Canvas */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;&#039;Grivan Thapar&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
GSoC 2010 Proposal: [http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/ascend/t127230757715 Improvement on Canvas-based modelling for Ascend] &amp;lt;br&amp;gt; See [[Canvas-based modeller for ASCEND]] for more information.&lt;br /&gt;
&lt;br /&gt;
Mentor: [[John Pye]]&lt;br /&gt;
&lt;br /&gt;
Subversion Branch {{srcbranch|grivan|}}&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Current Work=&lt;br /&gt;
==Canvas==&lt;br /&gt;
===Parameter Handling===&lt;br /&gt;
There seems a possibility of using the NOTES and METHODS together to allow a suitable design solution to parameter handling.&lt;br /&gt;
&lt;br /&gt;
Using NOTES to make distinction between the parameters:&lt;br /&gt;
*How to best organize the parameters, required, standard etc&lt;br /&gt;
*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 &#039;front end&#039; for displaying the parameters&lt;br /&gt;
*There would be some changes in the BlockType class, but that would be easy.&lt;br /&gt;
&lt;br /&gt;
Using default METHODS for scaling and specifying default values for parameters:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 METHOD canvas_default;&lt;br /&gt;
  RUN pump1.default_self;&lt;br /&gt;
  RUN condenser1.default_self;&lt;br /&gt;
 END canvas_default;&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Here the &amp;lt;code&amp;gt;pump1.default_self&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;condenser1.default_self&amp;lt;/code&amp;gt; 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.&lt;br /&gt;
&lt;br /&gt;
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:&lt;br /&gt;
&lt;br /&gt;
*How to use both the default methods and the parameter tab in blockproperties?&lt;br /&gt;
*What if the user selects the a default method and also fixes a parameter separately?&lt;br /&gt;
*What if the default method fails in some different configuration of a canvas model?&lt;br /&gt;
*What if something we have set as required can also be solved for?&lt;br /&gt;
&lt;br /&gt;
Using the two above things together will let us into hopefully a good design solution for the parameters.&lt;br /&gt;
&lt;br /&gt;
===Solving Process===&lt;br /&gt;
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.&lt;br /&gt;
*Checks for unconnected ports and line connectors.&lt;br /&gt;
*Making solving Undo proof, last year I did not have enough time to &#039;unsolve&#039; the model if there is an Undo just after solving process.&lt;br /&gt;
*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).&lt;br /&gt;
&lt;br /&gt;
=GSoC 2010 Participation=&lt;br /&gt;
&lt;br /&gt;
== Goals ==&lt;br /&gt;
&lt;br /&gt;
Improvement on Canvas-based modeling:&lt;br /&gt;
* Updating the graphical flow sheet modeler.&lt;br /&gt;
* Enhancing its usability and functionality.&lt;br /&gt;
* Making it more robust.&lt;br /&gt;
&lt;br /&gt;
== Tasks ==&lt;br /&gt;
&lt;br /&gt;
* Initially before coding address the necessary prerequisites that I will discuss with the Ascend team and have solutions ready to be implemented as follows;&lt;br /&gt;
* 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.&lt;br /&gt;
* Solution of the redundant equations in case of equality loops. The current method of &#039;Methods&#039; be either modified or updated, for easy debugging of the models.&lt;br /&gt;
* To specify the &#039;global&#039; variables for generic models, like streams in a turbine. Every such &#039;general&#039; 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.&lt;br /&gt;
* 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.&lt;br /&gt;
* Define a set number of generic models that could added so that using Ascend Canvas based modeler becomes a head-start process.&lt;br /&gt;
* 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.&lt;br /&gt;
&lt;br /&gt;
By mid-term review:&lt;br /&gt;
* 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.&lt;br /&gt;
* Do the GUI usability improvements. Undo, Redo, Save image etc.&lt;br /&gt;
* Code for a suitable framework for importing new models into the pallet from a specified location.&lt;br /&gt;
* Code for the solution of the type checking problem.&lt;br /&gt;
* Unit tests of features implemented.&lt;br /&gt;
* Start to code for defining the global variables for each of the generic block sub-model.&lt;br /&gt;
&lt;br /&gt;
By final-term review:&lt;br /&gt;
* Complete the code for setting the global variables for generic models.&lt;br /&gt;
* Code for efficient debugging of models with closed circulation loops.&lt;br /&gt;
* Code for the type checking.&lt;br /&gt;
* Unit tests of features implemented.&lt;br /&gt;
* Add new blocks of models.&lt;br /&gt;
* Final testing of the code, final integration to the /trunk code, documentation.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
 &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Category:GSOC2010]]&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=User:Grivan&amp;diff=2104</id>
		<title>User:Grivan</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=User:Grivan&amp;diff=2104"/>
		<updated>2011-04-07T22:00:48Z</updated>

		<summary type="html">&lt;p&gt;Grivan: /* Parameter Handling */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;&#039;Grivan Thapar&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
GSoC 2010 Proposal: [http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/ascend/t127230757715 Improvement on Canvas-based modelling for Ascend] &amp;lt;br&amp;gt; See [[Canvas-based modeller for ASCEND]] for more information.&lt;br /&gt;
&lt;br /&gt;
Mentor: [[John Pye]]&lt;br /&gt;
&lt;br /&gt;
Subversion Branch {{srcbranch|grivan|}}&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Current Work=&lt;br /&gt;
==Canvas==&lt;br /&gt;
===Parameter Handling===&lt;br /&gt;
There seems a possibility of using the NOTES and METHODS together to allow a suitable design solution to parameter handling.&lt;br /&gt;
&lt;br /&gt;
Using NOTES to make distinction between the parameters:&lt;br /&gt;
*How to best organize the parameters, required, standard etc&lt;br /&gt;
*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 &#039;front end&#039; for displaying the parameters&lt;br /&gt;
*There would be some changes in the BlockType class, but that would be easy.&lt;br /&gt;
&lt;br /&gt;
Using default METHODS for scaling and specifying default values for parameters:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;&lt;br /&gt;
 METHOD canvas_default;&lt;br /&gt;
  RUN pump1.default_self;&lt;br /&gt;
  RUN condenser1.default_self;&lt;br /&gt;
 END canvas_default;&lt;br /&gt;
&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Here the &amp;lt;code&amp;gt;pump1.default_self&amp;lt;/code&amp;gt; and &amp;lt;code&amp;gt;condenser1.default_self&amp;lt;/code&amp;gt; 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.&lt;br /&gt;
&lt;br /&gt;
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:&lt;br /&gt;
&lt;br /&gt;
*How to use both the default methods and the parameter tab in blockproperties.&lt;br /&gt;
*What if the user selects the a default method and also fixes a parameter separately.&lt;br /&gt;
*What if the default method fails in some different configuration of a canvas model.&lt;br /&gt;
*What if something we have set as required can also be solved for?&lt;br /&gt;
&lt;br /&gt;
Using the two above things together will let us into hopefully a good design solution for the parameters.&lt;br /&gt;
&lt;br /&gt;
=GSoC 2010 Participation=&lt;br /&gt;
&lt;br /&gt;
== Goals ==&lt;br /&gt;
&lt;br /&gt;
Improvement on Canvas-based modeling:&lt;br /&gt;
* Updating the graphical flow sheet modeler.&lt;br /&gt;
* Enhancing its usability and functionality.&lt;br /&gt;
* Making it more robust.&lt;br /&gt;
&lt;br /&gt;
== Tasks ==&lt;br /&gt;
&lt;br /&gt;
* Initially before coding address the necessary prerequisites that I will discuss with the Ascend team and have solutions ready to be implemented as follows;&lt;br /&gt;
* 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.&lt;br /&gt;
* Solution of the redundant equations in case of equality loops. The current method of &#039;Methods&#039; be either modified or updated, for easy debugging of the models.&lt;br /&gt;
* To specify the &#039;global&#039; variables for generic models, like streams in a turbine. Every such &#039;general&#039; 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.&lt;br /&gt;
* 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.&lt;br /&gt;
* Define a set number of generic models that could added so that using Ascend Canvas based modeler becomes a head-start process.&lt;br /&gt;
* 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.&lt;br /&gt;
&lt;br /&gt;
By mid-term review:&lt;br /&gt;
* 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.&lt;br /&gt;
* Do the GUI usability improvements. Undo, Redo, Save image etc.&lt;br /&gt;
* Code for a suitable framework for importing new models into the pallet from a specified location.&lt;br /&gt;
* Code for the solution of the type checking problem.&lt;br /&gt;
* Unit tests of features implemented.&lt;br /&gt;
* Start to code for defining the global variables for each of the generic block sub-model.&lt;br /&gt;
&lt;br /&gt;
By final-term review:&lt;br /&gt;
* Complete the code for setting the global variables for generic models.&lt;br /&gt;
* Code for efficient debugging of models with closed circulation loops.&lt;br /&gt;
* Code for the type checking.&lt;br /&gt;
* Unit tests of features implemented.&lt;br /&gt;
* Add new blocks of models.&lt;br /&gt;
* Final testing of the code, final integration to the /trunk code, documentation.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
 &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Category:GSOC2010]]&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=User:Grivan&amp;diff=2103</id>
		<title>User:Grivan</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=User:Grivan&amp;diff=2103"/>
		<updated>2011-04-07T21:54:38Z</updated>

		<summary type="html">&lt;p&gt;Grivan: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;&#039;Grivan Thapar&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
GSoC 2010 Proposal: [http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/ascend/t127230757715 Improvement on Canvas-based modelling for Ascend] &amp;lt;br&amp;gt; See [[Canvas-based modeller for ASCEND]] for more information.&lt;br /&gt;
&lt;br /&gt;
Mentor: [[John Pye]]&lt;br /&gt;
&lt;br /&gt;
Subversion Branch {{srcbranch|grivan|}}&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Current Work=&lt;br /&gt;
==Canvas==&lt;br /&gt;
===Parameter Handling===&lt;br /&gt;
There seems a possibility of using the NOTES and METHODS together to allow a suitable design solution to parameter handling.&lt;br /&gt;
&lt;br /&gt;
Using NOTES to make distinction between the parameters:&lt;br /&gt;
*How to best organize the parameters, required, standard etc&lt;br /&gt;
*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 &#039;front end&#039; for displaying the parameters&lt;br /&gt;
*There would be some changes in the BlockType class, but that would be easy.&lt;br /&gt;
&lt;br /&gt;
Using default METHODS for scaling and specifying default values for parameters:&lt;br /&gt;
&lt;br /&gt;
METHOD canvas_default;&lt;br /&gt;
RUN pump1.default_self;&lt;br /&gt;
RUN condenser1.default_self;&lt;br /&gt;
END canvas_default;&lt;br /&gt;
&lt;br /&gt;
Here the pump1.default_self and condenser1.default_self METHODS specify the nature of default action of the blocks pump1 and condenser1 respectively, i.e. how to set the parameters in a &#039;normal&#039; default way.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.&lt;br /&gt;
&lt;br /&gt;
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&lt;br /&gt;
to the default_self of the block inside the canvas_default. Some&lt;br /&gt;
things that will need to be taken care of:&lt;br /&gt;
&lt;br /&gt;
1. How to use both the default methods and the parameter tab in blockproperties.&lt;br /&gt;
2. What if the user selects the a default method and also fixes a&lt;br /&gt;
parameter separately.&lt;br /&gt;
3. What if the default method fails in some different configuration of&lt;br /&gt;
a canvas model.&lt;br /&gt;
4. What if something we have set as required can also be solved for?&lt;br /&gt;
&lt;br /&gt;
Using the two above things together will let us into a good design&lt;br /&gt;
solution for the parameters.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=GSoC 2010 Participation=&lt;br /&gt;
&lt;br /&gt;
== Goals ==&lt;br /&gt;
&lt;br /&gt;
Improvement on Canvas-based modeling:&lt;br /&gt;
* Updating the graphical flow sheet modeler.&lt;br /&gt;
* Enhancing its usability and functionality.&lt;br /&gt;
* Making it more robust.&lt;br /&gt;
&lt;br /&gt;
== Tasks ==&lt;br /&gt;
&lt;br /&gt;
* Initially before coding address the necessary prerequisites that I will discuss with the Ascend team and have solutions ready to be implemented as follows;&lt;br /&gt;
* 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.&lt;br /&gt;
* Solution of the redundant equations in case of equality loops. The current method of &#039;Methods&#039; be either modified or updated, for easy debugging of the models.&lt;br /&gt;
* To specify the &#039;global&#039; variables for generic models, like streams in a turbine. Every such &#039;general&#039; 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.&lt;br /&gt;
* 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.&lt;br /&gt;
* Define a set number of generic models that could added so that using Ascend Canvas based modeler becomes a head-start process.&lt;br /&gt;
* 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.&lt;br /&gt;
&lt;br /&gt;
By mid-term review:&lt;br /&gt;
* 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.&lt;br /&gt;
* Do the GUI usability improvements. Undo, Redo, Save image etc.&lt;br /&gt;
* Code for a suitable framework for importing new models into the pallet from a specified location.&lt;br /&gt;
* Code for the solution of the type checking problem.&lt;br /&gt;
* Unit tests of features implemented.&lt;br /&gt;
* Start to code for defining the global variables for each of the generic block sub-model.&lt;br /&gt;
&lt;br /&gt;
By final-term review:&lt;br /&gt;
* Complete the code for setting the global variables for generic models.&lt;br /&gt;
* Code for efficient debugging of models with closed circulation loops.&lt;br /&gt;
* Code for the type checking.&lt;br /&gt;
* Unit tests of features implemented.&lt;br /&gt;
* Add new blocks of models.&lt;br /&gt;
* Final testing of the code, final integration to the /trunk code, documentation.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
 &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Category:GSOC2010]]&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2053</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2053"/>
		<updated>2011-04-02T00:56:14Z</updated>

		<summary type="html">&lt;p&gt;Grivan: /* Update for Gaphas HEAD */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 and current development carried out by [[Grivan Thapar]]. The goals and tasks for the GSoC period are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. The concerns are right now at setting up better mechanisms for parameter handling and design enhancements like handling of stream objects, globals etc.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
TODO : Add more ideas, put a concrete solution overview to each Case. Add new use cases based upon electronic circuit models sent over by Divyanshu.&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
*Global Model equations.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
*Block rotation.&lt;br /&gt;
*:It would be nice if blocks could be rotated, it makes the canvas look more tidy.&lt;br /&gt;
*Other Issues.&lt;br /&gt;
*:Just specifying a value and not Fixing it. Should it be possible? &lt;br /&gt;
*: How to make additions of equations to the MODEL more intuitive.&lt;br /&gt;
&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}}. We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece. In addition take care of the ALIASES keyword used in the text model. TODO&lt;br /&gt;
*Elimination of redundant equations in closed loop flows.&lt;br /&gt;
*:Multiple loops present in the system.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Still needs to be discussed. TODO&lt;br /&gt;
*Specifications of flow streams. &lt;br /&gt;
*:It should be possible to switch between stream components, water to CO2 to toluene for example.&lt;br /&gt;
*:This however should &#039;&#039;&#039;not&#039;&#039;&#039; involve redrawing the whole model again.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Streams can be defined in the canvas by selecting the particular connections and specifying the stream component, the connections to these components at the ports must use the values of stream component provided. TODO&lt;br /&gt;
*Providing complex flow streams.&lt;br /&gt;
*:A regenerative cycle requires to specify the fraction of steam extracted at the &#039;&#039;bled&#039;&#039; point, that is a TEE in our sense. Such a fraction must be supplied by the user while making such connections. Assuming an open feedwater scheme.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; This should be easy as a simple TEE component must have a fixable variable &#039;fraction&#039;.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*In this case connections may need to be manually specified in order to provide complex flows as required.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious.&lt;br /&gt;
**For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling of Servo Motor with backlash and PID control===&lt;br /&gt;
*TODO : Add description&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The new Gapahs 0.7.2 release till now seems to work fine.&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head 0.7.1. &lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
TODO : Keep adding details&lt;br /&gt;
&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
==Improvements on the Solving Process==&lt;br /&gt;
Since we have no Type informations the solving is done primarily by first generating a string representation of the complete MODEL and then exported to the solver. This can lead to problems while trying to solve complex models requiring a large time to solve, because each time a variable is changed the complete model has to solved again. In case of PyGTK GUI we have a more powerful interaction with the solver and thus can change parameters without discarding the already solved model. The basic problem here lies in the fact that we don&#039;t instantiate the model first and then solve it.&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified. This provides and excellent way to have the same model provide simulation for any number of streams. Two implementations have to be taken care of to specify streams;&lt;br /&gt;
*GUI implementation:&lt;br /&gt;
*:This would provide a suitable GUI to select the stream.&lt;br /&gt;
*Application level implementation&lt;br /&gt;
*:This would add actual stream modifications to the block code.&lt;br /&gt;
The [[#Simple Rankine Cycle]] could be solved simply by connecting steam_port connectors. The {{src|models/johnpye/rankine.a4c}} uses Steam as the only modelling stream. This model needs to be evolved to use generic port types so that a better and more deep understanding is achieved in the problem of specifying flow streams.&lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now.&lt;br /&gt;
&lt;br /&gt;
*To have highlighting of connectible ports while connecting two ports we need to:&lt;br /&gt;
*#Find all suitable (IN/OUT/BOTH) ports available for connection.&lt;br /&gt;
*#Create a set their Types.&lt;br /&gt;
*#Check connect-ability for each of those types.&lt;br /&gt;
*#Highlight only the connectible ones.&lt;br /&gt;
&lt;br /&gt;
*To give a set of units that can be selected from a drop down menu in block properties:&lt;br /&gt;
*#Scan for the Type of the parameter.&lt;br /&gt;
*#Get the dimensions of the type.&lt;br /&gt;
*#Scan for the units available. &lt;br /&gt;
&lt;br /&gt;
*Implementation&lt;br /&gt;
**Some testing has been done of the functions, see &amp;lt;code&amp;gt;test_type_info()&amp;lt;/code&amp;gt; function inside /compiler/test/test_basics.c&lt;br /&gt;
**The test can be run on any file, using &amp;lt;code&amp;gt;scons test &amp;amp;&amp;amp; test/test compiler_basics.type_info&amp;lt;/code&amp;gt;&lt;br /&gt;
**From the observations, it is clear that the function &amp;lt;code&amp;gt;GetChildList()&amp;lt;/code&amp;gt; works as it should in case of all user generated foreseeable canvas models.&lt;br /&gt;
&lt;br /&gt;
==Key Deliverables==&lt;br /&gt;
To set a stone for the GSoC project following have to be implemented&lt;br /&gt;
*Canvas Model for a Regenerative Rankine cycle&lt;br /&gt;
*Ammonia synthesis reactor&lt;br /&gt;
*Support for user customisable icon-types for blocks&lt;br /&gt;
*Undo Support&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2052</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2052"/>
		<updated>2011-04-02T00:51:52Z</updated>

		<summary type="html">&lt;p&gt;Grivan: /* Use Cases */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 and current development carried out by [[Grivan Thapar]]. The goals and tasks for the GSoC period are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. The concerns are right now at setting up better mechanisms for parameter handling and design enhancements like handling of stream objects, globals etc.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
TODO : Add more ideas, put a concrete solution overview to each Case. Add new use cases based upon electronic circuit models sent over by Divyanshu.&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
*Global Model equations.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
*Block rotation.&lt;br /&gt;
*:It would be nice if blocks could be rotated, it makes the canvas look more tidy.&lt;br /&gt;
*Other Issues.&lt;br /&gt;
*:Just specifying a value and not Fixing it. Should it be possible? &lt;br /&gt;
*: How to make additions of equations to the MODEL more intuitive.&lt;br /&gt;
&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}}. We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece. In addition take care of the ALIASES keyword used in the text model. TODO&lt;br /&gt;
*Elimination of redundant equations in closed loop flows.&lt;br /&gt;
*:Multiple loops present in the system.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Still needs to be discussed. TODO&lt;br /&gt;
*Specifications of flow streams. &lt;br /&gt;
*:It should be possible to switch between stream components, water to CO2 to toluene for example.&lt;br /&gt;
*:This however should &#039;&#039;&#039;not&#039;&#039;&#039; involve redrawing the whole model again.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Streams can be defined in the canvas by selecting the particular connections and specifying the stream component, the connections to these components at the ports must use the values of stream component provided. TODO&lt;br /&gt;
*Providing complex flow streams.&lt;br /&gt;
*:A regenerative cycle requires to specify the fraction of steam extracted at the &#039;&#039;bled&#039;&#039; point, that is a TEE in our sense. Such a fraction must be supplied by the user while making such connections. Assuming an open feedwater scheme.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; This should be easy as a simple TEE component must have a fixable variable &#039;fraction&#039;.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*In this case connections may need to be manually specified in order to provide complex flows as required.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious.&lt;br /&gt;
**For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling of Servo Motor with backlash and PID control===&lt;br /&gt;
*TODO : Add description&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head.&lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
TODO : Keep adding details&lt;br /&gt;
&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
==Improvements on the Solving Process==&lt;br /&gt;
Since we have no Type informations the solving is done primarily by first generating a string representation of the complete MODEL and then exported to the solver. This can lead to problems while trying to solve complex models requiring a large time to solve, because each time a variable is changed the complete model has to solved again. In case of PyGTK GUI we have a more powerful interaction with the solver and thus can change parameters without discarding the already solved model. The basic problem here lies in the fact that we don&#039;t instantiate the model first and then solve it.&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified. This provides and excellent way to have the same model provide simulation for any number of streams. Two implementations have to be taken care of to specify streams;&lt;br /&gt;
*GUI implementation:&lt;br /&gt;
*:This would provide a suitable GUI to select the stream.&lt;br /&gt;
*Application level implementation&lt;br /&gt;
*:This would add actual stream modifications to the block code.&lt;br /&gt;
The [[#Simple Rankine Cycle]] could be solved simply by connecting steam_port connectors. The {{src|models/johnpye/rankine.a4c}} uses Steam as the only modelling stream. This model needs to be evolved to use generic port types so that a better and more deep understanding is achieved in the problem of specifying flow streams.&lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now.&lt;br /&gt;
&lt;br /&gt;
*To have highlighting of connectible ports while connecting two ports we need to:&lt;br /&gt;
*#Find all suitable (IN/OUT/BOTH) ports available for connection.&lt;br /&gt;
*#Create a set their Types.&lt;br /&gt;
*#Check connect-ability for each of those types.&lt;br /&gt;
*#Highlight only the connectible ones.&lt;br /&gt;
&lt;br /&gt;
*To give a set of units that can be selected from a drop down menu in block properties:&lt;br /&gt;
*#Scan for the Type of the parameter.&lt;br /&gt;
*#Get the dimensions of the type.&lt;br /&gt;
*#Scan for the units available. &lt;br /&gt;
&lt;br /&gt;
*Implementation&lt;br /&gt;
**Some testing has been done of the functions, see &amp;lt;code&amp;gt;test_type_info()&amp;lt;/code&amp;gt; function inside /compiler/test/test_basics.c&lt;br /&gt;
**The test can be run on any file, using &amp;lt;code&amp;gt;scons test &amp;amp;&amp;amp; test/test compiler_basics.type_info&amp;lt;/code&amp;gt;&lt;br /&gt;
**From the observations, it is clear that the function &amp;lt;code&amp;gt;GetChildList()&amp;lt;/code&amp;gt; works as it should in case of all user generated foreseeable canvas models.&lt;br /&gt;
&lt;br /&gt;
==Key Deliverables==&lt;br /&gt;
To set a stone for the GSoC project following have to be implemented&lt;br /&gt;
*Canvas Model for a Regenerative Rankine cycle&lt;br /&gt;
*Ammonia synthesis reactor&lt;br /&gt;
*Support for user customisable icon-types for blocks&lt;br /&gt;
*Undo Support&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2051</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2051"/>
		<updated>2011-04-02T00:50:49Z</updated>

		<summary type="html">&lt;p&gt;Grivan: /* Use Cases */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 and current development carried out by [[Grivan Thapar]]. The goals and tasks for the GSoC period are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. The concerns are right now at setting up better mechanisms for parameter handling and design enhancements like handling of stream objects, globals etc.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
TODO : Add more ideas, put a concrete solution overview to each Case. Add new use cases based upon the models by Divyanshu.&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
*Global Model equations.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
*Block rotation.&lt;br /&gt;
*:It would be nice if blocks could be rotated, it makes the canvas look more tidy.&lt;br /&gt;
*Other Issues.&lt;br /&gt;
*:Just specifying a value and not Fixing it. Should it be possible? &lt;br /&gt;
*: How to make additions of equations to the MODEL more intuitive.&lt;br /&gt;
&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}}. We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece. In addition take care of the ALIASES keyword used in the text model. TODO&lt;br /&gt;
*Elimination of redundant equations in closed loop flows.&lt;br /&gt;
*:Multiple loops present in the system.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Still needs to be discussed. TODO&lt;br /&gt;
*Specifications of flow streams. &lt;br /&gt;
*:It should be possible to switch between stream components, water to CO2 to toluene for example.&lt;br /&gt;
*:This however should &#039;&#039;&#039;not&#039;&#039;&#039; involve redrawing the whole model again.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Streams can be defined in the canvas by selecting the particular connections and specifying the stream component, the connections to these components at the ports must use the values of stream component provided. TODO&lt;br /&gt;
*Providing complex flow streams.&lt;br /&gt;
*:A regenerative cycle requires to specify the fraction of steam extracted at the &#039;&#039;bled&#039;&#039; point, that is a TEE in our sense. Such a fraction must be supplied by the user while making such connections. Assuming an open feedwater scheme.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; This should be easy as a simple TEE component must have a fixable variable &#039;fraction&#039;.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*In this case connections may need to be manually specified in order to provide complex flows as required.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious.&lt;br /&gt;
**For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling of Servo Motor with backlash and PID control===&lt;br /&gt;
*TODO : Add description&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head.&lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
TODO : Keep adding details&lt;br /&gt;
&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
==Improvements on the Solving Process==&lt;br /&gt;
Since we have no Type informations the solving is done primarily by first generating a string representation of the complete MODEL and then exported to the solver. This can lead to problems while trying to solve complex models requiring a large time to solve, because each time a variable is changed the complete model has to solved again. In case of PyGTK GUI we have a more powerful interaction with the solver and thus can change parameters without discarding the already solved model. The basic problem here lies in the fact that we don&#039;t instantiate the model first and then solve it.&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified. This provides and excellent way to have the same model provide simulation for any number of streams. Two implementations have to be taken care of to specify streams;&lt;br /&gt;
*GUI implementation:&lt;br /&gt;
*:This would provide a suitable GUI to select the stream.&lt;br /&gt;
*Application level implementation&lt;br /&gt;
*:This would add actual stream modifications to the block code.&lt;br /&gt;
The [[#Simple Rankine Cycle]] could be solved simply by connecting steam_port connectors. The {{src|models/johnpye/rankine.a4c}} uses Steam as the only modelling stream. This model needs to be evolved to use generic port types so that a better and more deep understanding is achieved in the problem of specifying flow streams.&lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now.&lt;br /&gt;
&lt;br /&gt;
*To have highlighting of connectible ports while connecting two ports we need to:&lt;br /&gt;
*#Find all suitable (IN/OUT/BOTH) ports available for connection.&lt;br /&gt;
*#Create a set their Types.&lt;br /&gt;
*#Check connect-ability for each of those types.&lt;br /&gt;
*#Highlight only the connectible ones.&lt;br /&gt;
&lt;br /&gt;
*To give a set of units that can be selected from a drop down menu in block properties:&lt;br /&gt;
*#Scan for the Type of the parameter.&lt;br /&gt;
*#Get the dimensions of the type.&lt;br /&gt;
*#Scan for the units available. &lt;br /&gt;
&lt;br /&gt;
*Implementation&lt;br /&gt;
**Some testing has been done of the functions, see &amp;lt;code&amp;gt;test_type_info()&amp;lt;/code&amp;gt; function inside /compiler/test/test_basics.c&lt;br /&gt;
**The test can be run on any file, using &amp;lt;code&amp;gt;scons test &amp;amp;&amp;amp; test/test compiler_basics.type_info&amp;lt;/code&amp;gt;&lt;br /&gt;
**From the observations, it is clear that the function &amp;lt;code&amp;gt;GetChildList()&amp;lt;/code&amp;gt; works as it should in case of all user generated foreseeable canvas models.&lt;br /&gt;
&lt;br /&gt;
==Key Deliverables==&lt;br /&gt;
To set a stone for the GSoC project following have to be implemented&lt;br /&gt;
*Canvas Model for a Regenerative Rankine cycle&lt;br /&gt;
*Ammonia synthesis reactor&lt;br /&gt;
*Support for user customisable icon-types for blocks&lt;br /&gt;
*Undo Support&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2050</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2050"/>
		<updated>2011-04-02T00:48:24Z</updated>

		<summary type="html">&lt;p&gt;Grivan: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 and current development carried out by [[Grivan Thapar]]. The goals and tasks for the GSoC period are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. The concerns are right now at setting up better mechanisms for parameter handling and design enhancements like handling of stream objects, globals etc.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
TODO : Add more ideas, put a concrete solution overview to each Case.&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
*Global Model equations.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
*Block rotation.&lt;br /&gt;
*:It would be nice if blocks could be rotated, it makes the canvas look more tidy.&lt;br /&gt;
*Other Issues.&lt;br /&gt;
*:Just specifying a value and not Fixing it. Should it be possible? &lt;br /&gt;
*: How to make additions of equations to the MODEL more intuitive.&lt;br /&gt;
&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}}. We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece. In addition take care of the ALIASES keyword used in the text model. TODO&lt;br /&gt;
*Elimination of redundant equations in closed loop flows.&lt;br /&gt;
*:Multiple loops present in the system.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Still needs to be discussed. TODO&lt;br /&gt;
*Specifications of flow streams. &lt;br /&gt;
*:It should be possible to switch between stream components, water to CO2 to toluene for example.&lt;br /&gt;
*:This however should &#039;&#039;&#039;not&#039;&#039;&#039; involve redrawing the whole model again.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Streams can be defined in the canvas by selecting the particular connections and specifying the stream component, the connections to these components at the ports must use the values of stream component provided. TODO&lt;br /&gt;
*Providing complex flow streams.&lt;br /&gt;
*:A regenerative cycle requires to specify the fraction of steam extracted at the &#039;&#039;bled&#039;&#039; point, that is a TEE in our sense. Such a fraction must be supplied by the user while making such connections. Assuming an open feedwater scheme.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; This should be easy as a simple TEE component must have a fixable variable &#039;fraction&#039;.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*In this case connections may need to be manually specified in order to provide complex flows as required.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious.&lt;br /&gt;
**For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling of Servo Motor with backlash and PID control===&lt;br /&gt;
*TODO : Add description&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head.&lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
TODO : Keep adding details&lt;br /&gt;
&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
==Improvements on the Solving Process==&lt;br /&gt;
Since we have no Type informations the solving is done primarily by first generating a string representation of the complete MODEL and then exported to the solver. This can lead to problems while trying to solve complex models requiring a large time to solve, because each time a variable is changed the complete model has to solved again. In case of PyGTK GUI we have a more powerful interaction with the solver and thus can change parameters without discarding the already solved model. The basic problem here lies in the fact that we don&#039;t instantiate the model first and then solve it.&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified. This provides and excellent way to have the same model provide simulation for any number of streams. Two implementations have to be taken care of to specify streams;&lt;br /&gt;
*GUI implementation:&lt;br /&gt;
*:This would provide a suitable GUI to select the stream.&lt;br /&gt;
*Application level implementation&lt;br /&gt;
*:This would add actual stream modifications to the block code.&lt;br /&gt;
The [[#Simple Rankine Cycle]] could be solved simply by connecting steam_port connectors. The {{src|models/johnpye/rankine.a4c}} uses Steam as the only modelling stream. This model needs to be evolved to use generic port types so that a better and more deep understanding is achieved in the problem of specifying flow streams.&lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now.&lt;br /&gt;
&lt;br /&gt;
*To have highlighting of connectible ports while connecting two ports we need to:&lt;br /&gt;
*#Find all suitable (IN/OUT/BOTH) ports available for connection.&lt;br /&gt;
*#Create a set their Types.&lt;br /&gt;
*#Check connect-ability for each of those types.&lt;br /&gt;
*#Highlight only the connectible ones.&lt;br /&gt;
&lt;br /&gt;
*To give a set of units that can be selected from a drop down menu in block properties:&lt;br /&gt;
*#Scan for the Type of the parameter.&lt;br /&gt;
*#Get the dimensions of the type.&lt;br /&gt;
*#Scan for the units available. &lt;br /&gt;
&lt;br /&gt;
*Implementation&lt;br /&gt;
**Some testing has been done of the functions, see &amp;lt;code&amp;gt;test_type_info()&amp;lt;/code&amp;gt; function inside /compiler/test/test_basics.c&lt;br /&gt;
**The test can be run on any file, using &amp;lt;code&amp;gt;scons test &amp;amp;&amp;amp; test/test compiler_basics.type_info&amp;lt;/code&amp;gt;&lt;br /&gt;
**From the observations, it is clear that the function &amp;lt;code&amp;gt;GetChildList()&amp;lt;/code&amp;gt; works as it should in case of all user generated foreseeable canvas models.&lt;br /&gt;
&lt;br /&gt;
==Key Deliverables==&lt;br /&gt;
To set a stone for the GSoC project following have to be implemented&lt;br /&gt;
*Canvas Model for a Regenerative Rankine cycle&lt;br /&gt;
*Ammonia synthesis reactor&lt;br /&gt;
*Support for user customisable icon-types for blocks&lt;br /&gt;
*Undo Support&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2049</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=2049"/>
		<updated>2011-04-02T00:46:14Z</updated>

		<summary type="html">&lt;p&gt;Grivan: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 and current development carried out by [[Grivan Thapar]]. The goals and tasks for the GSoC period are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. The concerns are right now at setting up better mechanisms for parameter handling and design enhancements like handling of stream objects, globals etc.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
TODO : Add more ideas, put a concrete solution overview to each Case.&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
*Global Model equations.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
*Block rotation.&lt;br /&gt;
*:It would be nice if blocks could be rotated, it makes the canvas look more tidy.&lt;br /&gt;
*Other Issues.&lt;br /&gt;
*:Just specifying a value and not Fixing it. Should it be possible? &lt;br /&gt;
*: How to make additions of equations to the MODEL more intuitive.&lt;br /&gt;
&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}}. We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece. In addition take care of the ALIASES keyword used in the text model. TODO&lt;br /&gt;
*Elimination of redundant equations in closed loop flows.&lt;br /&gt;
*:Multiple loops present in the system.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Still needs to be discussed. TODO&lt;br /&gt;
*Specifications of flow streams. &lt;br /&gt;
*:It should be possible to switch between stream components, water to CO2 to toluene for example.&lt;br /&gt;
*:This however should &#039;&#039;&#039;not&#039;&#039;&#039; involve redrawing the whole model again.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Streams can be defined in the canvas by selecting the particular connections and specifying the stream component, the connections to these components at the ports must use the values of stream component provided. TODO&lt;br /&gt;
*Providing complex flow streams.&lt;br /&gt;
*:A regenerative cycle requires to specify the fraction of steam extracted at the &#039;&#039;bled&#039;&#039; point, that is a TEE in our sense. Such a fraction must be supplied by the user while making such connections. Assuming an open feedwater scheme.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; This should be easy as a simple TEE component must have a fixable variable &#039;fraction&#039;.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*In this case connections may need to be manually specified in order to provide complex flows as required.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious.&lt;br /&gt;
**For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling of Servo Motor with backlash and PID control===&lt;br /&gt;
*TODO : Add description&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head.&lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
TODO : Keep adding details&lt;br /&gt;
&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
==Improvements on the Solving Process==&lt;br /&gt;
Since we have no Type informations the solving is done primarily by first generating a string representation of the complete MODEL and then exported to the solver. This can lead to problems while trying to solve complex models requiring a large time to solve, because each time a variable is changed the complete model has to solved again. In case of PyGTK GUI we have a more powerful interaction with the solver and thus can change parameters without discarding the already solved model. The basic problem here lies in the fact that we don&#039;t instantiate the model first and then solve it.&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified. This provides and excellent way to have the same model provide simulation for any number of streams. Two implementations have to be taken care of to specify streams;&lt;br /&gt;
*GUI implementation:&lt;br /&gt;
*:This would provide a suitable GUI to select the stream.&lt;br /&gt;
*Application level implementation&lt;br /&gt;
*:This would add actual stream modifications to the block code.&lt;br /&gt;
The [[#Simple Rankine Cycle]] could be solved simply by connecting steam_port connectors. The {{src|models/johnpye/rankine.a4c}} uses Steam as the only modelling stream. This model needs to be evolved to use generic port types so that a better and more deep understanding is achieved in the problem of specifying flow streams.&lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now.&lt;br /&gt;
&lt;br /&gt;
*To have highlighting of connectible ports while connecting two ports we need to:&lt;br /&gt;
*#Find all suitable (IN/OUT/BOTH) ports available for connection.&lt;br /&gt;
*#Create a set their Types.&lt;br /&gt;
*#Check connect-ability for each of those types.&lt;br /&gt;
*#Highlight only the connectible ones.&lt;br /&gt;
&lt;br /&gt;
*To give a set of units that can be selected from a drop down menu in block properties:&lt;br /&gt;
*#Scan for the Type of the parameter.&lt;br /&gt;
*#Get the dimensions of the type.&lt;br /&gt;
*#Scan for the units available. &lt;br /&gt;
&lt;br /&gt;
*Implementation&lt;br /&gt;
**Some testing has been done of the functions, see &amp;lt;code&amp;gt;test_type_info()&amp;lt;/code&amp;gt; function inside /compiler/test/test_basics.c&lt;br /&gt;
**The test can be run on any file, using &amp;lt;code&amp;gt;scons test &amp;amp;&amp;amp; test/test compiler_basics.type_info&amp;lt;/code&amp;gt;&lt;br /&gt;
**From the observations, it is clear that the function &amp;lt;code&amp;gt;GetChildList()&amp;lt;/code&amp;gt; works as it should in case of all user generated foreseeable canvas models.&lt;br /&gt;
&lt;br /&gt;
==Key Deliverables==&lt;br /&gt;
To set a stone for the GSoC project following have to be implemented&lt;br /&gt;
*Canvas Model for a Regenerative Rankine cycle&lt;br /&gt;
*Ammonia synthesis reactor&lt;br /&gt;
*Support for user customisable icon-types for blocks&lt;br /&gt;
*Undo Support&lt;br /&gt;
&lt;br /&gt;
==Weekly Reports==&lt;br /&gt;
&lt;br /&gt;
The weekly reports will be filed here. Week 0 starts from 24th of May up-to 30th of May and so on.&lt;br /&gt;
&lt;br /&gt;
====Week 0====&lt;br /&gt;
24th-May-10 to 30th-May-10&lt;br /&gt;
*Set up environment&lt;br /&gt;
*Attempt to try and get modeller running&lt;br /&gt;
*:Code updates for Gaphas HEAD using and Arijit&#039;s patch and some extra edits&lt;br /&gt;
*:Except for connections feature canvas code successfully updates for Gaphas HEAD&lt;br /&gt;
*:Code updates for py-gtksourceview2, enabled syntax highlighting&lt;br /&gt;
*Other minor issues resolved&lt;br /&gt;
*Unavailable for project completely due to scheduled end semester exams from 24th-July-10 to 2nd-July-10&lt;br /&gt;
&lt;br /&gt;
====Week 1====&lt;br /&gt;
31st-May-10 to 6th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;This was a &#039;pull-up-socks&#039; week, main aim was to get back on after exams and prioritise work&lt;br /&gt;
*Attempt to fix the connections code&lt;br /&gt;
*#Connection disconnection done, using Gaphas&#039; new Aspects API. Still need a way to reconnect&lt;br /&gt;
*Start identifying crucial aspects for Canvas Modelling&lt;br /&gt;
*Started developing Use-Cases&lt;br /&gt;
*Had a meet with Prof Kannan. Got a huge motivation&lt;br /&gt;
*#Got in touch with Shrikanth and Ankit to identify aspects for use of Canvas modeller in a class room environment&lt;br /&gt;
*#Got in touch with Delhi FOSS community&lt;br /&gt;
*Started working on implementation details for Type-Checking, Closed-Loop flow sheets, User-customisable icons&lt;br /&gt;
*Got this wiki page up&lt;br /&gt;
&lt;br /&gt;
====Week 2====&lt;br /&gt;
7th-June-10 to 13th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Complete study of use cases&lt;br /&gt;
*Have connections code completely set, robust and future ready&lt;br /&gt;
*Have implementation details of at least one of the GUI features&lt;br /&gt;
&#039;&#039;Status of work&#039;&#039;&lt;br /&gt;
*The canvas connection code is completely done. User can connect/disconnect items multiple times.&lt;br /&gt;
*Improved the block propertied dialogue box a lot. &lt;br /&gt;
*#Shifted the basic structure to XML, using Glade.&lt;br /&gt;
*#Due to no implementation of [[#Type Information]], setting units may still create a problem.&lt;br /&gt;
*#Parameters are now viewable through a List view.&lt;br /&gt;
*Use cases still need more work.&lt;br /&gt;
*Worked out some details of implementing Undo/Redo system. Starting the work to implement them.&lt;br /&gt;
&lt;br /&gt;
====Week 3====&lt;br /&gt;
14th-June-10 to 20th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Set up the Undo/Redo system.&lt;br /&gt;
*Improve the Unit checking.&lt;br /&gt;
*Get ideas, implementation details on [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Status of Work&#039;&#039;&lt;br /&gt;
*A very basic Undo system in place.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Issues&#039;&#039;&lt;br /&gt;
*Identifying a way to record Undo transactions took a large part of the week, could not complete other objectives.&lt;br /&gt;
&lt;br /&gt;
====Week 4====&lt;br /&gt;
21st-June-10 to 27th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO LIST&#039;&#039;&lt;br /&gt;
*Thoroughly test Undo system.&lt;br /&gt;
*Improve the Unit checking.&lt;br /&gt;
*Get ideas, implementation details on [[#Support for user-customisable custom icon types]]. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Status of Work&#039;&#039;&lt;br /&gt;
*Did many improvements to the Undo system.&lt;br /&gt;
*Improved the Key Accel&#039;s&lt;br /&gt;
*Improved Connections code.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Issues&#039;&#039;&lt;br /&gt;
*Callback functions do not record in gaphas as an event, so Undo system breaks at undoing a disconnect of Line Connection.&lt;br /&gt;
*Went through much of ASCEND API, but still not being able to identify Types and thus Units of parameters of blocks. For a temporary solution tried a failed attempt to get a Simulation of the String Model and identify Types. &lt;br /&gt;
*Problem lies in not being able to get [[#Type Information]] in the model by name, which is the only information we have from annotations.&lt;br /&gt;
*Finding ways for [[#Support for user-customisable custom icon types]] implementation details, studied how Modellica handles Graphic properties of blocks.&lt;br /&gt;
&lt;br /&gt;
====Week 5====&lt;br /&gt;
28th-June-10 to 4th-July-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Set up freesteam, solve and study rankine.a4c&lt;br /&gt;
*Try to implement [[#Support for user-customisable custom icon types]] by Mid-Term, get implementation details and begin work.&lt;br /&gt;
*Check for solutions for Line connection Undo bug.&lt;br /&gt;
*Find a way for getting [[#Type Information]].&lt;br /&gt;
*Deal with [[#Bugs]].&lt;br /&gt;
&lt;br /&gt;
====Week 6====&lt;br /&gt;
5th-July-10 to 11th-July-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Annotate rankine.a4c for Canvas Modelling.&lt;br /&gt;
*Solve [[#Simple Rankine Cycle]] through Canvas Modeller.&lt;br /&gt;
*GUI to add extra canvas MODEL equations/declarations.&lt;br /&gt;
*Work towards getting [[#Type Information]]&lt;br /&gt;
*Fix key-accel to Menu items.&lt;br /&gt;
*GUI for value-indicators of solved variables.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Status of Work&#039;&#039;&lt;br /&gt;
*Annotated  {{src|models/johnpye/rankine.a4c}} and successfully Solved [[#Simple Rankine Cycle]] through Canvas Modeller.&lt;br /&gt;
*User can now add extra canvas MODEL equations/declarations.&lt;br /&gt;
*Menu items key-accel&#039;s improved.&lt;br /&gt;
*Other GUI improvements like extra Canvas-properties pop-up, more items to Contextmenu, etc.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Issues&#039;&#039;&lt;br /&gt;
*What if a parameter is not fixed but has a value? Could not understand what does it mean.&lt;br /&gt;
*Need a more intuitive way to add the extra declarations, like real time visible addition to the MODEL code rather than having a separate tab.&lt;br /&gt;
*[[#Type Information]] still requires extra thinking and a lot of work.&lt;br /&gt;
&lt;br /&gt;
====Week 7====&lt;br /&gt;
12th-July-10 to 18th-July-10&lt;br /&gt;
*Submit Mid Term Evaluations&lt;br /&gt;
&lt;br /&gt;
====Week 8====&lt;br /&gt;
19th-July-10 to 25th-July-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 9====&lt;br /&gt;
26th-July-10 to 1st-August-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 10====&lt;br /&gt;
2nd-August-10 to 8th-August-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 11====&lt;br /&gt;
9th-August-10 to 16th-August-10&lt;br /&gt;
*Finalise work&lt;br /&gt;
*Submit End Term Evaluations&lt;br /&gt;
*Tie loose ends&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=1027</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=1027"/>
		<updated>2010-07-28T13:37:21Z</updated>

		<summary type="html">&lt;p&gt;Grivan: /* Type Information */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 development carried out by [[User:Grivan|Grivan]]. The goals and tasks are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. Efforts will be to make the modeller powerful enough for some real and serious modelling. Use Cases are being developed as to see what do we expect from our modeller to be able to do for us, to identify the most important aspects and implement them.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
TODO : Add more ideas, put a concrete solution overview to each Case.&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
*Global Model equations.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
*Block rotation.&lt;br /&gt;
*:It would be nice if blocks could be rotated, it makes the canvas look more tidy.&lt;br /&gt;
*Other Issues.&lt;br /&gt;
*:Just specifying a value and not Fixing it. Should it be possible? &lt;br /&gt;
*: How to make additions of equations to the MODEL more intuitive.&lt;br /&gt;
&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}}. We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece. In addition take care of the ALIASES keyword used in the text model. TODO&lt;br /&gt;
*Elimination of redundant equations in closed loop flows.&lt;br /&gt;
*:Multiple loops present in the system.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Still needs to be discussed. TODO&lt;br /&gt;
*Specifications of flow streams. &lt;br /&gt;
*:It should be possible to switch between stream components, water to CO2 to toluene for example.&lt;br /&gt;
*:This however should &#039;&#039;&#039;not&#039;&#039;&#039; involve redrawing the whole model again.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Streams can be defined in the canvas by selecting the particular connections and specifying the stream component, the connections to these components at the ports must use the values of stream component provided. TODO&lt;br /&gt;
*Providing complex flow streams.&lt;br /&gt;
*:A regenerative cycle requires to specify the fraction of steam extracted at the &#039;&#039;bled&#039;&#039; point, that is a TEE in our sense. Such a fraction must be supplied by the user while making such connections. Assuming an open feedwater scheme.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; This should be easy as a simple TEE component must have a fixable variable &#039;fraction&#039;.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*In this case connections may need to be manually specified in order to provide complex flows as required.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious.&lt;br /&gt;
**For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling of Servo Motor with backlash and PID control===&lt;br /&gt;
*TODO : Add description&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head.&lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
TODO : Keep adding details&lt;br /&gt;
&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
==Improvements on the Solving Process==&lt;br /&gt;
Since we have no Type informations the solving is done primarily by first generating a string representation of the complete MODEL and then exported to the solver. This can lead to problems while trying to solve complex models requiring a large time to solve, because each time a variable is changed the complete model has to solved again. In case of PyGTK GUI we have a more powerful interaction with the solver and thus can change parameters without discarding the already solved model. The basic problem here lies in the fact that we don&#039;t instantiate the model first and then solve it.&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified. This provides and excellent way to have the same model provide simulation for any number of streams. Two implementations have to be taken care of to specify streams;&lt;br /&gt;
*GUI implementation:&lt;br /&gt;
*:This would provide a suitable GUI to select the stream.&lt;br /&gt;
*Application level implementation&lt;br /&gt;
*:This would add actual stream modifications to the block code.&lt;br /&gt;
The [[#Simple Rankine Cycle]] could be solved simply by connecting steam_port connectors. The {{src|models/johnpye/rankine.a4c}} uses Steam as the only modelling stream. This model needs to be evolved to use generic port types so that a better and more deep understanding is achieved in the problem of specifying flow streams.&lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now.&lt;br /&gt;
&lt;br /&gt;
*To have highlighting of connectible ports while connecting two ports we need to:&lt;br /&gt;
*#Find all suitable (IN/OUT/BOTH) ports available for connection.&lt;br /&gt;
*#Create a set their Types.&lt;br /&gt;
*#Check connect-ability for each of those types.&lt;br /&gt;
*#Highlight only the connectible ones.&lt;br /&gt;
&lt;br /&gt;
*To give a set of units that can be selected from a drop down menu in block properties:&lt;br /&gt;
*#Scan for the Type of the parameter.&lt;br /&gt;
*#Get the dimensions of the type.&lt;br /&gt;
*#Scan for the units available. &lt;br /&gt;
&lt;br /&gt;
*Implementation&lt;br /&gt;
**Some testing has been done of the functions, see &amp;lt;code&amp;gt;test_type_info()&amp;lt;/code&amp;gt; function inside /compiler/test/test_basics.c&lt;br /&gt;
**The test can be run on any file, using &amp;lt;code&amp;gt;scons test &amp;amp;&amp;amp; test/test compiler_basics.type_info&amp;lt;/code&amp;gt;&lt;br /&gt;
**From the observations, it is clear that the function &amp;lt;code&amp;gt;GetChildList()&amp;lt;/code&amp;gt; work&#039;s as it should in case of all user generated foreseeable canvas models.&lt;br /&gt;
&lt;br /&gt;
==Key Deliverables==&lt;br /&gt;
To set a stone for the GSoC project following have to be implemented&lt;br /&gt;
*Canvas Model for a Regenerative Rankine cycle&lt;br /&gt;
*Ammonia synthesis reactor&lt;br /&gt;
*Support for user customisable icon-types for blocks&lt;br /&gt;
*Undo Support&lt;br /&gt;
&lt;br /&gt;
==Weekly Reports==&lt;br /&gt;
&lt;br /&gt;
The weekly reports will be filed here. Week 0 starts from 24th of May up-to 30th of May and so on.&lt;br /&gt;
&lt;br /&gt;
====Week 0====&lt;br /&gt;
24th-May-10 to 30th-May-10&lt;br /&gt;
*Set up environment&lt;br /&gt;
*Attempt to try and get modeller running&lt;br /&gt;
*:Code updates for Gaphas HEAD using and Arijit&#039;s patch and some extra edits&lt;br /&gt;
*:Except for connections feature canvas code successfully updates for Gaphas HEAD&lt;br /&gt;
*:Code updates for py-gtksourceview2, enabled syntax highlighting&lt;br /&gt;
*Other minor issues resolved&lt;br /&gt;
*Unavailable for project completely due to scheduled end semester exams from 24th-July-10 to 2nd-July-10&lt;br /&gt;
&lt;br /&gt;
====Week 1====&lt;br /&gt;
31st-May-10 to 6th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;This was a &#039;pull-up-socks&#039; week, main aim was to get back on after exams and prioritise work&lt;br /&gt;
*Attempt to fix the connections code&lt;br /&gt;
*#Connection disconnection done, using Gaphas&#039; new Aspects API. Still need a way to reconnect&lt;br /&gt;
*Start identifying crucial aspects for Canvas Modelling&lt;br /&gt;
*Started developing Use-Cases&lt;br /&gt;
*Had a meet with Prof Kannan. Got a huge motivation&lt;br /&gt;
*#Got in touch with Shrikanth and Ankit to identify aspects for use of Canvas modeller in a class room environment&lt;br /&gt;
*#Got in touch with Delhi FOSS community&lt;br /&gt;
*Started working on implementation details for Type-Checking, Closed-Loop flow sheets, User-customisable icons&lt;br /&gt;
*Got this wiki page up&lt;br /&gt;
&lt;br /&gt;
====Week 2====&lt;br /&gt;
7th-June-10 to 13th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Complete study of use cases&lt;br /&gt;
*Have connections code completely set, robust and future ready&lt;br /&gt;
*Have implementation details of at least one of the GUI features&lt;br /&gt;
&#039;&#039;Status of work&#039;&#039;&lt;br /&gt;
*The canvas connection code is completely done. User can connect/disconnect items multiple times.&lt;br /&gt;
*Improved the block propertied dialogue box a lot. &lt;br /&gt;
*#Shifted the basic structure to XML, using Glade.&lt;br /&gt;
*#Due to no implementation of [[#Type Information]], setting units may still create a problem.&lt;br /&gt;
*#Parameters are now viewable through a List view.&lt;br /&gt;
*Use cases still need more work.&lt;br /&gt;
*Worked out some details of implementing Undo/Redo system. Starting the work to implement them.&lt;br /&gt;
&lt;br /&gt;
====Week 3====&lt;br /&gt;
14th-June-10 to 20th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Set up the Undo/Redo system.&lt;br /&gt;
*Improve the Unit checking.&lt;br /&gt;
*Get ideas, implementation details on [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Status of Work&#039;&#039;&lt;br /&gt;
*A very basic Undo system in place.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Issues&#039;&#039;&lt;br /&gt;
*Identifying a way to record Undo transactions took a large part of the week, could not complete other objectives.&lt;br /&gt;
&lt;br /&gt;
====Week 4====&lt;br /&gt;
21st-June-10 to 27th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO LIST&#039;&#039;&lt;br /&gt;
*Thoroughly test Undo system.&lt;br /&gt;
*Improve the Unit checking.&lt;br /&gt;
*Get ideas, implementation details on [[#Support for user-customisable custom icon types]]. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Status of Work&#039;&#039;&lt;br /&gt;
*Did many improvements to the Undo system.&lt;br /&gt;
*Improved the Key Accel&#039;s&lt;br /&gt;
*Improved Connections code.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Issues&#039;&#039;&lt;br /&gt;
*Callback functions do not record in gaphas as an event, so Undo system breaks at undoing a disconnect of Line Connection.&lt;br /&gt;
*Went through much of ASCEND API, but still not being able to identify Types and thus Units of parameters of blocks. For a temporary solution tried a failed attempt to get a Simulation of the String Model and identify Types. &lt;br /&gt;
*Problem lies in not being able to get [[#Type Information]] in the model by name, which is the only information we have from annotations.&lt;br /&gt;
*Finding ways for [[#Support for user-customisable custom icon types]] implementation details, studied how Modellica handles Graphic properties of blocks.&lt;br /&gt;
&lt;br /&gt;
====Week 5====&lt;br /&gt;
28th-June-10 to 4th-July-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Set up freesteam, solve and study rankine.a4c&lt;br /&gt;
*Try to implement [[#Support for user-customisable custom icon types]] by Mid-Term, get implementation details and begin work.&lt;br /&gt;
*Check for solutions for Line connection Undo bug.&lt;br /&gt;
*Find a way for getting [[#Type Information]].&lt;br /&gt;
*Deal with [[#Bugs]].&lt;br /&gt;
&lt;br /&gt;
====Week 6====&lt;br /&gt;
5th-July-10 to 11th-July-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Annotate rankine.a4c for Canvas Modelling.&lt;br /&gt;
*Solve [[#Simple Rankine Cycle]] through Canvas Modeller.&lt;br /&gt;
*GUI to add extra canvas MODEL equations/declarations.&lt;br /&gt;
*Work towards getting [[#Type Information]]&lt;br /&gt;
*Fix key-accel to Menu items.&lt;br /&gt;
*GUI for value-indicators of solved variables.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Status of Work&#039;&#039;&lt;br /&gt;
*Annotated  {{src|models/johnpye/rankine.a4c}} and successfully Solved [[#Simple Rankine Cycle]] through Canvas Modeller.&lt;br /&gt;
*User can now add extra canvas MODEL equations/declarations.&lt;br /&gt;
*Menu items key-accel&#039;s improved.&lt;br /&gt;
*Other GUI improvements like extra Canvas-properties pop-up, more items to Contextmenu, etc.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Issues&#039;&#039;&lt;br /&gt;
*What if a parameter is not fixed but has a value? Could not understand what does it mean.&lt;br /&gt;
*Need a more intuitive way to add the extra declarations, like real time visible addition to the MODEL code rather than having a separate tab.&lt;br /&gt;
*[[#Type Information]] still requires extra thinking and a lot of work.&lt;br /&gt;
&lt;br /&gt;
====Week 7====&lt;br /&gt;
12th-July-10 to 18th-July-10&lt;br /&gt;
*Submit Mid Term Evaluations&lt;br /&gt;
&lt;br /&gt;
====Week 8====&lt;br /&gt;
19th-July-10 to 25th-July-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 9====&lt;br /&gt;
26th-July-10 to 1st-August-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 10====&lt;br /&gt;
2nd-August-10 to 8th-August-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 11====&lt;br /&gt;
9th-August-10 to 16th-August-10&lt;br /&gt;
*Finalise work&lt;br /&gt;
*Submit End Term Evaluations&lt;br /&gt;
*Tie loose ends&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=933</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=933"/>
		<updated>2010-07-12T21:16:09Z</updated>

		<summary type="html">&lt;p&gt;Grivan: /* Week 0 */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 development carried out by [[User:Grivan|Grivan]]. The goals and tasks are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. Efforts will be to make the modeller powerful enough for some real and serious modelling. Use Cases are being developed as to see what do we expect from our modeller to be able to do for us, to identify the most important aspects and implement them.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
TODO : Add more ideas, put a concrete solution overview to each Case.&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
*Global Model equations.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
*Block rotation.&lt;br /&gt;
*:It would be nice if blocks could be rotated, it makes the canvas look more tidy.&lt;br /&gt;
*Other Issues.&lt;br /&gt;
*:Just specifying a value and not Fixing it. Should it be possible? &lt;br /&gt;
*: How to make additions of equations to the MODEL more intuitive.&lt;br /&gt;
&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}}. We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece. In addition take care of the ALIASES keyword used in the text model. TODO&lt;br /&gt;
*Elimination of redundant equations in closed loop flows.&lt;br /&gt;
*:Multiple loops present in the system.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Still needs to be discussed. TODO&lt;br /&gt;
*Specifications of flow streams. &lt;br /&gt;
*:It should be possible to switch between stream components, water to CO2 to toluene for example.&lt;br /&gt;
*:This however should &#039;&#039;&#039;not&#039;&#039;&#039; involve redrawing the whole model again.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Streams can be defined in the canvas by selecting the particular connections and specifying the stream component, the connections to these components at the ports must use the values of stream component provided. TODO&lt;br /&gt;
*Providing complex flow streams.&lt;br /&gt;
*:A regenerative cycle requires to specify the fraction of steam extracted at the &#039;&#039;bled&#039;&#039; point, that is a TEE in our sense. Such a fraction must be supplied by the user while making such connections. Assuming an open feedwater scheme.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; This should be easy as a simple TEE component must have a fixable variable &#039;fraction&#039;.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*In this case connections may need to be manually specified in order to provide complex flows as required.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious.&lt;br /&gt;
**For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling of Servo Motor with backlash and PID control===&lt;br /&gt;
*TODO : Add description&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head.&lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
TODO : Keep adding details&lt;br /&gt;
&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
==Improvements on the Solving Process==&lt;br /&gt;
Since we have no Type informations the solving is done primarily by first generating a string representation of the complete MODEL and then exported to the solver. This can lead to problems while trying to solve complex models requiring a large time to solve, because each time a variable is changed the complete model has to solved again. In case of PyGTK GUI we have a more powerful interaction with the solver and thus can change parameters without discarding the already solved model. The basic problem here lies in the fact that we don&#039;t instantiate the model first and then solve it.&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified. This provides and excellent way to have the same model provide simulation for any number of streams. Two implementations have to be taken care of to specify streams;&lt;br /&gt;
*GUI implementation:&lt;br /&gt;
*:This would provide a suitable GUI to select the stream.&lt;br /&gt;
*Application level implementation&lt;br /&gt;
*:This would add actual stream modifications to the block code.&lt;br /&gt;
The [[#Simple Rankine Cycle]] could be solved simply by connecting steam_port connectors. The {{src|models/johnpye/rankine.a4c}} uses Steam as the only modelling stream. This model needs to be evolved to use generic port types so that a better and more deep understanding is achieved in the problem of specifying flow streams.&lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now.&lt;br /&gt;
&lt;br /&gt;
*To have highlighting of connectible ports while connecting two ports we need to:&lt;br /&gt;
*#Find all suitable (IN/OUT/BOTH) ports available for connection.&lt;br /&gt;
*#Create a set their Types.&lt;br /&gt;
*#Check connect-ability for each of those types.&lt;br /&gt;
*#Highlight only the connectible ones.&lt;br /&gt;
&lt;br /&gt;
*To give a set of units that can be selected from a drop down menu in block properties:&lt;br /&gt;
*#Scan for the Type of the parameter.&lt;br /&gt;
*#Get the dimensions of the type.&lt;br /&gt;
*#Scan for the units available. &lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Key Deliverables==&lt;br /&gt;
To set a stone for the GSoC project following have to be implemented&lt;br /&gt;
*Canvas Model for a Regenerative Rankine cycle&lt;br /&gt;
*Ammonia synthesis reactor&lt;br /&gt;
*Support for user customisable icon-types for blocks&lt;br /&gt;
*Undo Support&lt;br /&gt;
&lt;br /&gt;
==Weekly Reports==&lt;br /&gt;
&lt;br /&gt;
The weekly reports will be filed here. Week 0 starts from 24th of May up-to 30th of May and so on.&lt;br /&gt;
&lt;br /&gt;
====Week 0====&lt;br /&gt;
24th-May-10 to 30th-May-10&lt;br /&gt;
*Set up environment&lt;br /&gt;
*Attempt to try and get modeller running&lt;br /&gt;
*:Code updates for Gaphas HEAD using and Arijit&#039;s patch and some extra edits&lt;br /&gt;
*:Except for connections feature canvas code successfully updates for Gaphas HEAD&lt;br /&gt;
*:Code updates for py-gtksourceview2, enabled syntax highlighting&lt;br /&gt;
*Other minor issues resolved&lt;br /&gt;
*Unavailable for project completely due to scheduled end semester exams from 24th-July-10 to 2nd-July-10&lt;br /&gt;
&lt;br /&gt;
====Week 1====&lt;br /&gt;
31st-May-10 to 6th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;This was a &#039;pull-up-socks&#039; week, main aim was to get back on after exams and prioritise work&lt;br /&gt;
*Attempt to fix the connections code&lt;br /&gt;
*#Connection disconnection done, using Gaphas&#039; new Aspects API. Still need a way to reconnect&lt;br /&gt;
*Start identifying crucial aspects for Canvas Modelling&lt;br /&gt;
*Started developing Use-Cases&lt;br /&gt;
*Had a meet with Prof Kannan. Got a huge motivation&lt;br /&gt;
*#Got in touch with Shrikanth and Ankit to identify aspects for use of Canvas modeller in a class room environment&lt;br /&gt;
*#Got in touch with Delhi FOSS community&lt;br /&gt;
*Started working on implementation details for Type-Checking, Closed-Loop flow sheets, User-customisable icons&lt;br /&gt;
*Got this wiki page up&lt;br /&gt;
&lt;br /&gt;
====Week 2====&lt;br /&gt;
7th-June-10 to 13th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Complete study of use cases&lt;br /&gt;
*Have connections code completely set, robust and future ready&lt;br /&gt;
*Have implementation details of at least one of the GUI features&lt;br /&gt;
&#039;&#039;Status of work&#039;&#039;&lt;br /&gt;
*The canvas connection code is completely done. User can connect/disconnect items multiple times.&lt;br /&gt;
*Improved the block propertied dialogue box a lot. &lt;br /&gt;
*#Shifted the basic structure to XML, using Glade.&lt;br /&gt;
*#Due to no implementation of [[#Type Information]], setting units may still create a problem.&lt;br /&gt;
*#Parameters are now viewable through a List view.&lt;br /&gt;
*Use cases still need more work.&lt;br /&gt;
*Worked out some details of implementing Undo/Redo system. Starting the work to implement them.&lt;br /&gt;
&lt;br /&gt;
====Week 3====&lt;br /&gt;
14th-June-10 to 20th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Set up the Undo/Redo system.&lt;br /&gt;
*Improve the Unit checking.&lt;br /&gt;
*Get ideas, implementation details on [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Status of Work&#039;&#039;&lt;br /&gt;
*A very basic Undo system in place.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Issues&#039;&#039;&lt;br /&gt;
*Identifying a way to record Undo transactions took a large part of the week, could not complete other objectives.&lt;br /&gt;
&lt;br /&gt;
====Week 4====&lt;br /&gt;
21st-June-10 to 27th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO LIST&#039;&#039;&lt;br /&gt;
*Thoroughly test Undo system.&lt;br /&gt;
*Improve the Unit checking.&lt;br /&gt;
*Get ideas, implementation details on [[#Support for user-customisable custom icon types]]. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Status of Work&#039;&#039;&lt;br /&gt;
*Did many improvements to the Undo system.&lt;br /&gt;
*Improved the Key Accel&#039;s&lt;br /&gt;
*Improved Connections code.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Issues&#039;&#039;&lt;br /&gt;
*Callback functions do not record in gaphas as an event, so Undo system breaks at undoing a disconnect of Line Connection.&lt;br /&gt;
*Went through much of ASCEND API, but still not being able to identify Types and thus Units of parameters of blocks. For a temporary solution tried a failed attempt to get a Simulation of the String Model and identify Types. &lt;br /&gt;
*Problem lies in not being able to get [[#Type Information]] in the model by name, which is the only information we have from annotations.&lt;br /&gt;
*Finding ways for [[#Support for user-customisable custom icon types]] implementation details, studied how Modellica handles Graphic properties of blocks.&lt;br /&gt;
&lt;br /&gt;
====Week 5====&lt;br /&gt;
28th-June-10 to 4th-July-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Set up freesteam, solve and study rankine.a4c&lt;br /&gt;
*Try to implement [[#Support for user-customisable custom icon types]] by Mid-Term, get implementation details and begin work.&lt;br /&gt;
*Check for solutions for Line connection Undo bug.&lt;br /&gt;
*Find a way for getting [[#Type Information]].&lt;br /&gt;
*Deal with [[#Bugs]].&lt;br /&gt;
&lt;br /&gt;
====Week 6====&lt;br /&gt;
5th-July-10 to 11th-July-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Annotate rankine.a4c for Canvas Modelling.&lt;br /&gt;
*Solve [[#Simple Rankine Cycle]] through Canvas Modeller.&lt;br /&gt;
*GUI to add extra canvas MODEL equations/declarations.&lt;br /&gt;
*Work towards getting [[#Type Information]]&lt;br /&gt;
*Fix key-accel to Menu items.&lt;br /&gt;
*GUI for value-indicators of solved variables.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Status of Work&#039;&#039;&lt;br /&gt;
*Annotated  {{src|models/johnpye/rankine.a4c}} and successfully Solved [[#Simple Rankine Cycle]] through Canvas Modeller.&lt;br /&gt;
*User can now add extra canvas MODEL equations/declarations.&lt;br /&gt;
*Menu items key-accel&#039;s improved.&lt;br /&gt;
*Other GUI improvements like extra Canvas-properties pop-up, more items to Contextmenu, etc.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Issues&#039;&#039;&lt;br /&gt;
*What if a parameter is not fixed but has a value? Could not understand what does it mean.&lt;br /&gt;
*Need a more intuitive way to add the extra declarations, like real time visible addition to the MODEL code rather than having a separate tab.&lt;br /&gt;
*[[#Type Information]] still requires extra thinking and a lot of work.&lt;br /&gt;
&lt;br /&gt;
====Week 7====&lt;br /&gt;
12th-July-10 to 18th-July-10&lt;br /&gt;
*Submit Mid Term Evaluations&lt;br /&gt;
&lt;br /&gt;
====Week 8====&lt;br /&gt;
19th-July-10 to 25th-July-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 9====&lt;br /&gt;
26th-July-10 to 1st-August-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 10====&lt;br /&gt;
2nd-August-10 to 8th-August-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 11====&lt;br /&gt;
9th-August-10 to 16th-August-10&lt;br /&gt;
*Finalise work&lt;br /&gt;
*Submit End Term Evaluations&lt;br /&gt;
*Tie loose ends&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=932</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=932"/>
		<updated>2010-07-12T21:14:58Z</updated>

		<summary type="html">&lt;p&gt;Grivan: /* Week 6 */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 development carried out by [[User:Grivan|Grivan]]. The goals and tasks are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. Efforts will be to make the modeller powerful enough for some real and serious modelling. Use Cases are being developed as to see what do we expect from our modeller to be able to do for us, to identify the most important aspects and implement them.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
TODO : Add more ideas, put a concrete solution overview to each Case.&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
*Global Model equations.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
*Block rotation.&lt;br /&gt;
*:It would be nice if blocks could be rotated, it makes the canvas look more tidy.&lt;br /&gt;
*Other Issues.&lt;br /&gt;
*:Just specifying a value and not Fixing it. Should it be possible? &lt;br /&gt;
*: How to make additions of equations to the MODEL more intuitive.&lt;br /&gt;
&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}}. We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece. In addition take care of the ALIASES keyword used in the text model. TODO&lt;br /&gt;
*Elimination of redundant equations in closed loop flows.&lt;br /&gt;
*:Multiple loops present in the system.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Still needs to be discussed. TODO&lt;br /&gt;
*Specifications of flow streams. &lt;br /&gt;
*:It should be possible to switch between stream components, water to CO2 to toluene for example.&lt;br /&gt;
*:This however should &#039;&#039;&#039;not&#039;&#039;&#039; involve redrawing the whole model again.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Streams can be defined in the canvas by selecting the particular connections and specifying the stream component, the connections to these components at the ports must use the values of stream component provided. TODO&lt;br /&gt;
*Providing complex flow streams.&lt;br /&gt;
*:A regenerative cycle requires to specify the fraction of steam extracted at the &#039;&#039;bled&#039;&#039; point, that is a TEE in our sense. Such a fraction must be supplied by the user while making such connections. Assuming an open feedwater scheme.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; This should be easy as a simple TEE component must have a fixable variable &#039;fraction&#039;.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*In this case connections may need to be manually specified in order to provide complex flows as required.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious.&lt;br /&gt;
**For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling of Servo Motor with backlash and PID control===&lt;br /&gt;
*TODO : Add description&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head.&lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
TODO : Keep adding details&lt;br /&gt;
&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
==Improvements on the Solving Process==&lt;br /&gt;
Since we have no Type informations the solving is done primarily by first generating a string representation of the complete MODEL and then exported to the solver. This can lead to problems while trying to solve complex models requiring a large time to solve, because each time a variable is changed the complete model has to solved again. In case of PyGTK GUI we have a more powerful interaction with the solver and thus can change parameters without discarding the already solved model. The basic problem here lies in the fact that we don&#039;t instantiate the model first and then solve it.&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified. This provides and excellent way to have the same model provide simulation for any number of streams. Two implementations have to be taken care of to specify streams;&lt;br /&gt;
*GUI implementation:&lt;br /&gt;
*:This would provide a suitable GUI to select the stream.&lt;br /&gt;
*Application level implementation&lt;br /&gt;
*:This would add actual stream modifications to the block code.&lt;br /&gt;
The [[#Simple Rankine Cycle]] could be solved simply by connecting steam_port connectors. The {{src|models/johnpye/rankine.a4c}} uses Steam as the only modelling stream. This model needs to be evolved to use generic port types so that a better and more deep understanding is achieved in the problem of specifying flow streams.&lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now.&lt;br /&gt;
&lt;br /&gt;
*To have highlighting of connectible ports while connecting two ports we need to:&lt;br /&gt;
*#Find all suitable (IN/OUT/BOTH) ports available for connection.&lt;br /&gt;
*#Create a set their Types.&lt;br /&gt;
*#Check connect-ability for each of those types.&lt;br /&gt;
*#Highlight only the connectible ones.&lt;br /&gt;
&lt;br /&gt;
*To give a set of units that can be selected from a drop down menu in block properties:&lt;br /&gt;
*#Scan for the Type of the parameter.&lt;br /&gt;
*#Get the dimensions of the type.&lt;br /&gt;
*#Scan for the units available. &lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Key Deliverables==&lt;br /&gt;
To set a stone for the GSoC project following have to be implemented&lt;br /&gt;
*Canvas Model for a Regenerative Rankine cycle&lt;br /&gt;
*Ammonia synthesis reactor&lt;br /&gt;
*Support for user customisable icon-types for blocks&lt;br /&gt;
*Undo Support&lt;br /&gt;
&lt;br /&gt;
==Weekly Reports==&lt;br /&gt;
&lt;br /&gt;
The weekly reports will be filed here. Week 0 starts from 24th of May up-to 30th of May and so on.&lt;br /&gt;
&lt;br /&gt;
====Week 0====&lt;br /&gt;
24th-May-10 to 30th-May-10&lt;br /&gt;
*Set up environment&lt;br /&gt;
*Attempt to try and get modeller running&lt;br /&gt;
*#Code updates for Gaphas HEAD using and Arijit&#039;s patch and some extra edits&lt;br /&gt;
*#:Except for connections feature canvas code successfully updates for Gaphas HEAD&lt;br /&gt;
*#Code updates for py-gtksourceview2, enabled syntax highlighting&lt;br /&gt;
*Other minor issues resolved&lt;br /&gt;
*Unavailable for project completely due to scheduled end semester exams from 24th-July-10 to 2nd-July-10&lt;br /&gt;
&lt;br /&gt;
====Week 1====&lt;br /&gt;
31st-May-10 to 6th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;This was a &#039;pull-up-socks&#039; week, main aim was to get back on after exams and prioritise work&lt;br /&gt;
*Attempt to fix the connections code&lt;br /&gt;
*#Connection disconnection done, using Gaphas&#039; new Aspects API. Still need a way to reconnect&lt;br /&gt;
*Start identifying crucial aspects for Canvas Modelling&lt;br /&gt;
*Started developing Use-Cases&lt;br /&gt;
*Had a meet with Prof Kannan. Got a huge motivation&lt;br /&gt;
*#Got in touch with Shrikanth and Ankit to identify aspects for use of Canvas modeller in a class room environment&lt;br /&gt;
*#Got in touch with Delhi FOSS community&lt;br /&gt;
*Started working on implementation details for Type-Checking, Closed-Loop flow sheets, User-customisable icons&lt;br /&gt;
*Got this wiki page up&lt;br /&gt;
&lt;br /&gt;
====Week 2====&lt;br /&gt;
7th-June-10 to 13th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Complete study of use cases&lt;br /&gt;
*Have connections code completely set, robust and future ready&lt;br /&gt;
*Have implementation details of at least one of the GUI features&lt;br /&gt;
&#039;&#039;Status of work&#039;&#039;&lt;br /&gt;
*The canvas connection code is completely done. User can connect/disconnect items multiple times.&lt;br /&gt;
*Improved the block propertied dialogue box a lot. &lt;br /&gt;
*#Shifted the basic structure to XML, using Glade.&lt;br /&gt;
*#Due to no implementation of [[#Type Information]], setting units may still create a problem.&lt;br /&gt;
*#Parameters are now viewable through a List view.&lt;br /&gt;
*Use cases still need more work.&lt;br /&gt;
*Worked out some details of implementing Undo/Redo system. Starting the work to implement them.&lt;br /&gt;
&lt;br /&gt;
====Week 3====&lt;br /&gt;
14th-June-10 to 20th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Set up the Undo/Redo system.&lt;br /&gt;
*Improve the Unit checking.&lt;br /&gt;
*Get ideas, implementation details on [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Status of Work&#039;&#039;&lt;br /&gt;
*A very basic Undo system in place.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Issues&#039;&#039;&lt;br /&gt;
*Identifying a way to record Undo transactions took a large part of the week, could not complete other objectives.&lt;br /&gt;
&lt;br /&gt;
====Week 4====&lt;br /&gt;
21st-June-10 to 27th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO LIST&#039;&#039;&lt;br /&gt;
*Thoroughly test Undo system.&lt;br /&gt;
*Improve the Unit checking.&lt;br /&gt;
*Get ideas, implementation details on [[#Support for user-customisable custom icon types]]. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Status of Work&#039;&#039;&lt;br /&gt;
*Did many improvements to the Undo system.&lt;br /&gt;
*Improved the Key Accel&#039;s&lt;br /&gt;
*Improved Connections code.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Issues&#039;&#039;&lt;br /&gt;
*Callback functions do not record in gaphas as an event, so Undo system breaks at undoing a disconnect of Line Connection.&lt;br /&gt;
*Went through much of ASCEND API, but still not being able to identify Types and thus Units of parameters of blocks. For a temporary solution tried a failed attempt to get a Simulation of the String Model and identify Types. &lt;br /&gt;
*Problem lies in not being able to get [[#Type Information]] in the model by name, which is the only information we have from annotations.&lt;br /&gt;
*Finding ways for [[#Support for user-customisable custom icon types]] implementation details, studied how Modellica handles Graphic properties of blocks.&lt;br /&gt;
&lt;br /&gt;
====Week 5====&lt;br /&gt;
28th-June-10 to 4th-July-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Set up freesteam, solve and study rankine.a4c&lt;br /&gt;
*Try to implement [[#Support for user-customisable custom icon types]] by Mid-Term, get implementation details and begin work.&lt;br /&gt;
*Check for solutions for Line connection Undo bug.&lt;br /&gt;
*Find a way for getting [[#Type Information]].&lt;br /&gt;
*Deal with [[#Bugs]].&lt;br /&gt;
&lt;br /&gt;
====Week 6====&lt;br /&gt;
5th-July-10 to 11th-July-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Annotate rankine.a4c for Canvas Modelling.&lt;br /&gt;
*Solve [[#Simple Rankine Cycle]] through Canvas Modeller.&lt;br /&gt;
*GUI to add extra canvas MODEL equations/declarations.&lt;br /&gt;
*Work towards getting [[#Type Information]]&lt;br /&gt;
*Fix key-accel to Menu items.&lt;br /&gt;
*GUI for value-indicators of solved variables.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Status of Work&#039;&#039;&lt;br /&gt;
*Annotated  {{src|models/johnpye/rankine.a4c}} and successfully Solved [[#Simple Rankine Cycle]] through Canvas Modeller.&lt;br /&gt;
*User can now add extra canvas MODEL equations/declarations.&lt;br /&gt;
*Menu items key-accel&#039;s improved.&lt;br /&gt;
*Other GUI improvements like extra Canvas-properties pop-up, more items to Contextmenu, etc.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Issues&#039;&#039;&lt;br /&gt;
*What if a parameter is not fixed but has a value? Could not understand what does it mean.&lt;br /&gt;
*Need a more intuitive way to add the extra declarations, like real time visible addition to the MODEL code rather than having a separate tab.&lt;br /&gt;
*[[#Type Information]] still requires extra thinking and a lot of work.&lt;br /&gt;
&lt;br /&gt;
====Week 7====&lt;br /&gt;
12th-July-10 to 18th-July-10&lt;br /&gt;
*Submit Mid Term Evaluations&lt;br /&gt;
&lt;br /&gt;
====Week 8====&lt;br /&gt;
19th-July-10 to 25th-July-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 9====&lt;br /&gt;
26th-July-10 to 1st-August-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 10====&lt;br /&gt;
2nd-August-10 to 8th-August-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 11====&lt;br /&gt;
9th-August-10 to 16th-August-10&lt;br /&gt;
*Finalise work&lt;br /&gt;
*Submit End Term Evaluations&lt;br /&gt;
*Tie loose ends&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=931</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=931"/>
		<updated>2010-07-12T21:13:06Z</updated>

		<summary type="html">&lt;p&gt;Grivan: /* Week 6 */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 development carried out by [[User:Grivan|Grivan]]. The goals and tasks are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. Efforts will be to make the modeller powerful enough for some real and serious modelling. Use Cases are being developed as to see what do we expect from our modeller to be able to do for us, to identify the most important aspects and implement them.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
TODO : Add more ideas, put a concrete solution overview to each Case.&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
*Global Model equations.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
*Block rotation.&lt;br /&gt;
*:It would be nice if blocks could be rotated, it makes the canvas look more tidy.&lt;br /&gt;
*Other Issues.&lt;br /&gt;
*:Just specifying a value and not Fixing it. Should it be possible? &lt;br /&gt;
*: How to make additions of equations to the MODEL more intuitive.&lt;br /&gt;
&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}}. We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece. In addition take care of the ALIASES keyword used in the text model. TODO&lt;br /&gt;
*Elimination of redundant equations in closed loop flows.&lt;br /&gt;
*:Multiple loops present in the system.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Still needs to be discussed. TODO&lt;br /&gt;
*Specifications of flow streams. &lt;br /&gt;
*:It should be possible to switch between stream components, water to CO2 to toluene for example.&lt;br /&gt;
*:This however should &#039;&#039;&#039;not&#039;&#039;&#039; involve redrawing the whole model again.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Streams can be defined in the canvas by selecting the particular connections and specifying the stream component, the connections to these components at the ports must use the values of stream component provided. TODO&lt;br /&gt;
*Providing complex flow streams.&lt;br /&gt;
*:A regenerative cycle requires to specify the fraction of steam extracted at the &#039;&#039;bled&#039;&#039; point, that is a TEE in our sense. Such a fraction must be supplied by the user while making such connections. Assuming an open feedwater scheme.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; This should be easy as a simple TEE component must have a fixable variable &#039;fraction&#039;.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*In this case connections may need to be manually specified in order to provide complex flows as required.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious.&lt;br /&gt;
**For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling of Servo Motor with backlash and PID control===&lt;br /&gt;
*TODO : Add description&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head.&lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
TODO : Keep adding details&lt;br /&gt;
&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
==Improvements on the Solving Process==&lt;br /&gt;
Since we have no Type informations the solving is done primarily by first generating a string representation of the complete MODEL and then exported to the solver. This can lead to problems while trying to solve complex models requiring a large time to solve, because each time a variable is changed the complete model has to solved again. In case of PyGTK GUI we have a more powerful interaction with the solver and thus can change parameters without discarding the already solved model. The basic problem here lies in the fact that we don&#039;t instantiate the model first and then solve it.&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified. This provides and excellent way to have the same model provide simulation for any number of streams. Two implementations have to be taken care of to specify streams;&lt;br /&gt;
*GUI implementation:&lt;br /&gt;
*:This would provide a suitable GUI to select the stream.&lt;br /&gt;
*Application level implementation&lt;br /&gt;
*:This would add actual stream modifications to the block code.&lt;br /&gt;
The [[#Simple Rankine Cycle]] could be solved simply by connecting steam_port connectors. The {{src|models/johnpye/rankine.a4c}} uses Steam as the only modelling stream. This model needs to be evolved to use generic port types so that a better and more deep understanding is achieved in the problem of specifying flow streams.&lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now.&lt;br /&gt;
&lt;br /&gt;
*To have highlighting of connectible ports while connecting two ports we need to:&lt;br /&gt;
*#Find all suitable (IN/OUT/BOTH) ports available for connection.&lt;br /&gt;
*#Create a set their Types.&lt;br /&gt;
*#Check connect-ability for each of those types.&lt;br /&gt;
*#Highlight only the connectible ones.&lt;br /&gt;
&lt;br /&gt;
*To give a set of units that can be selected from a drop down menu in block properties:&lt;br /&gt;
*#Scan for the Type of the parameter.&lt;br /&gt;
*#Get the dimensions of the type.&lt;br /&gt;
*#Scan for the units available. &lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Key Deliverables==&lt;br /&gt;
To set a stone for the GSoC project following have to be implemented&lt;br /&gt;
*Canvas Model for a Regenerative Rankine cycle&lt;br /&gt;
*Ammonia synthesis reactor&lt;br /&gt;
*Support for user customisable icon-types for blocks&lt;br /&gt;
*Undo Support&lt;br /&gt;
&lt;br /&gt;
==Weekly Reports==&lt;br /&gt;
&lt;br /&gt;
The weekly reports will be filed here. Week 0 starts from 24th of May up-to 30th of May and so on.&lt;br /&gt;
&lt;br /&gt;
====Week 0====&lt;br /&gt;
24th-May-10 to 30th-May-10&lt;br /&gt;
*Set up environment&lt;br /&gt;
*Attempt to try and get modeller running&lt;br /&gt;
*#Code updates for Gaphas HEAD using and Arijit&#039;s patch and some extra edits&lt;br /&gt;
*#:Except for connections feature canvas code successfully updates for Gaphas HEAD&lt;br /&gt;
*#Code updates for py-gtksourceview2, enabled syntax highlighting&lt;br /&gt;
*Other minor issues resolved&lt;br /&gt;
*Unavailable for project completely due to scheduled end semester exams from 24th-July-10 to 2nd-July-10&lt;br /&gt;
&lt;br /&gt;
====Week 1====&lt;br /&gt;
31st-May-10 to 6th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;This was a &#039;pull-up-socks&#039; week, main aim was to get back on after exams and prioritise work&lt;br /&gt;
*Attempt to fix the connections code&lt;br /&gt;
*#Connection disconnection done, using Gaphas&#039; new Aspects API. Still need a way to reconnect&lt;br /&gt;
*Start identifying crucial aspects for Canvas Modelling&lt;br /&gt;
*Started developing Use-Cases&lt;br /&gt;
*Had a meet with Prof Kannan. Got a huge motivation&lt;br /&gt;
*#Got in touch with Shrikanth and Ankit to identify aspects for use of Canvas modeller in a class room environment&lt;br /&gt;
*#Got in touch with Delhi FOSS community&lt;br /&gt;
*Started working on implementation details for Type-Checking, Closed-Loop flow sheets, User-customisable icons&lt;br /&gt;
*Got this wiki page up&lt;br /&gt;
&lt;br /&gt;
====Week 2====&lt;br /&gt;
7th-June-10 to 13th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Complete study of use cases&lt;br /&gt;
*Have connections code completely set, robust and future ready&lt;br /&gt;
*Have implementation details of at least one of the GUI features&lt;br /&gt;
&#039;&#039;Status of work&#039;&#039;&lt;br /&gt;
*The canvas connection code is completely done. User can connect/disconnect items multiple times.&lt;br /&gt;
*Improved the block propertied dialogue box a lot. &lt;br /&gt;
*#Shifted the basic structure to XML, using Glade.&lt;br /&gt;
*#Due to no implementation of [[#Type Information]], setting units may still create a problem.&lt;br /&gt;
*#Parameters are now viewable through a List view.&lt;br /&gt;
*Use cases still need more work.&lt;br /&gt;
*Worked out some details of implementing Undo/Redo system. Starting the work to implement them.&lt;br /&gt;
&lt;br /&gt;
====Week 3====&lt;br /&gt;
14th-June-10 to 20th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Set up the Undo/Redo system.&lt;br /&gt;
*Improve the Unit checking.&lt;br /&gt;
*Get ideas, implementation details on [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Status of Work&#039;&#039;&lt;br /&gt;
*A very basic Undo system in place.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Issues&#039;&#039;&lt;br /&gt;
*Identifying a way to record Undo transactions took a large part of the week, could not complete other objectives.&lt;br /&gt;
&lt;br /&gt;
====Week 4====&lt;br /&gt;
21st-June-10 to 27th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO LIST&#039;&#039;&lt;br /&gt;
*Thoroughly test Undo system.&lt;br /&gt;
*Improve the Unit checking.&lt;br /&gt;
*Get ideas, implementation details on [[#Support for user-customisable custom icon types]]. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Status of Work&#039;&#039;&lt;br /&gt;
*Did many improvements to the Undo system.&lt;br /&gt;
*Improved the Key Accel&#039;s&lt;br /&gt;
*Improved Connections code.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Issues&#039;&#039;&lt;br /&gt;
*Callback functions do not record in gaphas as an event, so Undo system breaks at undoing a disconnect of Line Connection.&lt;br /&gt;
*Went through much of ASCEND API, but still not being able to identify Types and thus Units of parameters of blocks. For a temporary solution tried a failed attempt to get a Simulation of the String Model and identify Types. &lt;br /&gt;
*Problem lies in not being able to get [[#Type Information]] in the model by name, which is the only information we have from annotations.&lt;br /&gt;
*Finding ways for [[#Support for user-customisable custom icon types]] implementation details, studied how Modellica handles Graphic properties of blocks.&lt;br /&gt;
&lt;br /&gt;
====Week 5====&lt;br /&gt;
28th-June-10 to 4th-July-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Set up freesteam, solve and study rankine.a4c&lt;br /&gt;
*Try to implement [[#Support for user-customisable custom icon types]] by Mid-Term, get implementation details and begin work.&lt;br /&gt;
*Check for solutions for Line connection Undo bug.&lt;br /&gt;
*Find a way for getting [[#Type Information]].&lt;br /&gt;
*Deal with [[#Bugs]].&lt;br /&gt;
&lt;br /&gt;
====Week 6====&lt;br /&gt;
5th-July-10 to 11th-July-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Annotate rankine.a4c for Canvas Modelling.&lt;br /&gt;
*Solve [[#Simple Rankine Cycle]] through Canvas Modeller.&lt;br /&gt;
*GUI to add extra canvas MODEL equations/declarations.&lt;br /&gt;
*Work towards getting [[#Type Information]]&lt;br /&gt;
*Fix key-accel to Menu items.&lt;br /&gt;
*GUI for value-indicators of solved variables.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Status of Work&#039;&#039;&lt;br /&gt;
*Solved [[#Simple Rankine Cycle]] through Canvas Modeller.&lt;br /&gt;
*User can now add extra canvas MODEL equations/declarations.&lt;br /&gt;
*Menu items key-accel&#039;s improved.&lt;br /&gt;
*Other GUI improvements like extra Canvas-properties pop-up, more items to Contextmenu, etc.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Issues&#039;&#039;&lt;br /&gt;
*What if a parameter is not fixed but has a value? Could not understand what does it mean.&lt;br /&gt;
*Need a more intuitive way to add the extra declarations, like real time visible addition to the MODEL code rather than having a separate tab.&lt;br /&gt;
*[[#Type Information]] still requires extra thinking and a lot of work.&lt;br /&gt;
&lt;br /&gt;
====Week 7====&lt;br /&gt;
12th-July-10 to 18th-July-10&lt;br /&gt;
*Submit Mid Term Evaluations&lt;br /&gt;
&lt;br /&gt;
====Week 8====&lt;br /&gt;
19th-July-10 to 25th-July-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 9====&lt;br /&gt;
26th-July-10 to 1st-August-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 10====&lt;br /&gt;
2nd-August-10 to 8th-August-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 11====&lt;br /&gt;
9th-August-10 to 16th-August-10&lt;br /&gt;
*Finalise work&lt;br /&gt;
*Submit End Term Evaluations&lt;br /&gt;
*Tie loose ends&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=930</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=930"/>
		<updated>2010-07-12T21:02:30Z</updated>

		<summary type="html">&lt;p&gt;Grivan: /* Specification of flow streams */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 development carried out by [[User:Grivan|Grivan]]. The goals and tasks are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. Efforts will be to make the modeller powerful enough for some real and serious modelling. Use Cases are being developed as to see what do we expect from our modeller to be able to do for us, to identify the most important aspects and implement them.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
TODO : Add more ideas, put a concrete solution overview to each Case.&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
*Global Model equations.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
*Block rotation.&lt;br /&gt;
*:It would be nice if blocks could be rotated, it makes the canvas look more tidy.&lt;br /&gt;
*Other Issues.&lt;br /&gt;
*:Just specifying a value and not Fixing it. Should it be possible? &lt;br /&gt;
*: How to make additions of equations to the MODEL more intuitive.&lt;br /&gt;
&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}}. We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece. In addition take care of the ALIASES keyword used in the text model. TODO&lt;br /&gt;
*Elimination of redundant equations in closed loop flows.&lt;br /&gt;
*:Multiple loops present in the system.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Still needs to be discussed. TODO&lt;br /&gt;
*Specifications of flow streams. &lt;br /&gt;
*:It should be possible to switch between stream components, water to CO2 to toluene for example.&lt;br /&gt;
*:This however should &#039;&#039;&#039;not&#039;&#039;&#039; involve redrawing the whole model again.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Streams can be defined in the canvas by selecting the particular connections and specifying the stream component, the connections to these components at the ports must use the values of stream component provided. TODO&lt;br /&gt;
*Providing complex flow streams.&lt;br /&gt;
*:A regenerative cycle requires to specify the fraction of steam extracted at the &#039;&#039;bled&#039;&#039; point, that is a TEE in our sense. Such a fraction must be supplied by the user while making such connections. Assuming an open feedwater scheme.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; This should be easy as a simple TEE component must have a fixable variable &#039;fraction&#039;.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*In this case connections may need to be manually specified in order to provide complex flows as required.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious.&lt;br /&gt;
**For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling of Servo Motor with backlash and PID control===&lt;br /&gt;
*TODO : Add description&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head.&lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
TODO : Keep adding details&lt;br /&gt;
&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
==Improvements on the Solving Process==&lt;br /&gt;
Since we have no Type informations the solving is done primarily by first generating a string representation of the complete MODEL and then exported to the solver. This can lead to problems while trying to solve complex models requiring a large time to solve, because each time a variable is changed the complete model has to solved again. In case of PyGTK GUI we have a more powerful interaction with the solver and thus can change parameters without discarding the already solved model. The basic problem here lies in the fact that we don&#039;t instantiate the model first and then solve it.&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified. This provides and excellent way to have the same model provide simulation for any number of streams. Two implementations have to be taken care of to specify streams;&lt;br /&gt;
*GUI implementation:&lt;br /&gt;
*:This would provide a suitable GUI to select the stream.&lt;br /&gt;
*Application level implementation&lt;br /&gt;
*:This would add actual stream modifications to the block code.&lt;br /&gt;
The [[#Simple Rankine Cycle]] could be solved simply by connecting steam_port connectors. The {{src|models/johnpye/rankine.a4c}} uses Steam as the only modelling stream. This model needs to be evolved to use generic port types so that a better and more deep understanding is achieved in the problem of specifying flow streams.&lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now.&lt;br /&gt;
&lt;br /&gt;
*To have highlighting of connectible ports while connecting two ports we need to:&lt;br /&gt;
*#Find all suitable (IN/OUT/BOTH) ports available for connection.&lt;br /&gt;
*#Create a set their Types.&lt;br /&gt;
*#Check connect-ability for each of those types.&lt;br /&gt;
*#Highlight only the connectible ones.&lt;br /&gt;
&lt;br /&gt;
*To give a set of units that can be selected from a drop down menu in block properties:&lt;br /&gt;
*#Scan for the Type of the parameter.&lt;br /&gt;
*#Get the dimensions of the type.&lt;br /&gt;
*#Scan for the units available. &lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Key Deliverables==&lt;br /&gt;
To set a stone for the GSoC project following have to be implemented&lt;br /&gt;
*Canvas Model for a Regenerative Rankine cycle&lt;br /&gt;
*Ammonia synthesis reactor&lt;br /&gt;
*Support for user customisable icon-types for blocks&lt;br /&gt;
*Undo Support&lt;br /&gt;
&lt;br /&gt;
==Weekly Reports==&lt;br /&gt;
&lt;br /&gt;
The weekly reports will be filed here. Week 0 starts from 24th of May up-to 30th of May and so on.&lt;br /&gt;
&lt;br /&gt;
====Week 0====&lt;br /&gt;
24th-May-10 to 30th-May-10&lt;br /&gt;
*Set up environment&lt;br /&gt;
*Attempt to try and get modeller running&lt;br /&gt;
*#Code updates for Gaphas HEAD using and Arijit&#039;s patch and some extra edits&lt;br /&gt;
*#:Except for connections feature canvas code successfully updates for Gaphas HEAD&lt;br /&gt;
*#Code updates for py-gtksourceview2, enabled syntax highlighting&lt;br /&gt;
*Other minor issues resolved&lt;br /&gt;
*Unavailable for project completely due to scheduled end semester exams from 24th-July-10 to 2nd-July-10&lt;br /&gt;
&lt;br /&gt;
====Week 1====&lt;br /&gt;
31st-May-10 to 6th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;This was a &#039;pull-up-socks&#039; week, main aim was to get back on after exams and prioritise work&lt;br /&gt;
*Attempt to fix the connections code&lt;br /&gt;
*#Connection disconnection done, using Gaphas&#039; new Aspects API. Still need a way to reconnect&lt;br /&gt;
*Start identifying crucial aspects for Canvas Modelling&lt;br /&gt;
*Started developing Use-Cases&lt;br /&gt;
*Had a meet with Prof Kannan. Got a huge motivation&lt;br /&gt;
*#Got in touch with Shrikanth and Ankit to identify aspects for use of Canvas modeller in a class room environment&lt;br /&gt;
*#Got in touch with Delhi FOSS community&lt;br /&gt;
*Started working on implementation details for Type-Checking, Closed-Loop flow sheets, User-customisable icons&lt;br /&gt;
*Got this wiki page up&lt;br /&gt;
&lt;br /&gt;
====Week 2====&lt;br /&gt;
7th-June-10 to 13th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Complete study of use cases&lt;br /&gt;
*Have connections code completely set, robust and future ready&lt;br /&gt;
*Have implementation details of at least one of the GUI features&lt;br /&gt;
&#039;&#039;Status of work&#039;&#039;&lt;br /&gt;
*The canvas connection code is completely done. User can connect/disconnect items multiple times.&lt;br /&gt;
*Improved the block propertied dialogue box a lot. &lt;br /&gt;
*#Shifted the basic structure to XML, using Glade.&lt;br /&gt;
*#Due to no implementation of [[#Type Information]], setting units may still create a problem.&lt;br /&gt;
*#Parameters are now viewable through a List view.&lt;br /&gt;
*Use cases still need more work.&lt;br /&gt;
*Worked out some details of implementing Undo/Redo system. Starting the work to implement them.&lt;br /&gt;
&lt;br /&gt;
====Week 3====&lt;br /&gt;
14th-June-10 to 20th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Set up the Undo/Redo system.&lt;br /&gt;
*Improve the Unit checking.&lt;br /&gt;
*Get ideas, implementation details on [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Status of Work&#039;&#039;&lt;br /&gt;
*A very basic Undo system in place.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Issues&#039;&#039;&lt;br /&gt;
*Identifying a way to record Undo transactions took a large part of the week, could not complete other objectives.&lt;br /&gt;
&lt;br /&gt;
====Week 4====&lt;br /&gt;
21st-June-10 to 27th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO LIST&#039;&#039;&lt;br /&gt;
*Thoroughly test Undo system.&lt;br /&gt;
*Improve the Unit checking.&lt;br /&gt;
*Get ideas, implementation details on [[#Support for user-customisable custom icon types]]. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Status of Work&#039;&#039;&lt;br /&gt;
*Did many improvements to the Undo system.&lt;br /&gt;
*Improved the Key Accel&#039;s&lt;br /&gt;
*Improved Connections code.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Issues&#039;&#039;&lt;br /&gt;
*Callback functions do not record in gaphas as an event, so Undo system breaks at undoing a disconnect of Line Connection.&lt;br /&gt;
*Went through much of ASCEND API, but still not being able to identify Types and thus Units of parameters of blocks. For a temporary solution tried a failed attempt to get a Simulation of the String Model and identify Types. &lt;br /&gt;
*Problem lies in not being able to get [[#Type Information]] in the model by name, which is the only information we have from annotations.&lt;br /&gt;
*Finding ways for [[#Support for user-customisable custom icon types]] implementation details, studied how Modellica handles Graphic properties of blocks.&lt;br /&gt;
&lt;br /&gt;
====Week 5====&lt;br /&gt;
28th-June-10 to 4th-July-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Set up freesteam, solve and study rankine.a4c&lt;br /&gt;
*Try to implement [[#Support for user-customisable custom icon types]] by Mid-Term, get implementation details and begin work.&lt;br /&gt;
*Check for solutions for Line connection Undo bug.&lt;br /&gt;
*Find a way for getting [[#Type Information]].&lt;br /&gt;
*Deal with [[#Bugs]].&lt;br /&gt;
&lt;br /&gt;
====Week 6====&lt;br /&gt;
5th-July-10 to 11th-July-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
====Week 7====&lt;br /&gt;
12th-July-10 to 18th-July-10&lt;br /&gt;
*Submit Mid Term Evaluations&lt;br /&gt;
&lt;br /&gt;
====Week 8====&lt;br /&gt;
19th-July-10 to 25th-July-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 9====&lt;br /&gt;
26th-July-10 to 1st-August-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 10====&lt;br /&gt;
2nd-August-10 to 8th-August-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 11====&lt;br /&gt;
9th-August-10 to 16th-August-10&lt;br /&gt;
*Finalise work&lt;br /&gt;
*Submit End Term Evaluations&lt;br /&gt;
*Tie loose ends&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=929</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=929"/>
		<updated>2010-07-12T21:02:07Z</updated>

		<summary type="html">&lt;p&gt;Grivan: /* Specification of flow streams */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 development carried out by [[User:Grivan|Grivan]]. The goals and tasks are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. Efforts will be to make the modeller powerful enough for some real and serious modelling. Use Cases are being developed as to see what do we expect from our modeller to be able to do for us, to identify the most important aspects and implement them.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
TODO : Add more ideas, put a concrete solution overview to each Case.&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
*Global Model equations.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
*Block rotation.&lt;br /&gt;
*:It would be nice if blocks could be rotated, it makes the canvas look more tidy.&lt;br /&gt;
*Other Issues.&lt;br /&gt;
*:Just specifying a value and not Fixing it. Should it be possible? &lt;br /&gt;
*: How to make additions of equations to the MODEL more intuitive.&lt;br /&gt;
&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}}. We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece. In addition take care of the ALIASES keyword used in the text model. TODO&lt;br /&gt;
*Elimination of redundant equations in closed loop flows.&lt;br /&gt;
*:Multiple loops present in the system.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Still needs to be discussed. TODO&lt;br /&gt;
*Specifications of flow streams. &lt;br /&gt;
*:It should be possible to switch between stream components, water to CO2 to toluene for example.&lt;br /&gt;
*:This however should &#039;&#039;&#039;not&#039;&#039;&#039; involve redrawing the whole model again.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Streams can be defined in the canvas by selecting the particular connections and specifying the stream component, the connections to these components at the ports must use the values of stream component provided. TODO&lt;br /&gt;
*Providing complex flow streams.&lt;br /&gt;
*:A regenerative cycle requires to specify the fraction of steam extracted at the &#039;&#039;bled&#039;&#039; point, that is a TEE in our sense. Such a fraction must be supplied by the user while making such connections. Assuming an open feedwater scheme.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; This should be easy as a simple TEE component must have a fixable variable &#039;fraction&#039;.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*In this case connections may need to be manually specified in order to provide complex flows as required.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious.&lt;br /&gt;
**For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling of Servo Motor with backlash and PID control===&lt;br /&gt;
*TODO : Add description&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head.&lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
TODO : Keep adding details&lt;br /&gt;
&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
==Improvements on the Solving Process==&lt;br /&gt;
Since we have no Type informations the solving is done primarily by first generating a string representation of the complete MODEL and then exported to the solver. This can lead to problems while trying to solve complex models requiring a large time to solve, because each time a variable is changed the complete model has to solved again. In case of PyGTK GUI we have a more powerful interaction with the solver and thus can change parameters without discarding the already solved model. The basic problem here lies in the fact that we don&#039;t instantiate the model first and then solve it.&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified. This provides and excellent way to have the same model provide simulation for any number of streams. Two implementations have to be taken care of to specify streams;&lt;br /&gt;
*GUI implementation:&lt;br /&gt;
*:This would provide a suitable GUI to select the stream.&lt;br /&gt;
*Application level implementation&lt;br /&gt;
*:This would add actual stream modifications to the block code.&lt;br /&gt;
The [[Simple Rankine Cycle]] could be solved simply by connecting steam_port connectors. The {{src|models/johnpye/rankine.a4c}} uses Steam as the only modelling stream. This model needs to be evolved to use generic port types so that a better and more deep understanding is achieved in the problem of specifying flow streams.&lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now.&lt;br /&gt;
&lt;br /&gt;
*To have highlighting of connectible ports while connecting two ports we need to:&lt;br /&gt;
*#Find all suitable (IN/OUT/BOTH) ports available for connection.&lt;br /&gt;
*#Create a set their Types.&lt;br /&gt;
*#Check connect-ability for each of those types.&lt;br /&gt;
*#Highlight only the connectible ones.&lt;br /&gt;
&lt;br /&gt;
*To give a set of units that can be selected from a drop down menu in block properties:&lt;br /&gt;
*#Scan for the Type of the parameter.&lt;br /&gt;
*#Get the dimensions of the type.&lt;br /&gt;
*#Scan for the units available. &lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Key Deliverables==&lt;br /&gt;
To set a stone for the GSoC project following have to be implemented&lt;br /&gt;
*Canvas Model for a Regenerative Rankine cycle&lt;br /&gt;
*Ammonia synthesis reactor&lt;br /&gt;
*Support for user customisable icon-types for blocks&lt;br /&gt;
*Undo Support&lt;br /&gt;
&lt;br /&gt;
==Weekly Reports==&lt;br /&gt;
&lt;br /&gt;
The weekly reports will be filed here. Week 0 starts from 24th of May up-to 30th of May and so on.&lt;br /&gt;
&lt;br /&gt;
====Week 0====&lt;br /&gt;
24th-May-10 to 30th-May-10&lt;br /&gt;
*Set up environment&lt;br /&gt;
*Attempt to try and get modeller running&lt;br /&gt;
*#Code updates for Gaphas HEAD using and Arijit&#039;s patch and some extra edits&lt;br /&gt;
*#:Except for connections feature canvas code successfully updates for Gaphas HEAD&lt;br /&gt;
*#Code updates for py-gtksourceview2, enabled syntax highlighting&lt;br /&gt;
*Other minor issues resolved&lt;br /&gt;
*Unavailable for project completely due to scheduled end semester exams from 24th-July-10 to 2nd-July-10&lt;br /&gt;
&lt;br /&gt;
====Week 1====&lt;br /&gt;
31st-May-10 to 6th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;This was a &#039;pull-up-socks&#039; week, main aim was to get back on after exams and prioritise work&lt;br /&gt;
*Attempt to fix the connections code&lt;br /&gt;
*#Connection disconnection done, using Gaphas&#039; new Aspects API. Still need a way to reconnect&lt;br /&gt;
*Start identifying crucial aspects for Canvas Modelling&lt;br /&gt;
*Started developing Use-Cases&lt;br /&gt;
*Had a meet with Prof Kannan. Got a huge motivation&lt;br /&gt;
*#Got in touch with Shrikanth and Ankit to identify aspects for use of Canvas modeller in a class room environment&lt;br /&gt;
*#Got in touch with Delhi FOSS community&lt;br /&gt;
*Started working on implementation details for Type-Checking, Closed-Loop flow sheets, User-customisable icons&lt;br /&gt;
*Got this wiki page up&lt;br /&gt;
&lt;br /&gt;
====Week 2====&lt;br /&gt;
7th-June-10 to 13th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Complete study of use cases&lt;br /&gt;
*Have connections code completely set, robust and future ready&lt;br /&gt;
*Have implementation details of at least one of the GUI features&lt;br /&gt;
&#039;&#039;Status of work&#039;&#039;&lt;br /&gt;
*The canvas connection code is completely done. User can connect/disconnect items multiple times.&lt;br /&gt;
*Improved the block propertied dialogue box a lot. &lt;br /&gt;
*#Shifted the basic structure to XML, using Glade.&lt;br /&gt;
*#Due to no implementation of [[#Type Information]], setting units may still create a problem.&lt;br /&gt;
*#Parameters are now viewable through a List view.&lt;br /&gt;
*Use cases still need more work.&lt;br /&gt;
*Worked out some details of implementing Undo/Redo system. Starting the work to implement them.&lt;br /&gt;
&lt;br /&gt;
====Week 3====&lt;br /&gt;
14th-June-10 to 20th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Set up the Undo/Redo system.&lt;br /&gt;
*Improve the Unit checking.&lt;br /&gt;
*Get ideas, implementation details on [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Status of Work&#039;&#039;&lt;br /&gt;
*A very basic Undo system in place.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Issues&#039;&#039;&lt;br /&gt;
*Identifying a way to record Undo transactions took a large part of the week, could not complete other objectives.&lt;br /&gt;
&lt;br /&gt;
====Week 4====&lt;br /&gt;
21st-June-10 to 27th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO LIST&#039;&#039;&lt;br /&gt;
*Thoroughly test Undo system.&lt;br /&gt;
*Improve the Unit checking.&lt;br /&gt;
*Get ideas, implementation details on [[#Support for user-customisable custom icon types]]. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Status of Work&#039;&#039;&lt;br /&gt;
*Did many improvements to the Undo system.&lt;br /&gt;
*Improved the Key Accel&#039;s&lt;br /&gt;
*Improved Connections code.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Issues&#039;&#039;&lt;br /&gt;
*Callback functions do not record in gaphas as an event, so Undo system breaks at undoing a disconnect of Line Connection.&lt;br /&gt;
*Went through much of ASCEND API, but still not being able to identify Types and thus Units of parameters of blocks. For a temporary solution tried a failed attempt to get a Simulation of the String Model and identify Types. &lt;br /&gt;
*Problem lies in not being able to get [[#Type Information]] in the model by name, which is the only information we have from annotations.&lt;br /&gt;
*Finding ways for [[#Support for user-customisable custom icon types]] implementation details, studied how Modellica handles Graphic properties of blocks.&lt;br /&gt;
&lt;br /&gt;
====Week 5====&lt;br /&gt;
28th-June-10 to 4th-July-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Set up freesteam, solve and study rankine.a4c&lt;br /&gt;
*Try to implement [[#Support for user-customisable custom icon types]] by Mid-Term, get implementation details and begin work.&lt;br /&gt;
*Check for solutions for Line connection Undo bug.&lt;br /&gt;
*Find a way for getting [[#Type Information]].&lt;br /&gt;
*Deal with [[#Bugs]].&lt;br /&gt;
&lt;br /&gt;
====Week 6====&lt;br /&gt;
5th-July-10 to 11th-July-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
====Week 7====&lt;br /&gt;
12th-July-10 to 18th-July-10&lt;br /&gt;
*Submit Mid Term Evaluations&lt;br /&gt;
&lt;br /&gt;
====Week 8====&lt;br /&gt;
19th-July-10 to 25th-July-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 9====&lt;br /&gt;
26th-July-10 to 1st-August-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 10====&lt;br /&gt;
2nd-August-10 to 8th-August-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 11====&lt;br /&gt;
9th-August-10 to 16th-August-10&lt;br /&gt;
*Finalise work&lt;br /&gt;
*Submit End Term Evaluations&lt;br /&gt;
*Tie loose ends&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=928</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=928"/>
		<updated>2010-07-12T20:54:33Z</updated>

		<summary type="html">&lt;p&gt;Grivan: /* Improvements on the Solving Process */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 development carried out by [[User:Grivan|Grivan]]. The goals and tasks are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. Efforts will be to make the modeller powerful enough for some real and serious modelling. Use Cases are being developed as to see what do we expect from our modeller to be able to do for us, to identify the most important aspects and implement them.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
TODO : Add more ideas, put a concrete solution overview to each Case.&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
*Global Model equations.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
*Block rotation.&lt;br /&gt;
*:It would be nice if blocks could be rotated, it makes the canvas look more tidy.&lt;br /&gt;
*Other Issues.&lt;br /&gt;
*:Just specifying a value and not Fixing it. Should it be possible? &lt;br /&gt;
*: How to make additions of equations to the MODEL more intuitive.&lt;br /&gt;
&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}}. We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece. In addition take care of the ALIASES keyword used in the text model. TODO&lt;br /&gt;
*Elimination of redundant equations in closed loop flows.&lt;br /&gt;
*:Multiple loops present in the system.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Still needs to be discussed. TODO&lt;br /&gt;
*Specifications of flow streams. &lt;br /&gt;
*:It should be possible to switch between stream components, water to CO2 to toluene for example.&lt;br /&gt;
*:This however should &#039;&#039;&#039;not&#039;&#039;&#039; involve redrawing the whole model again.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Streams can be defined in the canvas by selecting the particular connections and specifying the stream component, the connections to these components at the ports must use the values of stream component provided. TODO&lt;br /&gt;
*Providing complex flow streams.&lt;br /&gt;
*:A regenerative cycle requires to specify the fraction of steam extracted at the &#039;&#039;bled&#039;&#039; point, that is a TEE in our sense. Such a fraction must be supplied by the user while making such connections. Assuming an open feedwater scheme.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; This should be easy as a simple TEE component must have a fixable variable &#039;fraction&#039;.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*In this case connections may need to be manually specified in order to provide complex flows as required.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious.&lt;br /&gt;
**For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling of Servo Motor with backlash and PID control===&lt;br /&gt;
*TODO : Add description&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head.&lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
TODO : Keep adding details&lt;br /&gt;
&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
==Improvements on the Solving Process==&lt;br /&gt;
Since we have no Type informations the solving is done primarily by first generating a string representation of the complete MODEL and then exported to the solver. This can lead to problems while trying to solve complex models requiring a large time to solve, because each time a variable is changed the complete model has to solved again. In case of PyGTK GUI we have a more powerful interaction with the solver and thus can change parameters without discarding the already solved model. The basic problem here lies in the fact that we don&#039;t instantiate the model first and then solve it.&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified. This provides and excellent way to have the same model provide simulation for any number of streams. Two implementations have to be taken care of to specify streams;&lt;br /&gt;
*GUI implementation:&lt;br /&gt;
*:This would provide a suitable GUI to select the stream.&lt;br /&gt;
*Application level implementation&lt;br /&gt;
*:This would add actual stream modifications to the block code.&lt;br /&gt;
Currently in process of studying how streams are handled by the ASCEND language itself.&lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now.&lt;br /&gt;
&lt;br /&gt;
*To have highlighting of connectible ports while connecting two ports we need to:&lt;br /&gt;
*#Find all suitable (IN/OUT/BOTH) ports available for connection.&lt;br /&gt;
*#Create a set their Types.&lt;br /&gt;
*#Check connect-ability for each of those types.&lt;br /&gt;
*#Highlight only the connectible ones.&lt;br /&gt;
&lt;br /&gt;
*To give a set of units that can be selected from a drop down menu in block properties:&lt;br /&gt;
*#Scan for the Type of the parameter.&lt;br /&gt;
*#Get the dimensions of the type.&lt;br /&gt;
*#Scan for the units available. &lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Key Deliverables==&lt;br /&gt;
To set a stone for the GSoC project following have to be implemented&lt;br /&gt;
*Canvas Model for a Regenerative Rankine cycle&lt;br /&gt;
*Ammonia synthesis reactor&lt;br /&gt;
*Support for user customisable icon-types for blocks&lt;br /&gt;
*Undo Support&lt;br /&gt;
&lt;br /&gt;
==Weekly Reports==&lt;br /&gt;
&lt;br /&gt;
The weekly reports will be filed here. Week 0 starts from 24th of May up-to 30th of May and so on.&lt;br /&gt;
&lt;br /&gt;
====Week 0====&lt;br /&gt;
24th-May-10 to 30th-May-10&lt;br /&gt;
*Set up environment&lt;br /&gt;
*Attempt to try and get modeller running&lt;br /&gt;
*#Code updates for Gaphas HEAD using and Arijit&#039;s patch and some extra edits&lt;br /&gt;
*#:Except for connections feature canvas code successfully updates for Gaphas HEAD&lt;br /&gt;
*#Code updates for py-gtksourceview2, enabled syntax highlighting&lt;br /&gt;
*Other minor issues resolved&lt;br /&gt;
*Unavailable for project completely due to scheduled end semester exams from 24th-July-10 to 2nd-July-10&lt;br /&gt;
&lt;br /&gt;
====Week 1====&lt;br /&gt;
31st-May-10 to 6th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;This was a &#039;pull-up-socks&#039; week, main aim was to get back on after exams and prioritise work&lt;br /&gt;
*Attempt to fix the connections code&lt;br /&gt;
*#Connection disconnection done, using Gaphas&#039; new Aspects API. Still need a way to reconnect&lt;br /&gt;
*Start identifying crucial aspects for Canvas Modelling&lt;br /&gt;
*Started developing Use-Cases&lt;br /&gt;
*Had a meet with Prof Kannan. Got a huge motivation&lt;br /&gt;
*#Got in touch with Shrikanth and Ankit to identify aspects for use of Canvas modeller in a class room environment&lt;br /&gt;
*#Got in touch with Delhi FOSS community&lt;br /&gt;
*Started working on implementation details for Type-Checking, Closed-Loop flow sheets, User-customisable icons&lt;br /&gt;
*Got this wiki page up&lt;br /&gt;
&lt;br /&gt;
====Week 2====&lt;br /&gt;
7th-June-10 to 13th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Complete study of use cases&lt;br /&gt;
*Have connections code completely set, robust and future ready&lt;br /&gt;
*Have implementation details of at least one of the GUI features&lt;br /&gt;
&#039;&#039;Status of work&#039;&#039;&lt;br /&gt;
*The canvas connection code is completely done. User can connect/disconnect items multiple times.&lt;br /&gt;
*Improved the block propertied dialogue box a lot. &lt;br /&gt;
*#Shifted the basic structure to XML, using Glade.&lt;br /&gt;
*#Due to no implementation of [[#Type Information]], setting units may still create a problem.&lt;br /&gt;
*#Parameters are now viewable through a List view.&lt;br /&gt;
*Use cases still need more work.&lt;br /&gt;
*Worked out some details of implementing Undo/Redo system. Starting the work to implement them.&lt;br /&gt;
&lt;br /&gt;
====Week 3====&lt;br /&gt;
14th-June-10 to 20th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Set up the Undo/Redo system.&lt;br /&gt;
*Improve the Unit checking.&lt;br /&gt;
*Get ideas, implementation details on [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Status of Work&#039;&#039;&lt;br /&gt;
*A very basic Undo system in place.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Issues&#039;&#039;&lt;br /&gt;
*Identifying a way to record Undo transactions took a large part of the week, could not complete other objectives.&lt;br /&gt;
&lt;br /&gt;
====Week 4====&lt;br /&gt;
21st-June-10 to 27th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO LIST&#039;&#039;&lt;br /&gt;
*Thoroughly test Undo system.&lt;br /&gt;
*Improve the Unit checking.&lt;br /&gt;
*Get ideas, implementation details on [[#Support for user-customisable custom icon types]]. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Status of Work&#039;&#039;&lt;br /&gt;
*Did many improvements to the Undo system.&lt;br /&gt;
*Improved the Key Accel&#039;s&lt;br /&gt;
*Improved Connections code.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Issues&#039;&#039;&lt;br /&gt;
*Callback functions do not record in gaphas as an event, so Undo system breaks at undoing a disconnect of Line Connection.&lt;br /&gt;
*Went through much of ASCEND API, but still not being able to identify Types and thus Units of parameters of blocks. For a temporary solution tried a failed attempt to get a Simulation of the String Model and identify Types. &lt;br /&gt;
*Problem lies in not being able to get [[#Type Information]] in the model by name, which is the only information we have from annotations.&lt;br /&gt;
*Finding ways for [[#Support for user-customisable custom icon types]] implementation details, studied how Modellica handles Graphic properties of blocks.&lt;br /&gt;
&lt;br /&gt;
====Week 5====&lt;br /&gt;
28th-June-10 to 4th-July-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Set up freesteam, solve and study rankine.a4c&lt;br /&gt;
*Try to implement [[#Support for user-customisable custom icon types]] by Mid-Term, get implementation details and begin work.&lt;br /&gt;
*Check for solutions for Line connection Undo bug.&lt;br /&gt;
*Find a way for getting [[#Type Information]].&lt;br /&gt;
*Deal with [[#Bugs]].&lt;br /&gt;
&lt;br /&gt;
====Week 6====&lt;br /&gt;
5th-July-10 to 11th-July-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
====Week 7====&lt;br /&gt;
12th-July-10 to 18th-July-10&lt;br /&gt;
*Submit Mid Term Evaluations&lt;br /&gt;
&lt;br /&gt;
====Week 8====&lt;br /&gt;
19th-July-10 to 25th-July-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 9====&lt;br /&gt;
26th-July-10 to 1st-August-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 10====&lt;br /&gt;
2nd-August-10 to 8th-August-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 11====&lt;br /&gt;
9th-August-10 to 16th-August-10&lt;br /&gt;
*Finalise work&lt;br /&gt;
*Submit End Term Evaluations&lt;br /&gt;
*Tie loose ends&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=927</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=927"/>
		<updated>2010-07-12T20:49:13Z</updated>

		<summary type="html">&lt;p&gt;Grivan: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 development carried out by [[User:Grivan|Grivan]]. The goals and tasks are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. Efforts will be to make the modeller powerful enough for some real and serious modelling. Use Cases are being developed as to see what do we expect from our modeller to be able to do for us, to identify the most important aspects and implement them.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
TODO : Add more ideas, put a concrete solution overview to each Case.&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
*Global Model equations.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
*Block rotation.&lt;br /&gt;
*:It would be nice if blocks could be rotated, it makes the canvas look more tidy.&lt;br /&gt;
*Other Issues.&lt;br /&gt;
*:Just specifying a value and not Fixing it. Should it be possible? &lt;br /&gt;
*: How to make additions of equations to the MODEL more intuitive.&lt;br /&gt;
&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}}. We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece. In addition take care of the ALIASES keyword used in the text model. TODO&lt;br /&gt;
*Elimination of redundant equations in closed loop flows.&lt;br /&gt;
*:Multiple loops present in the system.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Still needs to be discussed. TODO&lt;br /&gt;
*Specifications of flow streams. &lt;br /&gt;
*:It should be possible to switch between stream components, water to CO2 to toluene for example.&lt;br /&gt;
*:This however should &#039;&#039;&#039;not&#039;&#039;&#039; involve redrawing the whole model again.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Streams can be defined in the canvas by selecting the particular connections and specifying the stream component, the connections to these components at the ports must use the values of stream component provided. TODO&lt;br /&gt;
*Providing complex flow streams.&lt;br /&gt;
*:A regenerative cycle requires to specify the fraction of steam extracted at the &#039;&#039;bled&#039;&#039; point, that is a TEE in our sense. Such a fraction must be supplied by the user while making such connections. Assuming an open feedwater scheme.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; This should be easy as a simple TEE component must have a fixable variable &#039;fraction&#039;.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*In this case connections may need to be manually specified in order to provide complex flows as required.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious.&lt;br /&gt;
**For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling of Servo Motor with backlash and PID control===&lt;br /&gt;
*TODO : Add description&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head.&lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
TODO : Keep adding details&lt;br /&gt;
&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
==Improvements on the Solving Process==&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified. This provides and excellent way to have the same model provide simulation for any number of streams. Two implementations have to be taken care of to specify streams;&lt;br /&gt;
*GUI implementation:&lt;br /&gt;
*:This would provide a suitable GUI to select the stream.&lt;br /&gt;
*Application level implementation&lt;br /&gt;
*:This would add actual stream modifications to the block code.&lt;br /&gt;
Currently in process of studying how streams are handled by the ASCEND language itself.&lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now.&lt;br /&gt;
&lt;br /&gt;
*To have highlighting of connectible ports while connecting two ports we need to:&lt;br /&gt;
*#Find all suitable (IN/OUT/BOTH) ports available for connection.&lt;br /&gt;
*#Create a set their Types.&lt;br /&gt;
*#Check connect-ability for each of those types.&lt;br /&gt;
*#Highlight only the connectible ones.&lt;br /&gt;
&lt;br /&gt;
*To give a set of units that can be selected from a drop down menu in block properties:&lt;br /&gt;
*#Scan for the Type of the parameter.&lt;br /&gt;
*#Get the dimensions of the type.&lt;br /&gt;
*#Scan for the units available. &lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Key Deliverables==&lt;br /&gt;
To set a stone for the GSoC project following have to be implemented&lt;br /&gt;
*Canvas Model for a Regenerative Rankine cycle&lt;br /&gt;
*Ammonia synthesis reactor&lt;br /&gt;
*Support for user customisable icon-types for blocks&lt;br /&gt;
*Undo Support&lt;br /&gt;
&lt;br /&gt;
==Weekly Reports==&lt;br /&gt;
&lt;br /&gt;
The weekly reports will be filed here. Week 0 starts from 24th of May up-to 30th of May and so on.&lt;br /&gt;
&lt;br /&gt;
====Week 0====&lt;br /&gt;
24th-May-10 to 30th-May-10&lt;br /&gt;
*Set up environment&lt;br /&gt;
*Attempt to try and get modeller running&lt;br /&gt;
*#Code updates for Gaphas HEAD using and Arijit&#039;s patch and some extra edits&lt;br /&gt;
*#:Except for connections feature canvas code successfully updates for Gaphas HEAD&lt;br /&gt;
*#Code updates for py-gtksourceview2, enabled syntax highlighting&lt;br /&gt;
*Other minor issues resolved&lt;br /&gt;
*Unavailable for project completely due to scheduled end semester exams from 24th-July-10 to 2nd-July-10&lt;br /&gt;
&lt;br /&gt;
====Week 1====&lt;br /&gt;
31st-May-10 to 6th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;This was a &#039;pull-up-socks&#039; week, main aim was to get back on after exams and prioritise work&lt;br /&gt;
*Attempt to fix the connections code&lt;br /&gt;
*#Connection disconnection done, using Gaphas&#039; new Aspects API. Still need a way to reconnect&lt;br /&gt;
*Start identifying crucial aspects for Canvas Modelling&lt;br /&gt;
*Started developing Use-Cases&lt;br /&gt;
*Had a meet with Prof Kannan. Got a huge motivation&lt;br /&gt;
*#Got in touch with Shrikanth and Ankit to identify aspects for use of Canvas modeller in a class room environment&lt;br /&gt;
*#Got in touch with Delhi FOSS community&lt;br /&gt;
*Started working on implementation details for Type-Checking, Closed-Loop flow sheets, User-customisable icons&lt;br /&gt;
*Got this wiki page up&lt;br /&gt;
&lt;br /&gt;
====Week 2====&lt;br /&gt;
7th-June-10 to 13th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Complete study of use cases&lt;br /&gt;
*Have connections code completely set, robust and future ready&lt;br /&gt;
*Have implementation details of at least one of the GUI features&lt;br /&gt;
&#039;&#039;Status of work&#039;&#039;&lt;br /&gt;
*The canvas connection code is completely done. User can connect/disconnect items multiple times.&lt;br /&gt;
*Improved the block propertied dialogue box a lot. &lt;br /&gt;
*#Shifted the basic structure to XML, using Glade.&lt;br /&gt;
*#Due to no implementation of [[#Type Information]], setting units may still create a problem.&lt;br /&gt;
*#Parameters are now viewable through a List view.&lt;br /&gt;
*Use cases still need more work.&lt;br /&gt;
*Worked out some details of implementing Undo/Redo system. Starting the work to implement them.&lt;br /&gt;
&lt;br /&gt;
====Week 3====&lt;br /&gt;
14th-June-10 to 20th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Set up the Undo/Redo system.&lt;br /&gt;
*Improve the Unit checking.&lt;br /&gt;
*Get ideas, implementation details on [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Status of Work&#039;&#039;&lt;br /&gt;
*A very basic Undo system in place.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Issues&#039;&#039;&lt;br /&gt;
*Identifying a way to record Undo transactions took a large part of the week, could not complete other objectives.&lt;br /&gt;
&lt;br /&gt;
====Week 4====&lt;br /&gt;
21st-June-10 to 27th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO LIST&#039;&#039;&lt;br /&gt;
*Thoroughly test Undo system.&lt;br /&gt;
*Improve the Unit checking.&lt;br /&gt;
*Get ideas, implementation details on [[#Support for user-customisable custom icon types]]. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Status of Work&#039;&#039;&lt;br /&gt;
*Did many improvements to the Undo system.&lt;br /&gt;
*Improved the Key Accel&#039;s&lt;br /&gt;
*Improved Connections code.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Issues&#039;&#039;&lt;br /&gt;
*Callback functions do not record in gaphas as an event, so Undo system breaks at undoing a disconnect of Line Connection.&lt;br /&gt;
*Went through much of ASCEND API, but still not being able to identify Types and thus Units of parameters of blocks. For a temporary solution tried a failed attempt to get a Simulation of the String Model and identify Types. &lt;br /&gt;
*Problem lies in not being able to get [[#Type Information]] in the model by name, which is the only information we have from annotations.&lt;br /&gt;
*Finding ways for [[#Support for user-customisable custom icon types]] implementation details, studied how Modellica handles Graphic properties of blocks.&lt;br /&gt;
&lt;br /&gt;
====Week 5====&lt;br /&gt;
28th-June-10 to 4th-July-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Set up freesteam, solve and study rankine.a4c&lt;br /&gt;
*Try to implement [[#Support for user-customisable custom icon types]] by Mid-Term, get implementation details and begin work.&lt;br /&gt;
*Check for solutions for Line connection Undo bug.&lt;br /&gt;
*Find a way for getting [[#Type Information]].&lt;br /&gt;
*Deal with [[#Bugs]].&lt;br /&gt;
&lt;br /&gt;
====Week 6====&lt;br /&gt;
5th-July-10 to 11th-July-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
====Week 7====&lt;br /&gt;
12th-July-10 to 18th-July-10&lt;br /&gt;
*Submit Mid Term Evaluations&lt;br /&gt;
&lt;br /&gt;
====Week 8====&lt;br /&gt;
19th-July-10 to 25th-July-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 9====&lt;br /&gt;
26th-July-10 to 1st-August-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 10====&lt;br /&gt;
2nd-August-10 to 8th-August-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 11====&lt;br /&gt;
9th-August-10 to 16th-August-10&lt;br /&gt;
*Finalise work&lt;br /&gt;
*Submit End Term Evaluations&lt;br /&gt;
*Tie loose ends&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=926</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=926"/>
		<updated>2010-07-12T20:47:35Z</updated>

		<summary type="html">&lt;p&gt;Grivan: /* Type Information */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 development carried out by [[User:Grivan|Grivan]]. The goals and tasks are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. Efforts will be to make the modeller powerful enough for some real and serious modelling. Use Cases are being developed as to see what do we expect from our modeller to be able to do for us, to identify the most important aspects and implement them.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
TODO : Add more ideas, put a concrete solution overview to each Case.&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
*Global Model equations.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
*Block rotation.&lt;br /&gt;
*:It would be nice if blocks could be rotated, it makes the canvas look more tidy.&lt;br /&gt;
*Other Issues.&lt;br /&gt;
*:Just specifying a value and not Fixing it. Should it be possible? &lt;br /&gt;
*: How to make additions of equations to the MODEL more intuitive.&lt;br /&gt;
&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}}. We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece. In addition take care of the ALIASES keyword used in the text model. TODO&lt;br /&gt;
*Elimination of redundant equations in closed loop flows.&lt;br /&gt;
*:Multiple loops present in the system.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Still needs to be discussed. TODO&lt;br /&gt;
*Specifications of flow streams. &lt;br /&gt;
*:It should be possible to switch between stream components, water to CO2 to toluene for example.&lt;br /&gt;
*:This however should &#039;&#039;&#039;not&#039;&#039;&#039; involve redrawing the whole model again.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Streams can be defined in the canvas by selecting the particular connections and specifying the stream component, the connections to these components at the ports must use the values of stream component provided. TODO&lt;br /&gt;
*Providing complex flow streams.&lt;br /&gt;
*:A regenerative cycle requires to specify the fraction of steam extracted at the &#039;&#039;bled&#039;&#039; point, that is a TEE in our sense. Such a fraction must be supplied by the user while making such connections. Assuming an open feedwater scheme.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; This should be easy as a simple TEE component must have a fixable variable &#039;fraction&#039;.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*In this case connections may need to be manually specified in order to provide complex flows as required.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious.&lt;br /&gt;
**For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling of Servo Motor with backlash and PID control===&lt;br /&gt;
*TODO : Add description&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head.&lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
TODO : Keep adding details&lt;br /&gt;
&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified. This provides and excellent way to have the same model provide simulation for any number of streams. Two implementations have to be taken care of to specify streams;&lt;br /&gt;
*GUI implementation:&lt;br /&gt;
*:This would provide a suitable GUI to select the stream.&lt;br /&gt;
*Application level implementation&lt;br /&gt;
*:This would add actual stream modifications to the block code.&lt;br /&gt;
Currently in process of studying how streams are handled by the ASCEND language itself.&lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now.&lt;br /&gt;
&lt;br /&gt;
*To have highlighting of connectible ports while connecting two ports we need to:&lt;br /&gt;
*#Find all suitable (IN/OUT/BOTH) ports available for connection.&lt;br /&gt;
*#Create a set their Types.&lt;br /&gt;
*#Check connect-ability for each of those types.&lt;br /&gt;
*#Highlight only the connectible ones.&lt;br /&gt;
&lt;br /&gt;
*To give a set of units that can be selected from a drop down menu in block properties:&lt;br /&gt;
*#Scan for the Type of the parameter.&lt;br /&gt;
*#Get the dimensions of the type.&lt;br /&gt;
*#Scan for the units available. &lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Key Deliverables==&lt;br /&gt;
To set a stone for the GSoC project following have to be implemented&lt;br /&gt;
*Canvas Model for a Regenerative Rankine cycle&lt;br /&gt;
*Ammonia synthesis reactor&lt;br /&gt;
*Support for user customisable icon-types for blocks&lt;br /&gt;
*Undo Support&lt;br /&gt;
&lt;br /&gt;
==Weekly Reports==&lt;br /&gt;
&lt;br /&gt;
The weekly reports will be filed here. Week 0 starts from 24th of May up-to 30th of May and so on.&lt;br /&gt;
&lt;br /&gt;
====Week 0====&lt;br /&gt;
24th-May-10 to 30th-May-10&lt;br /&gt;
*Set up environment&lt;br /&gt;
*Attempt to try and get modeller running&lt;br /&gt;
*#Code updates for Gaphas HEAD using and Arijit&#039;s patch and some extra edits&lt;br /&gt;
*#:Except for connections feature canvas code successfully updates for Gaphas HEAD&lt;br /&gt;
*#Code updates for py-gtksourceview2, enabled syntax highlighting&lt;br /&gt;
*Other minor issues resolved&lt;br /&gt;
*Unavailable for project completely due to scheduled end semester exams from 24th-July-10 to 2nd-July-10&lt;br /&gt;
&lt;br /&gt;
====Week 1====&lt;br /&gt;
31st-May-10 to 6th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;This was a &#039;pull-up-socks&#039; week, main aim was to get back on after exams and prioritise work&lt;br /&gt;
*Attempt to fix the connections code&lt;br /&gt;
*#Connection disconnection done, using Gaphas&#039; new Aspects API. Still need a way to reconnect&lt;br /&gt;
*Start identifying crucial aspects for Canvas Modelling&lt;br /&gt;
*Started developing Use-Cases&lt;br /&gt;
*Had a meet with Prof Kannan. Got a huge motivation&lt;br /&gt;
*#Got in touch with Shrikanth and Ankit to identify aspects for use of Canvas modeller in a class room environment&lt;br /&gt;
*#Got in touch with Delhi FOSS community&lt;br /&gt;
*Started working on implementation details for Type-Checking, Closed-Loop flow sheets, User-customisable icons&lt;br /&gt;
*Got this wiki page up&lt;br /&gt;
&lt;br /&gt;
====Week 2====&lt;br /&gt;
7th-June-10 to 13th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Complete study of use cases&lt;br /&gt;
*Have connections code completely set, robust and future ready&lt;br /&gt;
*Have implementation details of at least one of the GUI features&lt;br /&gt;
&#039;&#039;Status of work&#039;&#039;&lt;br /&gt;
*The canvas connection code is completely done. User can connect/disconnect items multiple times.&lt;br /&gt;
*Improved the block propertied dialogue box a lot. &lt;br /&gt;
*#Shifted the basic structure to XML, using Glade.&lt;br /&gt;
*#Due to no implementation of [[#Type Information]], setting units may still create a problem.&lt;br /&gt;
*#Parameters are now viewable through a List view.&lt;br /&gt;
*Use cases still need more work.&lt;br /&gt;
*Worked out some details of implementing Undo/Redo system. Starting the work to implement them.&lt;br /&gt;
&lt;br /&gt;
====Week 3====&lt;br /&gt;
14th-June-10 to 20th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Set up the Undo/Redo system.&lt;br /&gt;
*Improve the Unit checking.&lt;br /&gt;
*Get ideas, implementation details on [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Status of Work&#039;&#039;&lt;br /&gt;
*A very basic Undo system in place.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Issues&#039;&#039;&lt;br /&gt;
*Identifying a way to record Undo transactions took a large part of the week, could not complete other objectives.&lt;br /&gt;
&lt;br /&gt;
====Week 4====&lt;br /&gt;
21st-June-10 to 27th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO LIST&#039;&#039;&lt;br /&gt;
*Thoroughly test Undo system.&lt;br /&gt;
*Improve the Unit checking.&lt;br /&gt;
*Get ideas, implementation details on [[#Support for user-customisable custom icon types]]. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Status of Work&#039;&#039;&lt;br /&gt;
*Did many improvements to the Undo system.&lt;br /&gt;
*Improved the Key Accel&#039;s&lt;br /&gt;
*Improved Connections code.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Issues&#039;&#039;&lt;br /&gt;
*Callback functions do not record in gaphas as an event, so Undo system breaks at undoing a disconnect of Line Connection.&lt;br /&gt;
*Went through much of ASCEND API, but still not being able to identify Types and thus Units of parameters of blocks. For a temporary solution tried a failed attempt to get a Simulation of the String Model and identify Types. &lt;br /&gt;
*Problem lies in not being able to get [[#Type Information]] in the model by name, which is the only information we have from annotations.&lt;br /&gt;
*Finding ways for [[#Support for user-customisable custom icon types]] implementation details, studied how Modellica handles Graphic properties of blocks.&lt;br /&gt;
&lt;br /&gt;
====Week 5====&lt;br /&gt;
28th-June-10 to 4th-July-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Set up freesteam, solve and study rankine.a4c&lt;br /&gt;
*Try to implement [[#Support for user-customisable custom icon types]] by Mid-Term, get implementation details and begin work.&lt;br /&gt;
*Check for solutions for Line connection Undo bug.&lt;br /&gt;
*Find a way for getting [[#Type Information]].&lt;br /&gt;
*Deal with [[#Bugs]].&lt;br /&gt;
&lt;br /&gt;
====Week 6====&lt;br /&gt;
5th-July-10 to 11th-July-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
====Week 7====&lt;br /&gt;
12th-July-10 to 18th-July-10&lt;br /&gt;
*Submit Mid Term Evaluations&lt;br /&gt;
&lt;br /&gt;
====Week 8====&lt;br /&gt;
19th-July-10 to 25th-July-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 9====&lt;br /&gt;
26th-July-10 to 1st-August-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 10====&lt;br /&gt;
2nd-August-10 to 8th-August-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 11====&lt;br /&gt;
9th-August-10 to 16th-August-10&lt;br /&gt;
*Finalise work&lt;br /&gt;
*Submit End Term Evaluations&lt;br /&gt;
*Tie loose ends&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=925</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=925"/>
		<updated>2010-07-12T20:40:15Z</updated>

		<summary type="html">&lt;p&gt;Grivan: /* Simple Rankine Cycle */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 development carried out by [[User:Grivan|Grivan]]. The goals and tasks are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. Efforts will be to make the modeller powerful enough for some real and serious modelling. Use Cases are being developed as to see what do we expect from our modeller to be able to do for us, to identify the most important aspects and implement them.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
TODO : Add more ideas, put a concrete solution overview to each Case.&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
*Global Model equations.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
*Block rotation.&lt;br /&gt;
*:It would be nice if blocks could be rotated, it makes the canvas look more tidy.&lt;br /&gt;
*Other Issues.&lt;br /&gt;
*:Just specifying a value and not Fixing it. Should it be possible? &lt;br /&gt;
*: How to make additions of equations to the MODEL more intuitive.&lt;br /&gt;
&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}}. We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece. In addition take care of the ALIASES keyword used in the text model. TODO&lt;br /&gt;
*Elimination of redundant equations in closed loop flows.&lt;br /&gt;
*:Multiple loops present in the system.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Still needs to be discussed. TODO&lt;br /&gt;
*Specifications of flow streams. &lt;br /&gt;
*:It should be possible to switch between stream components, water to CO2 to toluene for example.&lt;br /&gt;
*:This however should &#039;&#039;&#039;not&#039;&#039;&#039; involve redrawing the whole model again.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Streams can be defined in the canvas by selecting the particular connections and specifying the stream component, the connections to these components at the ports must use the values of stream component provided. TODO&lt;br /&gt;
*Providing complex flow streams.&lt;br /&gt;
*:A regenerative cycle requires to specify the fraction of steam extracted at the &#039;&#039;bled&#039;&#039; point, that is a TEE in our sense. Such a fraction must be supplied by the user while making such connections. Assuming an open feedwater scheme.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; This should be easy as a simple TEE component must have a fixable variable &#039;fraction&#039;.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*In this case connections may need to be manually specified in order to provide complex flows as required.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious.&lt;br /&gt;
**For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling of Servo Motor with backlash and PID control===&lt;br /&gt;
*TODO : Add description&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head.&lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
TODO : Keep adding details&lt;br /&gt;
&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified. This provides and excellent way to have the same model provide simulation for any number of streams. Two implementations have to be taken care of to specify streams;&lt;br /&gt;
*GUI implementation:&lt;br /&gt;
*:This would provide a suitable GUI to select the stream.&lt;br /&gt;
*Application level implementation&lt;br /&gt;
*:This would add actual stream modifications to the block code.&lt;br /&gt;
Currently in process of studying how streams are handled by the ASCEND language itself.&lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now. Looking for ways.&lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Key Deliverables==&lt;br /&gt;
To set a stone for the GSoC project following have to be implemented&lt;br /&gt;
*Canvas Model for a Regenerative Rankine cycle&lt;br /&gt;
*Ammonia synthesis reactor&lt;br /&gt;
*Support for user customisable icon-types for blocks&lt;br /&gt;
*Undo Support&lt;br /&gt;
&lt;br /&gt;
==Weekly Reports==&lt;br /&gt;
&lt;br /&gt;
The weekly reports will be filed here. Week 0 starts from 24th of May up-to 30th of May and so on.&lt;br /&gt;
&lt;br /&gt;
====Week 0====&lt;br /&gt;
24th-May-10 to 30th-May-10&lt;br /&gt;
*Set up environment&lt;br /&gt;
*Attempt to try and get modeller running&lt;br /&gt;
*#Code updates for Gaphas HEAD using and Arijit&#039;s patch and some extra edits&lt;br /&gt;
*#:Except for connections feature canvas code successfully updates for Gaphas HEAD&lt;br /&gt;
*#Code updates for py-gtksourceview2, enabled syntax highlighting&lt;br /&gt;
*Other minor issues resolved&lt;br /&gt;
*Unavailable for project completely due to scheduled end semester exams from 24th-July-10 to 2nd-July-10&lt;br /&gt;
&lt;br /&gt;
====Week 1====&lt;br /&gt;
31st-May-10 to 6th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;This was a &#039;pull-up-socks&#039; week, main aim was to get back on after exams and prioritise work&lt;br /&gt;
*Attempt to fix the connections code&lt;br /&gt;
*#Connection disconnection done, using Gaphas&#039; new Aspects API. Still need a way to reconnect&lt;br /&gt;
*Start identifying crucial aspects for Canvas Modelling&lt;br /&gt;
*Started developing Use-Cases&lt;br /&gt;
*Had a meet with Prof Kannan. Got a huge motivation&lt;br /&gt;
*#Got in touch with Shrikanth and Ankit to identify aspects for use of Canvas modeller in a class room environment&lt;br /&gt;
*#Got in touch with Delhi FOSS community&lt;br /&gt;
*Started working on implementation details for Type-Checking, Closed-Loop flow sheets, User-customisable icons&lt;br /&gt;
*Got this wiki page up&lt;br /&gt;
&lt;br /&gt;
====Week 2====&lt;br /&gt;
7th-June-10 to 13th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Complete study of use cases&lt;br /&gt;
*Have connections code completely set, robust and future ready&lt;br /&gt;
*Have implementation details of at least one of the GUI features&lt;br /&gt;
&#039;&#039;Status of work&#039;&#039;&lt;br /&gt;
*The canvas connection code is completely done. User can connect/disconnect items multiple times.&lt;br /&gt;
*Improved the block propertied dialogue box a lot. &lt;br /&gt;
*#Shifted the basic structure to XML, using Glade.&lt;br /&gt;
*#Due to no implementation of [[#Type Information]], setting units may still create a problem.&lt;br /&gt;
*#Parameters are now viewable through a List view.&lt;br /&gt;
*Use cases still need more work.&lt;br /&gt;
*Worked out some details of implementing Undo/Redo system. Starting the work to implement them.&lt;br /&gt;
&lt;br /&gt;
====Week 3====&lt;br /&gt;
14th-June-10 to 20th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Set up the Undo/Redo system.&lt;br /&gt;
*Improve the Unit checking.&lt;br /&gt;
*Get ideas, implementation details on [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Status of Work&#039;&#039;&lt;br /&gt;
*A very basic Undo system in place.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Issues&#039;&#039;&lt;br /&gt;
*Identifying a way to record Undo transactions took a large part of the week, could not complete other objectives.&lt;br /&gt;
&lt;br /&gt;
====Week 4====&lt;br /&gt;
21st-June-10 to 27th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO LIST&#039;&#039;&lt;br /&gt;
*Thoroughly test Undo system.&lt;br /&gt;
*Improve the Unit checking.&lt;br /&gt;
*Get ideas, implementation details on [[#Support for user-customisable custom icon types]]. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Status of Work&#039;&#039;&lt;br /&gt;
*Did many improvements to the Undo system.&lt;br /&gt;
*Improved the Key Accel&#039;s&lt;br /&gt;
*Improved Connections code.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Issues&#039;&#039;&lt;br /&gt;
*Callback functions do not record in gaphas as an event, so Undo system breaks at undoing a disconnect of Line Connection.&lt;br /&gt;
*Went through much of ASCEND API, but still not being able to identify Types and thus Units of parameters of blocks. For a temporary solution tried a failed attempt to get a Simulation of the String Model and identify Types. &lt;br /&gt;
*Problem lies in not being able to get [[#Type Information]] in the model by name, which is the only information we have from annotations.&lt;br /&gt;
*Finding ways for [[#Support for user-customisable custom icon types]] implementation details, studied how Modellica handles Graphic properties of blocks.&lt;br /&gt;
&lt;br /&gt;
====Week 5====&lt;br /&gt;
28th-June-10 to 4th-July-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Set up freesteam, solve and study rankine.a4c&lt;br /&gt;
*Try to implement [[#Support for user-customisable custom icon types]] by Mid-Term, get implementation details and begin work.&lt;br /&gt;
*Check for solutions for Line connection Undo bug.&lt;br /&gt;
*Find a way for getting [[#Type Information]].&lt;br /&gt;
*Deal with [[#Bugs]].&lt;br /&gt;
&lt;br /&gt;
====Week 6====&lt;br /&gt;
5th-July-10 to 11th-July-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
====Week 7====&lt;br /&gt;
12th-July-10 to 18th-July-10&lt;br /&gt;
*Submit Mid Term Evaluations&lt;br /&gt;
&lt;br /&gt;
====Week 8====&lt;br /&gt;
19th-July-10 to 25th-July-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 9====&lt;br /&gt;
26th-July-10 to 1st-August-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 10====&lt;br /&gt;
2nd-August-10 to 8th-August-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 11====&lt;br /&gt;
9th-August-10 to 16th-August-10&lt;br /&gt;
*Finalise work&lt;br /&gt;
*Submit End Term Evaluations&lt;br /&gt;
*Tie loose ends&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
	<entry>
		<id>https://ascend4.org/index.php?title=Canvas_Development&amp;diff=924</id>
		<title>Canvas Development</title>
		<link rel="alternate" type="text/html" href="https://ascend4.org/index.php?title=Canvas_Development&amp;diff=924"/>
		<updated>2010-07-12T20:38:46Z</updated>

		<summary type="html">&lt;p&gt;Grivan: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;{{task}}&lt;br /&gt;
This page aims to document all the GSoC 2010 development carried out by [[User:Grivan|Grivan]]. The goals and tasks are additionally listed over [[User:Grivan#Tasks|here]] for a quick look. Efforts will be to make the modeller powerful enough for some real and serious modelling. Use Cases are being developed as to see what do we expect from our modeller to be able to do for us, to identify the most important aspects and implement them.&lt;br /&gt;
&lt;br /&gt;
==Use Cases==&lt;br /&gt;
We want to be able to solve following descriptions from our Canvas Based Modeller. These would help us identify as to what things require our immediate attention. This will help identify the missing elements from our design, and how best these should be implemented.&lt;br /&gt;
&lt;br /&gt;
TODO : Add more ideas, put a concrete solution overview to each Case.&lt;br /&gt;
&lt;br /&gt;
===Simple Rankine Cycle===&lt;br /&gt;
A simple Rankine cycle has been modelled as a use case to see what all is missing.&lt;br /&gt;
[[Image:Screenshot-ASCEND_Canvas_Modeller.png|thumb|250px|right|Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.]]&lt;br /&gt;
[[Image:Screenshot-Block_Description.png|thumb|200px|right|Instance browser showing partial results.]]&lt;br /&gt;
*Global Model equations.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: A &#039;Canvas Properties&#039; pop-up allows for additions of extra declarations to the MODEL. &lt;br /&gt;
*Set up of extra components.&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.&lt;br /&gt;
*Block rotation.&lt;br /&gt;
*:It would be nice if blocks could be rotated, it makes the canvas look more tidy.&lt;br /&gt;
*Other Issues.&lt;br /&gt;
*:Just specifying a value and not Fixing it. Should it be possible? &lt;br /&gt;
*: How to make additions of equations to the MODEL more intuitive.&lt;br /&gt;
&lt;br /&gt;
===Regenerative Rankine Cycle===&lt;br /&gt;
[http://en.wikipedia.org/wiki/Rankine_cycle#Regenerative_Rankine_cycle  Rankine cycle] is a thermodynamic process that converts heat energy into work. [[John Pye]] has already written an ASCEND language based model for this process here {{src|models/johnpye/rankine.a4c}}. We would want to develop a steady state model of regenerative Rankine cycle. &lt;br /&gt;
This particular model would require from us to:&lt;br /&gt;
*Set up of extra components&lt;br /&gt;
:&#039;&#039;Implementation&#039;&#039;: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece. In addition take care of the ALIASES keyword used in the text model. TODO&lt;br /&gt;
*Elimination of redundant equations in closed loop flows.&lt;br /&gt;
*:Multiple loops present in the system.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Still needs to be discussed. TODO&lt;br /&gt;
*Specifications of flow streams. &lt;br /&gt;
*:It should be possible to switch between stream components, water to CO2 to toluene for example.&lt;br /&gt;
*:This however should &#039;&#039;&#039;not&#039;&#039;&#039; involve redrawing the whole model again.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; Streams can be defined in the canvas by selecting the particular connections and specifying the stream component, the connections to these components at the ports must use the values of stream component provided. TODO&lt;br /&gt;
*Providing complex flow streams.&lt;br /&gt;
*:A regenerative cycle requires to specify the fraction of steam extracted at the &#039;&#039;bled&#039;&#039; point, that is a TEE in our sense. Such a fraction must be supplied by the user while making such connections. Assuming an open feedwater scheme.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; This should be easy as a simple TEE component must have a fixable variable &#039;fraction&#039;.&lt;br /&gt;
*Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD.&lt;br /&gt;
:&#039;&#039;Implementation:&#039;&#039; See [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
===Ammonia Synthesis Reactor===&lt;br /&gt;
Ammonia is basically manufactured by chemical combination of nitrogen and hydrogen gases at high temperature and pressure in the presence of a catalyst. The reactor could be desirable complexity which has to be decided. In any case Ammonia synthesis requires complex flow streams.&lt;br /&gt;
*The simulation type needs to determined. What kind of reactor will be used for example [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.&lt;br /&gt;
*In this case connections may need to be manually specified in order to provide complex flows as required.&lt;br /&gt;
&lt;br /&gt;
===Non-Chemical Models===&lt;br /&gt;
ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these: &lt;br /&gt;
*[[Damped response]] &lt;br /&gt;
*[[Calculation of sun position]]&lt;br /&gt;
*[[Worked_examples#Four bar linkage | Four bar linkage]]&lt;br /&gt;
Specification of flow streams should not make the modeller lose it generality. Other chemical process modellers make the modeller specific for use with chemical engineering models. However we would also want to have our modeller models of mechanical and electrical architecture. Basically maintain the ASCEND&#039;s general approach.&lt;br /&gt;
*Flow streams have to be mentioned such that it does not affect the type of system being modelled does not require specification of flow streams or it is obvious.&lt;br /&gt;
**For example, current and torque/energy/tension are obviously the streams in an electrical model and a particular mechanical model.&lt;br /&gt;
&lt;br /&gt;
===Dynamic Modelling of Servo Motor with backlash and PID control===&lt;br /&gt;
*TODO : Add description&lt;br /&gt;
&lt;br /&gt;
==Update for [[Gaphas]] HEAD==&lt;br /&gt;
The following section lists all the updating that needs to be done or has been done to work with latest gaphas head.&lt;br /&gt;
===Aspects===&lt;br /&gt;
One of the features that enhances the usability of the canvas is the dragging of ports to ports support to specify a stream. In reality these provides ARE_THE_SAME arguments when the ASCEND code is created.&lt;br /&gt;
*The Aspects of gaphas API define the &#039;how&#039; and Tools the &#039;what&#039;.&lt;br /&gt;
*Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.&lt;br /&gt;
*This should be carefully designed to have no problems in the future as it is already an important component.&lt;br /&gt;
&lt;br /&gt;
===Line Connection===&lt;br /&gt;
Line Connection now uses Aspects, it is quite stable.&lt;br /&gt;
&lt;br /&gt;
==GUI Usability Improvements==&lt;br /&gt;
TODO : Keep adding details&lt;br /&gt;
&lt;br /&gt;
===Undo/Redo Support ===&lt;br /&gt;
An Undo/Redo support would enhance the Usability. The gaphas library provides a very low level access to changes in its classes in form of multiple actions those of which could be executed to perform an Undo action. What is being done is to segregate the Actions &#039;&#039;observed&#039;&#039; into user level &#039;&#039;Transactions&#039;&#039; which could be applied to perform one Undo or a Redo. &lt;br /&gt;
*A basic but working mechanism is present.&lt;br /&gt;
*The mechanism breaks at undoing Line Connections.&lt;br /&gt;
*Add support for Undoing after a model has been solved. Give an error message like &#039;Undoing will discard your currently solved model.&#039;&lt;br /&gt;
*Enable Redo.&lt;br /&gt;
&lt;br /&gt;
===Bugs===&lt;br /&gt;
Maybe this [http://ascendbugs.cheme.cmu.edu/search.php?project_id=4&amp;amp;category=canvas-gui&amp;amp;sticky_issues=on&amp;amp;product_build=&amp;amp;sortby=last_updated&amp;amp;dir=DESC&amp;amp;hide_status_id=80 bug list] could be useful for that.&lt;br /&gt;
&lt;br /&gt;
===Support for user-customisable custom icon types===&lt;br /&gt;
We want to be able to generate icons for models by embedding some kind of user definable code inside the model and/or add a graphical file itself. We want to make the resizing of the blocks such that it just works. Say for example if a motor is to be circle, it has to remain a circle. Additionally it would require us to read the model code and identify the constraint codes and pass them to Gaphas.&lt;br /&gt;
TODO : Add exact Implementation details&lt;br /&gt;
&lt;br /&gt;
==Specification of flow streams==&lt;br /&gt;
To provide reusable modelling architecture for modelling systems with non-trivial flow streams, the flow streams should be manually specified. This provides and excellent way to have the same model provide simulation for any number of streams. Two implementations have to be taken care of to specify streams;&lt;br /&gt;
*GUI implementation:&lt;br /&gt;
*:This would provide a suitable GUI to select the stream.&lt;br /&gt;
*Application level implementation&lt;br /&gt;
*:This would add actual stream modifications to the block code.&lt;br /&gt;
Currently in process of studying how streams are handled by the ASCEND language itself.&lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Type Information==&lt;br /&gt;
While connecting two blocks together the type of input and output port of the connector must be matched, also if we can extract Type information on variables in our model both Unit checking and port checking should be fairly easy. Type checking isn&#039;t very easy right now. Looking for ways.&lt;br /&gt;
&lt;br /&gt;
TODO : Add implementation details&lt;br /&gt;
&lt;br /&gt;
==Key Deliverables==&lt;br /&gt;
To set a stone for the GSoC project following have to be implemented&lt;br /&gt;
*Canvas Model for a Regenerative Rankine cycle&lt;br /&gt;
*Ammonia synthesis reactor&lt;br /&gt;
*Support for user customisable icon-types for blocks&lt;br /&gt;
*Undo Support&lt;br /&gt;
&lt;br /&gt;
==Weekly Reports==&lt;br /&gt;
&lt;br /&gt;
The weekly reports will be filed here. Week 0 starts from 24th of May up-to 30th of May and so on.&lt;br /&gt;
&lt;br /&gt;
====Week 0====&lt;br /&gt;
24th-May-10 to 30th-May-10&lt;br /&gt;
*Set up environment&lt;br /&gt;
*Attempt to try and get modeller running&lt;br /&gt;
*#Code updates for Gaphas HEAD using and Arijit&#039;s patch and some extra edits&lt;br /&gt;
*#:Except for connections feature canvas code successfully updates for Gaphas HEAD&lt;br /&gt;
*#Code updates for py-gtksourceview2, enabled syntax highlighting&lt;br /&gt;
*Other minor issues resolved&lt;br /&gt;
*Unavailable for project completely due to scheduled end semester exams from 24th-July-10 to 2nd-July-10&lt;br /&gt;
&lt;br /&gt;
====Week 1====&lt;br /&gt;
31st-May-10 to 6th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;This was a &#039;pull-up-socks&#039; week, main aim was to get back on after exams and prioritise work&lt;br /&gt;
*Attempt to fix the connections code&lt;br /&gt;
*#Connection disconnection done, using Gaphas&#039; new Aspects API. Still need a way to reconnect&lt;br /&gt;
*Start identifying crucial aspects for Canvas Modelling&lt;br /&gt;
*Started developing Use-Cases&lt;br /&gt;
*Had a meet with Prof Kannan. Got a huge motivation&lt;br /&gt;
*#Got in touch with Shrikanth and Ankit to identify aspects for use of Canvas modeller in a class room environment&lt;br /&gt;
*#Got in touch with Delhi FOSS community&lt;br /&gt;
*Started working on implementation details for Type-Checking, Closed-Loop flow sheets, User-customisable icons&lt;br /&gt;
*Got this wiki page up&lt;br /&gt;
&lt;br /&gt;
====Week 2====&lt;br /&gt;
7th-June-10 to 13th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Complete study of use cases&lt;br /&gt;
*Have connections code completely set, robust and future ready&lt;br /&gt;
*Have implementation details of at least one of the GUI features&lt;br /&gt;
&#039;&#039;Status of work&#039;&#039;&lt;br /&gt;
*The canvas connection code is completely done. User can connect/disconnect items multiple times.&lt;br /&gt;
*Improved the block propertied dialogue box a lot. &lt;br /&gt;
*#Shifted the basic structure to XML, using Glade.&lt;br /&gt;
*#Due to no implementation of [[#Type Information]], setting units may still create a problem.&lt;br /&gt;
*#Parameters are now viewable through a List view.&lt;br /&gt;
*Use cases still need more work.&lt;br /&gt;
*Worked out some details of implementing Undo/Redo system. Starting the work to implement them.&lt;br /&gt;
&lt;br /&gt;
====Week 3====&lt;br /&gt;
14th-June-10 to 20th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Set up the Undo/Redo system.&lt;br /&gt;
*Improve the Unit checking.&lt;br /&gt;
*Get ideas, implementation details on [[#Support for user-customisable custom icon types]].&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Status of Work&#039;&#039;&lt;br /&gt;
*A very basic Undo system in place.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Issues&#039;&#039;&lt;br /&gt;
*Identifying a way to record Undo transactions took a large part of the week, could not complete other objectives.&lt;br /&gt;
&lt;br /&gt;
====Week 4====&lt;br /&gt;
21st-June-10 to 27th-June-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO LIST&#039;&#039;&lt;br /&gt;
*Thoroughly test Undo system.&lt;br /&gt;
*Improve the Unit checking.&lt;br /&gt;
*Get ideas, implementation details on [[#Support for user-customisable custom icon types]]. &lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Status of Work&#039;&#039;&lt;br /&gt;
*Did many improvements to the Undo system.&lt;br /&gt;
*Improved the Key Accel&#039;s&lt;br /&gt;
*Improved Connections code.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Issues&#039;&#039;&lt;br /&gt;
*Callback functions do not record in gaphas as an event, so Undo system breaks at undoing a disconnect of Line Connection.&lt;br /&gt;
*Went through much of ASCEND API, but still not being able to identify Types and thus Units of parameters of blocks. For a temporary solution tried a failed attempt to get a Simulation of the String Model and identify Types. &lt;br /&gt;
*Problem lies in not being able to get [[#Type Information]] in the model by name, which is the only information we have from annotations.&lt;br /&gt;
*Finding ways for [[#Support for user-customisable custom icon types]] implementation details, studied how Modellica handles Graphic properties of blocks.&lt;br /&gt;
&lt;br /&gt;
====Week 5====&lt;br /&gt;
28th-June-10 to 4th-July-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
*Set up freesteam, solve and study rankine.a4c&lt;br /&gt;
*Try to implement [[#Support for user-customisable custom icon types]] by Mid-Term, get implementation details and begin work.&lt;br /&gt;
*Check for solutions for Line connection Undo bug.&lt;br /&gt;
*Find a way for getting [[#Type Information]].&lt;br /&gt;
*Deal with [[#Bugs]].&lt;br /&gt;
&lt;br /&gt;
====Week 6====&lt;br /&gt;
5th-July-10 to 11th-July-10&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;TODO List&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
====Week 7====&lt;br /&gt;
12th-July-10 to 18th-July-10&lt;br /&gt;
*Submit Mid Term Evaluations&lt;br /&gt;
&lt;br /&gt;
====Week 8====&lt;br /&gt;
19th-July-10 to 25th-July-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 9====&lt;br /&gt;
26th-July-10 to 1st-August-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 10====&lt;br /&gt;
2nd-August-10 to 8th-August-10&lt;br /&gt;
*TODO&lt;br /&gt;
&lt;br /&gt;
====Week 11====&lt;br /&gt;
9th-August-10 to 16th-August-10&lt;br /&gt;
*Finalise work&lt;br /&gt;
*Submit End Term Evaluations&lt;br /&gt;
*Tie loose ends&lt;/div&gt;</summary>
		<author><name>Grivan</name></author>
	</entry>
</feed>