Grey-box Models - Revision history

Jpye at 00:30, 19 May 2010

2010-05-19T00:30:15Z

← Older revision		Revision as of 00:30, 19 May 2010
Line 5:		Line 5:

	The current ASCEND system for dealing with 'black box' elements would be a suitable API for allowing the solver to deal with these, hence the name 'grey box': the modeller can see the equations but the top-level solver can not, and must deal with the equations ''as though'' they were a ''black'' box.		The current ASCEND system for dealing with 'black box' elements would be a suitable API for allowing the solver to deal with these, hence the name 'grey box': the modeller can see the equations but the top-level solver can not, and must deal with the equations ''as though'' they were a ''black'' box.


	== Example ==		== Example ==
Line 14:		Line 13:

	We could just write		We could just write


	<source lang="a4c">MODEL circle;		<source lang="a4c">MODEL circle;
Line 43:		Line 41:

	The <tt>GREY(r_grey)</tt> statement would add the instance of type <tt>radius</tt> to the 'grey' list for the present model. When the problem analysis phase came along, the grey model would be found and encapsulated as a sub-model using the [[external libraries]] technique of 'black box', but instead of arbitrary black box code, the encapsulation would be of a sub-model solved using the [[QRSlv]] solver (in this case -- as specified).		The <tt>GREY(r_grey)</tt> statement would add the instance of type <tt>radius</tt> to the 'grey' list for the present model. When the problem analysis phase came along, the grey model would be found and encapsulated as a sub-model using the [[external libraries]] technique of 'black box', but instead of arbitrary black box code, the encapsulation would be of a sub-model solved using the [[QRSlv]] solver (in this case -- as specified).


	The <tt>GREY</tt> statement would simply be an specialisation of the proposed <tt>LINK</tt> statement.		The <tt>GREY</tt> statement would simply be an specialisation of the proposed <tt>LINK</tt> statement.




	~~[[Category:Proposed]]~~

Jpye at 00:29, 19 May 2010

2010-05-19T00:29:56Z

← Older revision		Revision as of 00:29, 19 May 2010
Line 42:		Line 42:
	END circle;</source>		END circle;</source>

	The <tt>GREY(r_grey)</tt> statement would add the instance of type <tt>radius</tt> to the 'grey' list for the present model. When the problem analysis phase came along, the grey model would be found and encapsulated as a sub-model using the [[~~ExternalLibraries~~]] technique of 'black box', but instead of arbitrary black box code, the encapsulation would be of a sub-model solved using the [[QRSlv]] solver (in this case -- as specified).		The <tt>GREY(r_grey)</tt> statement would add the instance of type <tt>radius</tt> to the 'grey' list for the present model. When the problem analysis phase came along, the grey model would be found and encapsulated as a sub-model using the [[external libraries]] technique of 'black box', but instead of arbitrary black box code, the encapsulation would be of a sub-model solved using the [[QRSlv]] solver (in this case -- as specified).

UploadBot: Restored page from Google Cache, uploaded by John Pye

2010-05-13T13:42:51Z

Restored page from Google Cache, uploaded by John Pye

New page

{{task}}
The idea of 'grey-box' models would be to give some way in which complicated sub-models could be expressed with intermediate variables, without needing to change the system's higher-level structure.

To some extent this is like explicit 'tearing' of the system of equations, as it delimits a block in which any internal variables must be solved before the higher-level system gets to see the remaining variables referenced by that block.

The current ASCEND system for dealing with 'black box' elements would be a suitable API for allowing the solver to deal with these, hence the name 'grey box': the modeller can see the equations but the top-level solver can not, and must deal with the equations ''as though'' they were a ''black'' box.

== Example ==

Perhaps we wish to solve a problem involving the radius of a circle

<math>r= \sqrt{x^2+y^2}</math>

We could just write

<source lang="a4c">MODEL circle;
x,y,r IS_A solver_var;

r_eq: r = sqrt(x^2 + y^2);

MODEL;</source>

but what if that <tt>r_eq</tt> were more complicated. Perhaps then we would like to write it separately and include some intermediate values in the calculation:

<source lang="a4c">MODEL radius;
x,y,r IS_A solver_var;

x2,y2 IS_A solver_var;
x2 = x^2;

y2 = y^2;
r = x2 + y2;

END radius;

MODEL circle;
r_grey IS_A radius;

GREY(r_grey,'QRSlv');
END circle;</source>

The <tt>GREY(r_grey)</tt> statement would add the instance of type <tt>radius</tt> to the 'grey' list for the present model. When the problem analysis phase came along, the grey model would be found and encapsulated as a sub-model using the [[ExternalLibraries]] technique of 'black box', but instead of arbitrary black box code, the encapsulation would be of a sub-model solved using the [[QRSlv]] solver (in this case -- as specified).

The <tt>GREY</tt> statement would simply be an specialisation of the proposed <tt>LINK</tt> statement.

[[Category:Proposed]]