IS REFINED TO: Difference between revisions
Restored page from Google Cache, uploaded by John Pye |
No edit summary |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{DISPLAYTITLE:IS_REFINED_TO}} | |||
The '''IS_REFINED_TO''' statement is used to apply refinements to an already-declared variable or sub-model. | The '''IS_REFINED_TO''' statement is used to apply refinements to an already-declared variable or sub-model. | ||
| Line 5: | Line 6: | ||
In other words, one or more variables followed by the IS_REFINED_TO keyword, followed by a type that is a refinement (see [[REFINES]]) of the type of the variables listed. If the refined type ('typename') is a [[Parametric type]], then arguments are required following the typename. | In other words, one or more variables followed by the IS_REFINED_TO keyword, followed by a type that is a refinement (see [[REFINES]]) of the type of the variables listed. If the refined type ('typename') is a [[Parametric type]], then arguments are required following the typename. | ||
We use this statement to change the type of each of the instances listed to the | We use this statement to change the type of each of the instances listed to the type type_name. The modeler has to have defined each member on the list of instances. The type_name has to be a type which refines the types of all the instances on the list. | ||
type type_name. The modeler has to have defined each member on the list of | |||
instances. The type_name has to be a type which refines the types of all the | An example of its use is as follows. First we define the parts called fl1, fl2 and fl3 which are of type flash. | ||
instances on the list. | |||
<source lang="a4c">fl1, fl2, fl3 IS_A flash;</source> | <source lang="a4c">fl1, fl2, fl3 IS_A flash;</source> | ||
Assume that there exists in the previously defined model definitions the type | |||
adiabatic_flash that is a refinement of flash. Then we can make fl1 and fl3 | Assume that there exists in the previously defined model definitions the type adiabatic_flash that is a refinement of flash. Then we can make fl1 and fl3 into more refined types by stating: | ||
into more refined types by stating: | |||
<source lang="a4c">fl1, fl3 IS_REFINED_TO adiabatic_flash;</source> | <source lang="a4c">fl1, fl3 IS_REFINED_TO adiabatic_flash;</source> | ||
This reconstruction does not occur until the arguments to the type satisfy the | This reconstruction does not occur until the arguments to the type satisfy the definition type_name. | ||
definition type_name. | |||
Using IS_REFINED_TO for example allows an array of similar objects to be declared: | Using IS_REFINED_TO for example allows an array of similar objects to be declared: | ||
<source lang="a4c">a[1..4] IS_A steam_equipment; | <source lang="a4c">a[1..4] IS_A steam_equipment; | ||
a[1] IS_REFINED_TO pump; | a[1] IS_REFINED_TO pump; | ||
a[2,3] IS_REFINED_TO pipe; | a[2,3] IS_REFINED_TO pipe; | ||
a[4] IS_REFINED_TO turbine;</source> | a[4] IS_REFINED_TO turbine;</source> | ||
| Line 33: | Line 27: | ||
It also allows looping constructs to be used to set up parametric models where the parameters are not identical for all members of the array. | It also allows looping constructs to be used to set up parametric models where the parameters are not identical for all members of the array. | ||
See also [[SELECT]]. | See also [[SELECT]], [[FOR]]. | ||
[[Category:Syntax]] | |||
[[Category:Documentation]] | [[Category:Documentation]] | ||
Latest revision as of 02:36, 17 November 2013
The IS_REFINED_TO statement is used to apply refinements to an already-declared variable or sub-model.
var [,var[,var...]] IS_REFINED_TO typename[(arg[,arg...])]
In other words, one or more variables followed by the IS_REFINED_TO keyword, followed by a type that is a refinement (see REFINES) of the type of the variables listed. If the refined type ('typename') is a Parametric type, then arguments are required following the typename.
We use this statement to change the type of each of the instances listed to the type type_name. The modeler has to have defined each member on the list of instances. The type_name has to be a type which refines the types of all the instances on the list.
An example of its use is as follows. First we define the parts called fl1, fl2 and fl3 which are of type flash.
fl1, fl2, fl3 IS_A flash;
Assume that there exists in the previously defined model definitions the type adiabatic_flash that is a refinement of flash. Then we can make fl1 and fl3 into more refined types by stating:
fl1, fl3 IS_REFINED_TO adiabatic_flash;
This reconstruction does not occur until the arguments to the type satisfy the definition type_name.
Using IS_REFINED_TO for example allows an array of similar objects to be declared:
a[1..4] IS_A steam_equipment; a[1] IS_REFINED_TO pump; a[2,3] IS_REFINED_TO pipe; a[4] IS_REFINED_TO turbine;
It also allows looping constructs to be used to set up parametric models where the parameters are not identical for all members of the array.