Object-oriented modelling - Revision history

Jpye at 23:53, 13 December 2010

2010-12-13T23:53:13Z

← Older revision		Revision as of 23:53, 13 December 2010
Line 1:		Line 1:
	~~<div class="notice metadata" id="~~stub~~">''This article is a '''stub'''. You can help out by <span class="plainlinks">[http://ascendwiki.cheme.cmu.edu/index.php?title=Object-oriented_modelling&action=edit expanding it]</span>. ''</div>~~		{{stub}}
	This page overviews the object-oriented capabilities of ASCEND.		This page overviews the object-oriented capabilities of ASCEND.


	== <tt>MODEL</tt>s built from <tt>MODEL</tt>s ==		== <tt>MODEL</tt>s built from <tt>MODEL</tt>s ==
Line 50:		Line 49:

	Here, both new variables and new relations were added. Note that it is possible only to add new relations; relations in base models can not be removed in refinements of the base model (although using the <tt>included</tt> property of a relations, one can gain something like that ability).		Here, both new variables and new relations were added. Note that it is possible only to add new relations; relations in base models can not be removed in refinements of the base model (although using the <tt>included</tt> property of a relations, one can gain something like that ability).


	== Parameterised models ==		== Parameterised models ==
Line 98:		Line 96:

	<source lang="a4c">MODEL flow_meter REFINES flow_equipment;		<source lang="a4c">MODEL flow_meter REFINES flow_equipment;

	....;		....;
	END flow_meter;</source>		END flow_meter;</source>
Line 106:		Line 103:
	ASCEND model instances are dynamically typed. While using a compiled model instance, and using the Tcl/Tk GUI for ASCEND, any instance part can be interactively merged with another compatible part or refined to a derived type to debug the model. This allows interactive exploration of the mathematics without requiring a rewrite of the input files at every step. This practice is not universally endorsed, but the Script logging capability guarantees that all such changes can be captured by the careful modeler and the final set reintegrated in the model source files.		ASCEND model instances are dynamically typed. While using a compiled model instance, and using the Tcl/Tk GUI for ASCEND, any instance part can be interactively merged with another compatible part or refined to a derived type to debug the model. This allows interactive exploration of the mathematics without requiring a rewrite of the input files at every step. This practice is not universally endorsed, but the Script logging capability guarantees that all such changes can be captured by the careful modeler and the final set reintegrated in the model source files.




	~~[[Category:Stubs]]~~
	[[Category:Documentation]]		[[Category:Documentation]]
	[[Category:Syntax]]		[[Category:Syntax]]

Jpye: /* Parameterised models */

2010-07-31T09:38:42Z

Parameterised models

← Older revision		Revision as of 09:38, 31 July 2010
Line 76:		Line 76:
	Further refinement of parametric models is possible using a [[WHERE]] clause following the [[REFINES]] clause.		Further refinement of parametric models is possible using a [[WHERE]] clause following the [[REFINES]] clause.

			For more information, see [[Parameterised models]].

	== Refinements after declaration ==		== Refinements after declaration ==

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

2010-05-13T14:04:04Z

Restored page from Google Cache, uploaded by John Pye

New page

<div class="notice metadata" id="stub">''This article is a '''stub'''. You can help out by <span class="plainlinks">[http://ascendwiki.cheme.cmu.edu/index.php?title=Object-oriented_modelling&action=edit expanding it]</span>. ''</div>
This page overviews the object-oriented capabilities of ASCEND.

== <tt>MODEL</tt>s built from <tt>MODEL</tt>s ==
The simplest object-oriented capability of ASCEND is to create models as aggregates of smaller models:

<source lang="a4c">MODEL tank;
V IS_A volume;
rho IS_A density;

mdot IS_A mass_rate;
Vdot IS_A volume_rate;
Vdot = mdot * rho;

END tank;

MODEL pipe;
mdot IS_A mass_rate;

rho IS_A density;
END pipe;

MODEL tank_and_pipe;

T IS_A tank;
P IS_A pipe;
T.rho, P.rho ARE_THE_SAME;

P.mdot, T.mdot ARE_THE_SAME;
END tank_and_pipe;</source>

== Model refinement ==

As well as aggregating models to producing models from smaller parts, one can refine a model of one type to make something more specialised, using the [[REFINES]] keyword.:

<source lang="a4c">MODEL vessel REFINES tank;

p IS_A pressure;
R IS_A gas_constant;
n IS_A factor;

T IS_A temperature;
p*V = n * R * T;

T_amb IS_A temperature;
T = T_amb + 20 {K};

END vessel;</source>

Here, both new variables and new relations were added. Note that it is possible only to add new relations; relations in base models can not be removed in refinements of the base model (although using the <tt>included</tt> property of a relations, one can gain something like that ability).

== Parameterised models ==

Models can be set up so that they require certain externally-defined parameters at the time when they are instantiated. For example:

<source lang="a4c">MODEL pump(
in WILL_BE pressurepipe;
out WILL_BE pressurepipe;

);
dp IS_A pressure;
out.p = in.p + dp;

END pump;

MODEL pumped_thing;
L1, L2 IS_A pressurepipe;

P IS_A pump(L1,L2);
END pumped_thing;</source>

These models show that for parameterised (ie parametric) models, you must first declare the sub-models using <tt>IS_A</tt> declarations, then you can place them into your parameterised declaration as <tt>pump(L1,L2)</tt>, which is the name of the ''type'' of model, followed by the specific ''instances'' of the parameters you want.

Further refinement of parametric models is possible using a [[WHERE]] clause following the [[REFINES]] clause.

== Refinements after declaration ==

The <tt>IS_REFINED_TO</tt> declaration allows one to start off by declaring a part to be a base-type and then refine that part to be a more specialised type with a subsequent call. This allows for example arrays of hetergeneous objects to be created.

<source lang="a4c">MODEL flow_sequence;

E[1..3] IS_A flow_equipment;
E[1].out, E[2].in ARE_THE_SAME;

E[2].out, E[3].in ARE_THE_SAME;
E[2] IS_REFINED_TO flow_meter;

E[1] IS_REFINED_TO flow_pump;
E[3] IS_REFINED_TO flow_tank;

END flow_sequence;</source>

The more specialised types (here flow_meter, flow_pump and flow_tank) must be refinements of flow_equipment - e.g.,

<source lang="a4c">MODEL flow_meter REFINES flow_equipment;

....;
END flow_meter;</source>

== Refinements and merges after instantiation ==

ASCEND model instances are dynamically typed. While using a compiled model instance, and using the Tcl/Tk GUI for ASCEND, any instance part can be interactively merged with another compatible part or refined to a derived type to debug the model. This allows interactive exploration of the mathematics without requiring a rewrite of the input files at every step. This practice is not universally endorsed, but the Script logging capability guarantees that all such changes can be captured by the careful modeler and the final set reintegrated in the model source files.

[[Category:Stubs]]
[[Category:Documentation]]
[[Category:Syntax]]