Canvas Development

This article is about planned development or proposed functionality. Comments welcome.

This page aims to document all the GSoC 2010 development carried out by Grivan. The goals and tasks are additionally listed over 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.

Use Cases

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.

TODO : Add more ideas, put a concrete solution overview to each Case.

Simple Rankine Cycle

Error creating thumbnail: File missing

Canvas modeller for ASCEND, showing a simple Rankine Cycle solved.

Error creating thumbnail: File missing

Instance browser showing partial results.

A simple Rankine cycle has been modelled as a use case to see what all is missing.

• Global Model equations.

Implementation: A 'Canvas Properties' pop-up allows for additions of extra declarations to the MODEL.

• Set up of extra components.

Implementation: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.

• Block rotation.

  It would be nice if blocks could be rotated, it makes the canvas look more tidy.

• Other Issues.

  Just specifying a value and not Fixing it. Should it be possible?

  How to make additions of equations to the MODEL more intuitive.

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 models/johnpye/rankine.a4c. We would want to develop a steady state model of regenerative Rankine cycle. This particular model would require from us to:

• Set up of extra components

Implementation: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece. In addition take care of the ALIASES keyword used in the text model. TODO

• Elimination of redundant equations in closed loop flows.

  Multiple loops present in the system.

Implementation: Still needs to be discussed. TODO

• Specifications of flow streams.

  It should be possible to switch between stream components, water to CO2 to toluene for example.

  This however should not involve redrawing the whole model again.

Implementation: 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

• Providing complex flow streams.

  A regenerative cycle requires to specify the fraction of steam extracted at the bled 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.

Implementation: This should be easy as a simple TEE component must have a fixable variable 'fraction'.

• Present graphical models used to create the flowsheet in a more intuitive form. In styles of a PID or a PFD.

Implementation: See #Support for user-customisable custom icon types.

Ammonia Synthesis Reactor

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.

• The simulation type needs to determined. What kind of reactor will be used for example plug flow or Gibbs.
• In this case connections may need to be manually specified in order to provide complex flows as required.

Non-Chemical Models

ASCEND is a powerful language, it is fairly general to support all kinds of mathematical models. For example take look at these:

• Damped response
• Calculation of sun position
• Four bar linkage

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's general approach.

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

Dynamic Modelling of Servo Motor with backlash and PID control

• TODO : Add description

Update for Gaphas HEAD

The following section lists all the updating that needs to be done or has been done to work with latest gaphas head.

Aspects

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.

• The Aspects of gaphas API define the 'how' and Tools the 'what'.
• Specific handlers now have to be created to handle events like line disconnection on either of the ports, re-connection etc.
• This should be carefully designed to have no problems in the future as it is already an important component.

Line Connection

Line Connection now uses Aspects, it is quite stable.

GUI Usability Improvements

TODO : Keep adding details

Undo/Redo Support

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 observed into user level Transactions which could be applied to perform one Undo or a Redo.

• A basic but working mechanism is present.
• The mechanism breaks at undoing Line Connections.
• Add support for Undoing after a model has been solved. Give an error message like 'Undoing will discard your currently solved model.'
• Enable Redo.

Bugs

Maybe this bug list could be useful for that.

Support for user-customisable custom icon types

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. TODO : Add exact Implementation details

Improvements on the Solving Process

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't instantiate the model first and then solve it.

Specification of flow streams

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;

• GUI implementation:

  This would provide a suitable GUI to select the stream.

• Application level implementation

  This would add actual stream modifications to the block code.

The #Simple Rankine Cycle could be solved simply by connecting steam_port connectors. The 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.

TODO : Add implementation details

Type Information

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't very easy right now.

• To have highlighting of connectible ports while connecting two ports we need to:
  1. Find all suitable (IN/OUT/BOTH) ports available for connection.
  2. Create a set their Types.
  3. Check connect-ability for each of those types.
  4. Highlight only the connectible ones.

• To give a set of units that can be selected from a drop down menu in block properties:
  1. Scan for the Type of the parameter.
  2. Get the dimensions of the type.
  3. Scan for the units available.

• Implementation
  • Some testing has been done of the functions, see test_type_info() function inside /compiler/test/test_basics.c
  • The test can be run on any file, using scons test && test/test compiler_basics.type_info
  • From the observations, it is clear that the function GetChildList() work's as it should in case of all user generated foreseeable canvas models.

Key Deliverables

To set a stone for the GSoC project following have to be implemented

