Canvas Development - Revision history

Grivan: /* GUI Usability Improvements */

2011-08-24T06:22:47Z

GUI Usability Improvements

← Older revision		Revision as of 06:22, 24 August 2011
Line 69:		Line 69:
	===Line routing===		===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 [http://adaptagrams.sourceforge.net/libavoid/index.html libavoid] for this.		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.

			===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==		==Improvements on the Solving Process==

Grivan: /* Update for Gaphas HEAD */

2011-08-24T06:19:47Z

Update for Gaphas HEAD

← Older revision		Revision as of 06:19, 24 August 2011
Line 48:		Line 48:
	===Line Connection===		===Line Connection===
	Line Connection now uses Aspects, it is quite stable.		Line Connection now uses Aspects, it is quite stable.

			===Line Routing===
			Look further for details.

	==GUI Usability Improvements==		==GUI Usability Improvements==

Grivan: /* Use Cases */

2011-08-24T06:18:55Z

Use Cases

← Older revision		Revision as of 06:18, 24 August 2011
Line 4:		Line 4:
	==Use Cases==		==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.		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. Add new use cases based upon electronic circuit models sent over by [[Divyanshu Bandil\|Divyanshu]].~~

	===Simple Rankine Cycle===		===Simple Rankine Cycle===
Line 14:		Line 12:
	*Set up of extra components: Pump, Turbine, Boiler, Condenser have been annotated to provide blocks with suitable parameters.		*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===		===Regenerative Rankine Cycle===
	[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.		[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.
	This particular model would require from us to:		This particular model would require from us to:
	*Set up of extra components		*Set up of extra components: Pump, Turbine, Boiler, Condenser, Feedwater Heater, TEE piece.
	~~:''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. (Only if we do not use ATS)
	*Elimination of redundant equations in closed loop flows.		*Specifications and provisioning of complex flow streams.
	*:Multiple loops present in the system.		*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]].
	~~:''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 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.		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 [http://en.wikipedia.org/wiki/Plug_flow_reactor_model plug flow] or Gibbs.		*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.
	*~~In this case connections may need to be manually specified in order to provide~~ complex ~~flows as required~~.		*Specifications and provisioning of complex flow streams.

	===Non-Chemical Models===		===Non-Chemical Models===
Line 43:		Line 32:
	*[[Worked_examples#Four bar linkage \| Four bar linkage]]		*[[Worked_examples#Four bar linkage \| 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.		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.		*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.
	**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===		===Dynamic Modelling with backlash and PID control===
	*~~TODO : Add description~~		*Some time after we can look at solving a dynamic model!

	==Update for [[Gaphas]] HEAD==		==Update for [[Gaphas]] HEAD==

Grivan: /* Simple Rankine Cycle */

2011-08-24T06:10:02Z

Simple Rankine Cycle

← Older revision		Revision as of 06:10, 24 August 2011
Line 11:		Line 11:
	[[Image:Screenshot-Block_Description.png\|thumb\|200px\|right\|Instance browser showing partial results.]]		[[Image:Screenshot-Block_Description.png\|thumb\|200px\|right\|Instance browser showing partial results.]]
	A simple Rankine cycle has been modelled as a use case to see what all is missing.		A simple Rankine cycle has been modelled as a use case to see what all is missing.
	*Global Model equations.		*Global Model equations: A 'Canvas Properties' pop-up allows for additions of extra declarations to the MODEL.
	~~:''Implementation''~~: 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.
	*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===		===Regenerative Rankine Cycle===

Grivan: /* GUI Usability Improvements */

2011-08-24T06:07:21Z

GUI Usability Improvements

← Older revision		Revision as of 06:07, 24 August 2011
Line 69:		Line 69:

	==GUI Usability Improvements==		==GUI Usability Improvements==
	~~TODO : Keep adding details~~

	===Undo/Redo Support ===		===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.		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.
Line 84:		Line 82:
	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.		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		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 [http://adaptagrams.sourceforge.net/libavoid/index.html libavoid] for this.

	==Improvements on the Solving Process==		==Improvements on the Solving Process==

Grivan: /* Specification of flow streams */

2011-08-24T05:40:44Z

Specification of flow streams

@@ Line 89: / Line 89: @@
 ==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;
+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:
+*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,
 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.
 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:

Grivan: /* Specification of flow streams */

2011-08-24T05:27:32Z

Specification of flow streams

← Older revision		Revision as of 05:27, 24 August 2011
Line 90:		Line 90:
	==Specification of flow streams==		==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;		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:		*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']).
	*:This would provide a suitable GUI to select the stream.		*Application level implementation:
	*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 {{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.		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.
			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:
	~~TODO : Add implementation details~~		*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==		==Type Information==

Grivan: /* Week 5 */

2011-07-03T18:41:29Z

Week 5

← Older revision		Revision as of 18:41, 3 July 2011
Line 152:		Line 152:
	====Week 5====		====Week 5====
	27th-June-11 to 3th-July-11		27th-June-11 to 3th-July-11
	~~</n>~~Still struggling with the stream implementation, will do the complete update in a few days time.
			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		*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.		*Some success, but still not being able to solve the generated model.

Grivan: /* Week 5 */

2011-07-03T18:41:12Z

Week 5

← Older revision		Revision as of 18:41, 3 July 2011
Line 152:		Line 152:
	====Week 5====		====Week 5====
	27th-June-11 to 3th-July-11		27th-June-11 to 3th-July-11
	<\n>Still struggling with the stream implementation, will do the complete update in a few days time.		</n>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		*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.		*Some success, but still not being able to solve the generated model.

Grivan: /* Week 5 */

2011-07-03T18:40:57Z

Week 5

← Older revision		Revision as of 18:40, 3 July 2011
Line 152:		Line 152:
	====Week 5====		====Week 5====
	27th-June-11 to 3th-July-11		27th-June-11 to 3th-July-11
	Still struggling with the stream implementation, will do the complete update in a few days time.		<\n>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		*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.		*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====		====Week 6====