Canvas Development

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

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

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.

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: A 'Canvas Properties' pop-up allows for additions of extra declarations to the MODEL.
• Set up of extra components: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.

We want to solve models that have feedback loops,

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 (NOTE: see also 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. This particular model would require from us to:

• Set up of extra components: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece.
• Elimination of redundant equations in closed loop flows. (Only if we do not use ATS)
• Specifications and provisioning of complex flow streams.
• 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.

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.
• Specifications and provisioning of complex flow streams.

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 with backlash and PID control

• Some time after we can look at solving a dynamic model!

Update for Gaphas HEAD

The new Gapahs 0.7.2 release till now seems to work fine. 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.

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.

Line Routing

Look further for details.

GUI Usability Improvements

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

Line routing

Gaphas now supports line routing, the canvas code would require some changes to work with that. Check the avoid branch of gaphas. It uses libavoid for this.

Save and restore

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.

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.

• GUI implementation: This would provide a suitable GUI to select the stream. An annotated set defined in the 'stream' 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: ['N2','H2','NH3']).
• 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.

The conventional way,

MODEL mycanvas;
A, B, C IS_A stream(['N2','H2','NH3'])
BO IS_A boiler(A,B);
CO IS_A condenser(C,A);
END mycanvas;

A way John suggests,

MODEL mycanvas;
A, B, C IS_A stream(['N2','H2','NH3'])
BO IS_A boiler;
CO IS_A condenser;
A, BO.inlet, CO.outlet ARE_THE_SAME;
END mycanvas;

The way it is now,

MODEL steram;
components "param: set of stream components" IS_A set OF symbol_constant;
END stream;
MODEL mycanvas;
A, B, C IS_A stream;
BO IS_A boiler;
CO IS_A condenser;
A, BO.inlet, CO.outlet ARE_THE_SAME;

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. The ASCEND library provides for generic 'stream' 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:

• The 'stream' 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).
• 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.
• Specifying streams requires 'sets' to be defined, we might just require to use ARRAY types which can be defined on 'sets', but currently we have no way of identifying array types in our block models, not even through annotations. Some sort of 'hack' can work though, but I am just saying.

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() works as it should in case of all user generated foreseeable canvas models.

Weekly Reports GSOC 2011

The weekly reports will be filed here.

Week 0

23th-May-11 to 29th-May-11

• Necessary changes for libavoid bindings.
  • Still needs some work on the connection mechanism.

Week 1

30th-May-11 to 5th-June-11

Week 2

6th-June-11 to 12th-June-11

• Some progress towards having methods to set the default values. changeset 3474
• Some unusual behavior while updating to use of SWIG 2, some quick fixes. changeset 3482
• Some work towards getting stream into the canvas.

Week 3

13th-June-11 to 19th-June-11

Goals:

• Set up some mechanism of setting of default values.
• Get implementation ideas on setting up of globals and streams on the canvas. Possibly begin some work on them.

Week 4

20th-June-11 to 26th-June-11

• Stream MODEL's recognized by canvas as globals.
• User can set streams to blocks.
• 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.
• Spent the weekend on reading the complete models developed by Art on the Hydrogen cycles, which has a set based implementation of streams.

Week 5

27th-June-11 to 3th-July-11

Still struggling with the stream implementation, will do the complete update in a few days time.

• Writing a new version of Rankine cycle blocks for canvas using the 'stream' component defined in the models/stream_holdup.a4l
• Some success, but still not being able to solve the generated model.
• Basically in canvas we will have a global 'stream' 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.

Week 6

4th-July-11 to 10th-July-11

Week 7

11th-July-11 to 17th-July-11

Week 8

18th-July-11 to 24th-July-11

Week 9

25th-July-11 to 31st-July-11

Week 10

1st-August-11 to 7th-August-11

Week 11

8th-August-11 to 15th-August-11