• Canvas Model for a Regenerative Rankine cycle
• Ammonia synthesis reactor
• Support for user customisable icon-types for blocks
• Undo Support

Weekly Reports

The weekly reports will be filed here. Week 0 starts from 24th of May up-to 30th of May and so on.

Week 0

24th-May-10 to 30th-May-10

• Set up environment
• Attempt to try and get modeller running

  Code updates for Gaphas HEAD using and Arijit's patch and some extra edits

  Except for connections feature canvas code successfully updates for Gaphas HEAD

  Code updates for py-gtksourceview2, enabled syntax highlighting

• Other minor issues resolved
• Unavailable for project completely due to scheduled end semester exams from 24th-July-10 to 2nd-July-10

Week 1

31st-May-10 to 6th-June-10
This was a 'pull-up-socks' week, main aim was to get back on after exams and prioritise work

• Attempt to fix the connections code
  1. Connection disconnection done, using Gaphas' new Aspects API. Still need a way to reconnect
• Start identifying crucial aspects for Canvas Modelling
• Started developing Use-Cases
• Had a meet with Prof Kannan. Got a huge motivation
  1. Got in touch with Shrikanth and Ankit to identify aspects for use of Canvas modeller in a class room environment
  2. Got in touch with Delhi FOSS community
• Started working on implementation details for Type-Checking, Closed-Loop flow sheets, User-customisable icons
• Got this wiki page up

Week 2

7th-June-10 to 13th-June-10
TODO List

• Complete study of use cases
• Have connections code completely set, robust and future ready
• Have implementation details of at least one of the GUI features

Status of work

• The canvas connection code is completely done. User can connect/disconnect items multiple times.
• Improved the block propertied dialogue box a lot.
  1. Shifted the basic structure to XML, using Glade.
  2. Due to no implementation of #Type Information, setting units may still create a problem.
  3. Parameters are now viewable through a List view.
• Use cases still need more work.
• Worked out some details of implementing Undo/Redo system. Starting the work to implement them.

Week 3

14th-June-10 to 20th-June-10
TODO List

• Set up the Undo/Redo system.
• Improve the Unit checking.
• Get ideas, implementation details on #Support for user-customisable custom icon types.

Status of Work

• A very basic Undo system in place.

Issues

• Identifying a way to record Undo transactions took a large part of the week, could not complete other objectives.

Week 4

21st-June-10 to 27th-June-10
TODO LIST

• Thoroughly test Undo system.
• Improve the Unit checking.
• Get ideas, implementation details on #Support for user-customisable custom icon types.

Status of Work

• Did many improvements to the Undo system.
• Improved the Key Accel's
• Improved Connections code.

Issues

• Callback functions do not record in gaphas as an event, so Undo system breaks at undoing a disconnect of Line Connection.
• 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.
• Problem lies in not being able to get #Type Information in the model by name, which is the only information we have from annotations.
• Finding ways for #Support for user-customisable custom icon types implementation details, studied how Modellica handles Graphic properties of blocks.

Week 5

28th-June-10 to 4th-July-10
TODO List

• Set up freesteam, solve and study rankine.a4c
• Try to implement #Support for user-customisable custom icon types by Mid-Term, get implementation details and begin work.
• Check for solutions for Line connection Undo bug.
• Find a way for getting #Type Information.
• Deal with #Bugs.

Week 6

5th-July-10 to 11th-July-10
TODO List

• Annotate rankine.a4c for Canvas Modelling.
• Solve #Simple Rankine Cycle through Canvas Modeller.
• GUI to add extra canvas MODEL equations/declarations.
• Work towards getting #Type Information
• Fix key-accel to Menu items.
• GUI for value-indicators of solved variables.

Status of Work

• Annotated models/johnpye/rankine.a4c and successfully Solved #Simple Rankine Cycle through Canvas Modeller.
• User can now add extra canvas MODEL equations/declarations.
• Menu items key-accel's improved.
• Other GUI improvements like extra Canvas-properties pop-up, more items to Contextmenu, etc.

Issues

• What if a parameter is not fixed but has a value? Could not understand what does it mean.
• 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.
• #Type Information still requires extra thinking and a lot of work.

Week 7

12th-July-10 to 18th-July-10

• Submit Mid Term Evaluations

Week 8

19th-July-10 to 25th-July-10

• TODO

Week 9

26th-July-10 to 1st-August-10

• TODO

Week 10

2nd-August-10 to 8th-August-10

• TODO

Week 11

9th-August-10 to 16th-August-10

• Finalise work
• Submit End Term Evaluations
• Tie loose ends