User:Grivan - Revision history

Grivan at 16:42, 12 December 2013

2013-12-12T16:42:32Z

← Older revision		Revision as of 16:42, 12 December 2013
Line 3:		Line 3:
	Subversion Branch {{srcbranchdir\|grivan\|}} and {{srcbranchdir\|grivan2\|}} (merged into trunk code as of May 2012).		Subversion Branch {{srcbranchdir\|grivan\|}} and {{srcbranchdir\|grivan2\|}} (merged into trunk code as of May 2012).

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

	=Work for [[GSOC2011]]=		=Work for [[GSOC2011]]=

Jpye at 20:58, 16 May 2012

2012-05-16T20:58:42Z

← Older revision		Revision as of 20:58, 16 May 2012
Line 5:		Line 5:
	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.		I am pursuing my Bachelor of Engineering Degree from Netaji Subhas Institute of Technology, University of Delhi, and will graduate the four-year course in 2011.

	=~~Current~~ Work=		=Work for [[GSOC2011]]=
	===Canvas===		===Canvas===
	===Goals===		===Goals===
Line 54:		Line 54:
	*Some work on bugs, {{changeset\|3482}} and {{changeset\|3513}}.		*Some work on bugs, {{changeset\|3482}} and {{changeset\|3513}}.

	=~~Past Work~~=		=Previous work=

	==~~GSoC 2010~~ Participation==		==[[GSOC2010]] Participation==
	GSoC 2010 Proposal: [http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/ascend/t127230757715 Improvement on Canvas-based modelling for ASCEND] <br> See [[Canvas-based modeller for ASCEND]] for more information.		GSoC 2010 Proposal: [http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/ascend/t127230757715 Improvement on Canvas-based modelling for ASCEND] <br> See [[Canvas-based modeller for ASCEND]] for more information.
	<br>Mentor: [[John Pye]]		<br>Mentor: [[John Pye]]

Jpye at 20:57, 16 May 2012

2012-05-16T20:57:50Z

← Older revision		Revision as of 20:57, 16 May 2012
Line 1:		Line 1:
	'''Grivan Thapar'''		'''Grivan Thapar'''

	Subversion Branch {{srcbranchdir\|grivan\|}} and {{srcbranchdir\|grivan2\|}}		Subversion Branch {{srcbranchdir\|grivan\|}} and {{srcbranchdir\|grivan2\|}} (merged into trunk code as of May 2012).

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

Jpye: /* GSoC 2010 Participation */

2011-08-19T04:13:13Z

GSoC 2010 Participation

← Older revision		Revision as of 04:13, 19 August 2011
Line 57:		Line 57:

	==GSoC 2010 Participation==		==GSoC 2010 Participation==
	GSoC 2010 Proposal: [http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/ascend/t127230757715 Improvement on Canvas-based modelling for ~~Ascend~~] <br> See [[Canvas-based modeller for ASCEND]] for more information.		GSoC 2010 Proposal: [http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/ascend/t127230757715 Improvement on Canvas-based modelling for ASCEND] <br> See [[Canvas-based modeller for ASCEND]] for more information.
	<br>Mentor: [[John Pye]]		<br>Mentor: [[John Pye]]

Jpye at 05:06, 6 August 2011

2011-08-06T05:06:27Z

← Older revision		Revision as of 05:06, 6 August 2011
Line 99:		Line 99:
	[[Category:GSOC2010]]		[[Category:GSOC2010]]
	[[Category:GSOC2011]]		[[Category:GSOC2011]]
			[[Category:ASCEND Contributors]]

Grivan: /* Progress */

2011-07-15T15:04:42Z

Progress

← Older revision		Revision as of 15:04, 15 July 2011
Line 50:		Line 50:
	===Progress===		===Progress===
	*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.		*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.
	*~~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.		*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.
	*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.		*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.
	*Some work on bugs, {{changeset\|3482}} and {{changeset\|3513}}.		*Some work on bugs, {{changeset\|3482}} and {{changeset\|3513}}.

Grivan at 15:00, 15 July 2011

2011-07-15T15:00:33Z

← Older revision		Revision as of 15:00, 15 July 2011
Line 7:		Line 7:
	=Current Work=		=Current Work=
	===Canvas===		===Canvas===
	===Goals====		===Goals===
	====Parameter Handling====		====Parameter Handling====
	There seems a possibility of using the NOTES and METHODS together to allow a suitable design solution to parameter handling.		There seems a possibility of using the NOTES and METHODS together to allow a suitable design solution to parameter handling.

Grivan at 15:00, 15 July 2011

2011-07-15T15:00:13Z

← Older revision		Revision as of 15:00, 15 July 2011
Line 8:		Line 8:
	===Canvas===		===Canvas===
	===Goals====		===Goals====
	====Parameter Handling===		====Parameter Handling====
	There seems a possibility of using the NOTES and METHODS together to allow a suitable design solution to parameter handling.		There seems a possibility of using the NOTES and METHODS together to allow a suitable design solution to parameter handling.

Grivan at 14:59, 15 July 2011

2011-07-15T14:59:10Z

← Older revision		Revision as of 14:59, 15 July 2011
Line 6:		Line 6:

	=Current Work=		=Current Work=
	==Canvas==		===Canvas===
	===Parameter Handling===		===Goals====
			====Parameter Handling===
	There seems a possibility of using the NOTES and METHODS together to allow a suitable design solution to parameter handling.		There seems a possibility of using the NOTES and METHODS together to allow a suitable design solution to parameter handling.

Line 35:		Line 36:
	Using the two above things together will let us into hopefully a good design solution for the parameters.		Using the two above things together will let us into hopefully a good design solution for the parameters.

	===Solving Process===		====Solving Process====
	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.		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.
	*Have to deal with the 'instances' 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.		*Have to deal with the 'instances' 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.
Line 41:		Line 42:
	*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).		*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).

	===Other Tasks===		====Other Tasks====
	#Set up canvas to use the new libavoid bindings. Although could be done before, in case the libavoid bindings are completed.		#Set up canvas to use the new libavoid bindings. Although could be done before, in case the libavoid bindings are completed.
	#For Undo need to look for better method for segregating transactions, only some more tweaking should be necessary.		#For Undo need to look for better method for segregating transactions, only some more tweaking should be necessary.
Line 47:		Line 48:
	#User defined shapes of the 'blocks', this was proposed last year but not completed, we will have to take care though of libavoid limitations here though.		#User defined shapes of the 'blocks', this was proposed last year but not completed, we will have to take care though of libavoid limitations here though.
	#Other smaller GUI improvements, embedding the Canvas into main GUI, more model libraries etc.		#Other smaller GUI improvements, embedding the Canvas into main GUI, more model libraries etc.
			===Progress===
			*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.
			*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.
			*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.
			*Some work on bugs, {{changeset\|3482}} and {{changeset\|3513}}.

	=Past Work=		=Past Work=

Jpye at 01:12, 16 May 2011

2011-05-16T01:12:19Z

← Older revision		Revision as of 01:12, 16 May 2011
Line 90:		Line 90:

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




	[[Category:GSOC2010]]		[[Category:GSOC2010]]
			[[Category:GSOC2011]]