Controlling the solvers from within METHODS - Revision history

Jpye: /* Implementation */

2015-03-04T02:42:35Z

Implementation

← Older revision		Revision as of 02:42, 4 March 2015
Line 68:		Line 68:
	There is currently no support for solving any MODEL other than that returned from <tt>GetSimulationRoot</tt>. Support for this seems to be a little difficult to design.		There is currently no support for solving any MODEL other than that returned from <tt>GetSimulationRoot</tt>. Support for this seems to be a little difficult to design.

	As mentioned above, how these functions work exactly is up to the 'driver' to define. Some standard error codes are defined, so that the <tt>Initialize</tt> function in ~~[http://ascendcode.cheme.cmu.edu/viewvc.cgi/code/branches/slvreq/ascend/compiler/initialize.c <font color="orange">slvreq</font>:~~ascend/compiler/initialize.c] is able to make sensible error messages for the user. But otherwise, the 'driver' gets to decide.		As mentioned above, how these functions work exactly is up to the 'driver' to define. Some standard error codes are defined, so that the <tt>Initialize</tt> function in {{src\|ascend/compiler/initialize.c}} is able to make sensible error messages for the user. But otherwise, the 'driver' gets to decide.

	In order to allow the 'driver' to store implementation-dependent data along with the <tt>slvreq_hooks</tt>, a <tt>user_data</tt> pointer can be provided when the hooks are assigned. This user_data parameter is then provided back the driver whenever any of those hook functions are actually called.		In order to allow the 'driver' to store implementation-dependent data along with the <tt>slvreq_hooks</tt>, a <tt>user_data</tt> pointer can be provided when the hooks are assigned. This user_data parameter is then provided back the driver whenever any of those hook functions are actually called.

Jpye: /* Implementation */

2015-03-04T02:41:27Z

Implementation

← Older revision		Revision as of 02:41, 4 March 2015
Line 66:		Line 66:
	When the SOLVE command is executed, it calls <tt>slvreq_do_solve</tt> and then <tt>do_solve_fn</tt>.		When the SOLVE command is executed, it calls <tt>slvreq_do_solve</tt> and then <tt>do_solve_fn</tt>.

	There is currently no support for solving any MODEL other than that returned from ~~</~~tt~~>~~GetSimulationRoot~~<~~/tt~~>~~. Support for this seems to be a little difficult to design.		There is currently no support for solving any MODEL other than that returned from <tt>GetSimulationRoot</tt>. Support for this seems to be a little difficult to design.

	As mentioned above, how these functions work exactly is up to the 'driver' to define. Some standard error codes are defined, so that the <tt>Initialize</tt> function in [http://ascendcode.cheme.cmu.edu/viewvc.cgi/code/branches/slvreq/ascend/compiler/initialize.c <font color="orange">slvreq</font>:ascend/compiler/initialize.c] is able to make sensible error messages for the user. But otherwise, the 'driver' gets to decide.		As mentioned above, how these functions work exactly is up to the 'driver' to define. Some standard error codes are defined, so that the <tt>Initialize</tt> function in [http://ascendcode.cheme.cmu.edu/viewvc.cgi/code/branches/slvreq/ascend/compiler/initialize.c <font color="orange">slvreq</font>:ascend/compiler/initialize.c] is able to make sensible error messages for the user. But otherwise, the 'driver' gets to decide.

Jpye at 22:49, 20 June 2012

2012-06-20T22:49:59Z

← Older revision		Revision as of 22:49, 20 June 2012
Line 1:		Line 1:
	{{experimental}}		{{experimental}}
	The following new proposed syntax has been introduced into the ASCEND language in a developmental branch called slvreq, see [http://ascendcode.cheme.cmu.edu/viewvc.cgi/code/branches/slvreq/ascend/compiler/slvreq.h <font color="orange">slvreq</font>:ascend/compiler/slvreq.h].

	Support is added for three new statements relating to 'solver requests' in the ASCEND language:		Support is added for three new statements relating to 'solver requests' in the ASCEND language:

Jpye at 08:05, 29 March 2011

2011-03-29T08:05:57Z

← Older revision		Revision as of 08:05, 29 March 2011
Line 1:		Line 1:
	{{~~task~~}}		{{experimental}}
	The following new proposed syntax has been introduced into the ASCEND language in a developmental branch called slvreq, see [http://ascendcode.cheme.cmu.edu/viewvc.cgi/code/branches/slvreq/ascend/compiler/slvreq.h <font color="orange">slvreq</font>:ascend/compiler/slvreq.h].		The following new proposed syntax has been introduced into the ASCEND language in a developmental branch called slvreq, see [http://ascendcode.cheme.cmu.edu/viewvc.cgi/code/branches/slvreq/ascend/compiler/slvreq.h <font color="orange">slvreq</font>:ascend/compiler/slvreq.h].

Jpye at 07:47, 3 August 2010

2010-08-03T07:47:16Z

← Older revision		Revision as of 07:47, 3 August 2010
Line 7:		Line 7:
	* '''OPTION''' to specify values for options to be used during solving.		* '''OPTION''' to specify values for options to be used during solving.
	* '''SOLVE''' to actually trigger the user interface to go ahead and solve the MODEL.		* '''SOLVE''' to actually trigger the user interface to go ahead and solve the MODEL.

			'''WARNING'''. There appears to be a bug with the the SOLVER statement, which is that it must be the last statement executed before solution of the model is attempted. Otherwise [[FIX]]ed and [[FREE]]d variables may not be correctly updated ({{bug\|472}}).

	<source lang="a4c">MODEL mymodel;		<source lang="a4c">MODEL mymodel;
	x,y IS_A solver_var;		x,y IS_A solver_var;
Line 44:		Line 47:

	Both of these have implications for the GUI layer and how it organises itself.		Both of these have implications for the GUI layer and how it organises itself.

	'''WARNING'''. There appears to be a bug with the the SOLVER statement, which is that it must be the last statement executed before solution of the model is attempted. Otherwise [[FIX]]ed and [[FREE]]d variables may not be correctly updated ({{bug\|472}}).

	==Motivation==		==Motivation==

Jpye at 07:46, 3 August 2010

2010-08-03T07:46:50Z

← Older revision		Revision as of 07:46, 3 August 2010
Line 44:		Line 44:

	Both of these have implications for the GUI layer and how it organises itself.		Both of these have implications for the GUI layer and how it organises itself.

			'''WARNING'''. There appears to be a bug with the the SOLVER statement, which is that it must be the last statement executed before solution of the model is attempted. Otherwise [[FIX]]ed and [[FREE]]d variables may not be correctly updated ({{bug\|472}}).

	==Motivation==		==Motivation==

Jpye: /* Problems and questions */

2010-07-21T10:56:54Z

Problems and questions

← Older revision		Revision as of 10:56, 21 July 2010
Line 133:		Line 133:

	==Problems and questions==		==Problems and questions==

			'''Bug:''' there is a bug if the SOLVER and other commands are placed before all the METHODS that specify values etc. {{bug\|472}}.

	'''Problem:''' some effort was made (simlist.c) to implement support for multiple SimulationInstances per instance tree. This has never been fully realised (and the merits of this idea are not yet completely clear to me). But the the current slvreq depends crucially on the fact that, within a running METHOD, it's possible to determine what is the current SimulationInstance.		'''Problem:''' some effort was made (simlist.c) to implement support for multiple SimulationInstances per instance tree. This has never been fully realised (and the merits of this idea are not yet completely clear to me). But the the current slvreq depends crucially on the fact that, within a running METHOD, it's possible to determine what is the current SimulationInstance.

Jpye: /* GUI integration */

2010-05-29T10:52:41Z

GUI integration

← Older revision		Revision as of 10:52, 29 May 2010
Line 169:		Line 169:
	** finds that solvername.parametername is valid, and sets the parameter (after casting it to the appropriate type)		** finds that solvername.parametername is valid, and sets the parameter (after casting it to the appropriate type)
	** finds that solvername.parametername is not valid, and returns an error code		** finds that solvername.parametername is not valid, and returns an error code
	** finds that solvername.parametername is valid, and sets the parameter (after casting it to the appropriate type)
	** finds that solvername.parametername is not valid, and returns an error code
	* finds that solvername.parametername is valid, and sets the parameter (after casting it to the appropriate type)
	* finds that solvername.parametername is not valid, and returns an error code
	* libascend proceeds with more METHOD statments...		* libascend proceeds with more METHOD statments...

	[[Category:Documentation]]		[[Category:Documentation]]

Jpye at 06:42, 19 May 2010

2010-05-19T06:42:57Z

← Older revision		Revision as of 06:42, 19 May 2010
Line 174:		Line 174:
	* finds that solvername.parametername is not valid, and returns an error code		* finds that solvername.parametername is not valid, and returns an error code
	* libascend proceeds with more METHOD statments...		* libascend proceeds with more METHOD statments...

			[[Category:Documentation]]

Jpye at 06:42, 19 May 2010

2010-05-19T06:42:40Z

← Older revision		Revision as of 06:42, 19 May 2010
Line 24:		Line 24:
	END mymodel;</source>		END mymodel;</source>

			== Syntax ==

	=~~= Syntax ==~~		<source lang=a4c>
	~~<pre~~>
	SOLVER solvername;		SOLVER solvername;
	OPTION optionname valuexpression;		OPTION optionname valuexpression;
	SOLVE;		SOLVE;
	</~~pre~~>		</source>

	It is proposed to additionally set the syntax for solving particular instances, perhaps as		It is proposed to additionally set the syntax for solving particular instances, perhaps as

	<~~pre~~>		<source lang=a4c>
	SOLVER solvername WITH myinstance		SOLVER solvername WITH myinstance
	</~~pre~~>		</source>

	or else perhaps as		or else perhaps as

	<~~pre~~>		<source lang=a4c>
	SOLVE myinstance		SOLVE myinstance
	</~~pre~~>		</source>

	Both of these have implications for the GUI layer and how it organises itself.		Both of these have implications for the GUI layer and how it organises itself.


	==Motivation==		==Motivation==
Line 53:		Line 51:
	However, many models won't just solve with a simple click of the 'solve' button. Some models need specific solvers to be selected first, and other models will only solve if suitable values of the solver parameters are defined. Neither of these things can be done from within the modelling language, so the result is that the write-test-debug loop for model-making has required the user to either do a lot of spurious clicking to set options each time, or else to write a script to 'drive' ASCEND with the correct settings. Neither of these are particularly user-friendly; [[John Pye]] thinks it should be possible for the user to do 'everything they want' from within a single modelling file.		However, many models won't just solve with a simple click of the 'solve' button. Some models need specific solvers to be selected first, and other models will only solve if suitable values of the solver parameters are defined. Neither of these things can be done from within the modelling language, so the result is that the write-test-debug loop for model-making has required the user to either do a lot of spurious clicking to set options each time, or else to write a script to 'drive' ASCEND with the correct settings. Neither of these are particularly user-friendly; [[John Pye]] thinks it should be possible for the user to do 'everything they want' from within a single modelling file.

	[[Ben Allan]] has pointed out that such a goal (doing 'everything you want' from within an .a4c file) is unreasonable, because the syntax available within [[METHOD\|METHODs]] is too limited to allow anything very sophisticated, and we don't want to develop a full-blown language there. That's a fair point, but the addition of these commands is seen as being so advantageous to user experience that John Pye thought it was worth attempting, regardless.		[[Ben Allan]] has pointed out that such a goal (doing 'everything you want' from within an .a4c file) is unreasonable, because the syntax available within [[METHOD\|METHODs]] is too limited to allow anything very sophisticated, and we don't want to develop a full-blown language there. That's a fair point, but the addition of these commands is seen as being so advantageous to user experience that [[John Pye]] thought it was worth attempting, regardless.


	== Implementation ==		== Implementation ==
Line 61:		Line 58:

	A new pointer was added to the <tt>SimulationInstance</tt> object, called <tt>slvreq_hooks</tt>, allowing an ASCEND 'driver' (GUI, command-line interface, test suite, etc) to provide hook functions (via a call to <tt>slvreq_assign_hooks</tt>) to which the different SOLVER, OPTION and SOLVE commands could be passed. What those commands then do is left entirely up to the 'driver'.		A new pointer was added to the <tt>SimulationInstance</tt> object, called <tt>slvreq_hooks</tt>, allowing an ASCEND 'driver' (GUI, command-line interface, test suite, etc) to provide hook functions (via a call to <tt>slvreq_assign_hooks</tt>) to which the different SOLVER, OPTION and SOLVE commands could be passed. What those commands then do is left entirely up to the 'driver'.


	Whenever the SOLVER command is encountered, it eventually finds its way to a call to <tt>slvreq_set_solver</tt>. This function locates the slvreq_hooks object in the SimulationInstance, and then, if available, runs the <tt>set_solver_fn</tt> hook function (hopefully) earlier provided by the 'driver'.		Whenever the SOLVER command is encountered, it eventually finds its way to a call to <tt>slvreq_set_solver</tt>. This function locates the slvreq_hooks object in the SimulationInstance, and then, if available, runs the <tt>set_solver_fn</tt> hook function (hopefully) earlier provided by the 'driver'.
Line 68:		Line 64:

	When the SOLVE command is executed, it calls <tt>slvreq_do_solve</tt> and then <tt>do_solve_fn</tt>.		When the SOLVE command is executed, it calls <tt>slvreq_do_solve</tt> and then <tt>do_solve_fn</tt>.


	There is currently no support for solving any MODEL other than that returned from </tt>GetSimulationRoot</tt>. Support for this seems to be a little difficult to design.		There is currently no support for solving any MODEL other than that returned from </tt>GetSimulationRoot</tt>. Support for this seems to be a little difficult to design.
Line 75:		Line 70:

	In order to allow the 'driver' to store implementation-dependent data along with the <tt>slvreq_hooks</tt>, a <tt>user_data</tt> pointer can be provided when the hooks are assigned. This user_data parameter is then provided back the driver whenever any of those hook functions are actually called.		In order to allow the 'driver' to store implementation-dependent data along with the <tt>slvreq_hooks</tt>, a <tt>user_data</tt> pointer can be provided when the hooks are assigned. This user_data parameter is then provided back the driver whenever any of those hook functions are actually called.



	==Sample driver: test_slvreq.c==		==Sample driver: test_slvreq.c==

	A sample 'driver' implementation with support for the <tt>slvreq</tt> functions is [http://ascendcode.cheme.cmu.edu/viewvc.cgi/code/branches/slvreq/ascend/compiler/test/test_slvreq.c <font color="orange">slvreq</font>:ascend/compiler/test/test_slvreq.c]. This implementation works as follows		A sample 'driver' implementation with support for the <tt>slvreq</tt> functions is [http://ascendcode.cheme.cmu.edu/viewvc.cgi/code/branches/slvreq/ascend/compiler/test/test_slvreq.c <font color="orange">slvreq</font>:ascend/compiler/test/test_slvreq.c]. This implementation works as follows


	* SimulationInstance->slvreq_hooks points to a structure containing the simulation instance pointer together with (optionally) a <tt>slv_system_t</tt> object, '''sys'''. If the system has been built this 'sys' is non-NULL. Otherwise it is NULL. The system is built only once, when the first SOLVER statement is encountered.		* SimulationInstance->slvreq_hooks points to a structure containing the simulation instance pointer together with (optionally) a <tt>slv_system_t</tt> object, '''sys'''. If the system has been built this 'sys' is non-NULL. Otherwise it is NULL. The system is built only once, when the first SOLVER statement is encountered.
Line 150:		Line 142:

	See also [[Solver NOTES]], another proposed solution to this problem.		See also [[Solver NOTES]], another proposed solution to this problem.


	==GUI integration==		==GUI integration==