Express-I:
The location attributes are inherited from meta type location. The example will specify both a real property and a string property.
attribute --> POINT {
coordinate_system (M) --> @InstanceId;
vertex --> @InstanceId;
coordinates (M) --> LIST( RealValue, ... );
ref_unit_of_measure (M) --> LIST( @InstanceId, ... ); };
property (M)--> SET (@prop1, @prop2, ... );
prop1 = POINT_PROPERTY_REAL {
ref_property_kind (M) --> @InstanceId;
coord_sys_axis --> @InstanceId;
ref_unit_of_measure (M) --> @InstanceId;
real_value (M) --> RealValue; };
prop2 = POINT_PROPERTY_STRING {
ref_property_kind (M) --> @InstanceId;
string_value (M) --> StringValue; };
... };
Interface:
The following C structures are used to pass values of points between the facility and the application. The structure used depends on the significance of the coordinates.
typedef struct daePointVRealStructure
{
daeLocationQuantityReal location;
daeInteger propertyCount;
daePointPropertyReal *properties;
} daePointVReal;
typedef struct daePointVDoubleStructure
{
daeLocationQuantityDouble location;
daeInteger propertyCount;
daePointPropertyDouble *properties;
} daePointVDouble;
typedef struct daePointVAnyStructure
{
daeLocationReal location;
daeInteger propertyCount;
daePointPropertyAny *properties;
} daePointVAny;
typedef struct daePointPropertyRealStructure
{
daeInstance refProperty;
daeAcronym unitOfMeasure;
daeInstance coordinateAxis;
daeReal value;
} daePointPropertyReal;
typedef struct daePointPropertyDoubleStructure
{
daeInstance refProperty;
daeAcronym unitOfMeasure;
daeInstance coordinateAxis;
daeDouble value;
} daePointPropertyDouble;
typedef struct daePointPropertyAnyStructure
{
daeInstance refProperty;
daeAcronym unitOfMeasure;
daeInstance coordinateAxis;
daeAtype dataType;
daePointer valueAddress;
} daePointPropertyAny;
The daePointV... structure describes a point by the coordinate values of a location in a coordinate system together with zero or more property values. The propertyCount member specifies the number of properties. Each property is contained in a daePointProperty... structure.
The daePointProperty... structure specifies the value of a property associated with a point. The refProperty member is the instance of Ref_property_kind for the property and unitOfMeasure is the acronym attribute of the instance of Ref_unit_of_measure specifying the property units. The coordinateAxis member may be specified to be NULL or an instance of Coordinate_system_axis along which the property is measured.
F.4.7 DATE
A date value is a calendar date, specifying a year, month, and day of month. This is intended to conform to the SQL92 specification for DATE (see DATE in Section 9, "Language" ).
Specification:
- Syntax: DATE
Content:
A date value must be suitable to represent a date in the Gregorian calendar. The value is expected to be able to represent modern dates. It need not be able to represent geological times.
META_TYPE date;
year : INTEGER;
month : INTEGER;
day : INTEGER;
WHERE
year_valid : { 1 <= year <= 9999 };
month_valid : { 1 <= month <= 12 } ;
day_valid: ( ( month IN [1,3,5,7,8,10,12] ) AND { 1 <= day <= 31 } ) XOR
( ( ( month IN [4,6,9,11] ) AND { 1 <= day <= 30 } ) XOR
( ( month = 2 ) AND
((((((year mod 4) = 0) AND ((year mod 100) <> 100)) OR
((year mod 400) = 0)) AND { 1 <= day <= 29 }) OR
{ 1 <= day <= 28 } )));
END_META_TYPE;
Express-I:
attribute --> DATE { -- yyyy-mmm-dd
year --> IntegerValue;
month --> IntegerValue;
day --> IntegerValue; };
Ex: start_date --> DATE { --1996-June-18
Ex: year --> 1996;
Ex: month --> 6;
Ex: day --> 18; };
Interface:
The primary interface to a date is through a structure which separates the year, month, and day.
typedef struct daeDateStructure
{
daeShort year;
daeShort month;
daeShort day;
} daeDate, *daeDatePtr;
A date may alternatively be cast as a timestamp, or into a standard C "tm" structure, which is presented as the C data type daeTime. When a value is retrieved in these extended structures, the time values and UCT offset will be zero. When updated, the time values and UCT offset will be ignored.
F.4.8 TIME
A time value is a clock time in Universal Coordinated Time (UCT), where the clock time gives hour within day, minutes within hour, and seconds within minute. This is intended to conform to the SQL92 specification for TIME (see "TIME" in Section 9, "Language" ).
Specification:
- Syntax: TIME `(' precision_spec `)'
- precision_spec = required minimum precision in fractional seconds, positive integer.
Content:
The value must represent the time within a day, to the precision specified. The SQL92 specification indicates that values are expected to be maintained in Universal Coordinated Time (UCT). This avoids ambiguity not only for which time zone the value is correct but also for the changes between standard and daylight savings times.
META_TYPE time;
hour : INTEGER;
minute : INTEGER;
second : REAL ( precision );
uct_offset : DAYTIMEINTERVAL;
EXTERNAL
precision : INTEGER;
WHERE
hour_valid : { 0 <= hour <= 23 };
minute_valid : { 0 <= minute <= 59 };
second_valid : { 0.0 <= second < 62.0 };
nonleap_second_valid: (second<60.0) OR ((hour=23) AND
(minute=59));
offset_valid : ( (uct_offset.days=0) AND
(uct_offset.seconds=0.0) AND
(uct_offset.hour >= -12) AND
(((uct_offset.hour=13) AND
(uct_offset.minute=0)) OR
(uct_offset.hour <= 12))) );
precision_valid : 0 < precision;
END_META_TYPE;
Where
- hour:
- Hour within day. Specified in the time zone at uct_offset
- minute:
- Minute within hour. Specified in the time zone at uct_offset
- second:
- Second within minute.
- uct_offset:
- Offset of the time zone from UCT. The offset is a value from negative 12:59 through positive 13:00.
Express-I:
attribute --> TIME { -- hh:mm:ss.sss (uct_offset)
hour (M) --> IntegerValue;
minute (M) --> IntegerValue;
second (M) --> RealValue;
uct_offset (M) --> DAYTIMEINTERVAL{
days (M) -- 0;
hours (M) --> IntegerValue;
minutes (M) --> IntegerValue;
seconds (M) --> 0; }; };
Ex: end_time --> TIME { -- 8:10 PM Houston time.
Ex: hour (M) --> 20;
Ex: minute (M) --> 10;
Ex: seconds (M) --> 0.0;
Ex: uct_offset (M) --> DAYTIMEINTERVAL {
Ex: days (M) --> 0;
Ex: hours (M) --> -6;
Ex: minutes (M) --> 0;
Ex: seconds (M) --> 0; }; };
Interface:
Two structures are available for passing clock time: one casts the seconds to single precision real, the other casts the seconds to double precision.
typedef struct daeTimeRealStructure
{
daeShort hour;
daeShort minutes;
daeReal seconds;
daeBoolean uctOffsetFlag;
daeDayTimeIntervalReal uctOffset;
} daeTimeReal;
typedef struct daeTimeDoubleStructure
{
daeShort hour;
daeShort minutes;
daeDouble seconds;
daeBoolean uctOffsetFlag;
daeDayTimeIntervalReal uctOffset;
} daeTimeDouble;
The uctOffset member is a day-time interval specifying the difference between UCT and the specified time. When this structure is passed as an input argument uctOffsetFlag may be set to TRUE to indicate that uctOffset is specified. uctOffset is a hour to minute day-time interval with the permitted values of -12:59 through 13:00. If uctOffsetFlag is FALSE, then the offset from UCT of the local time zone for the session is implied and uctOffset is ignored. When this structure is returned as an output argument uctOffsetFlag is always set to TRUE and the returned time has a value for uctOffset which is the original UCT offset of the time.
F.4.9 TIMESTAMP
A calendar date and clock time in UCT. This is intended to conform to the SQL92 specification for TIMESTAMP (see "TIMESTAMP" in Section 9, "Language" ).
Specification:
- Syntax: TIMESTAMP `(' precision_spec `)'
- precision_spec = required minimum precision of fractional seconds, positive integer.
Content:
A value of TIMESTAMP consists of a calendar date and a clock time.
META_TYPE timestamp;
date : date;
time : time ( precision );
EXTERNAL
precision : INTEGER;
WHERE
precision_valid : 0 < precision;
nonleap_second_valid: (time.second<60.0) OR
(leap_year(date.year) AND (date.month=12) AND
(date.day=31) AND (time.hour=23) AND
(time.minute=59));
END_META_TYPE;
FUNCTION leap_year ( year : integer ) : BOOLEAN;
IF ((((year mod 4) = 0) AND
((year mod 100) <> 100)) OR
((year mod 400) = 0)) THEN
RETURN (TRUE);
END_IF;
RETURN (FALSE);
END_FUNCTION;
Express-I:
attribute --> TIMESTAMP {
DATE {
attributes for date };
TIME {
attributes for time };
Ex: end_time --> TIMESTAMP { -- 1990-Dec-21 12 noon UCT;
Ex: date (M) --> DATE {
Ex: year (M) --> 1990;
Ex: month (M) --> 12;
Ex: day (M) --> 21; };
Ex: time (M) = TIME {
Ex: hour (M) --> 12;
Ex: minute (M) --> 0;
Ex: second (M) --> 0.0;
Ex: uct_offset (M) --> DAYTIMEINTERVAL {
Ex: days (M) --> 0;
Ex: hours (M) --> 0;
Ex: minutes (M) --> 0;
Ex: seconds (M) --> 0; }; }; };
Interface:
A timestamp may be cast to a structure combining date and time:
typedef struct daeTimeStampRealStructure
{
daeDate date;
daeTimeReal time;
} daeTimeStampReal;
typedef struct daeTimeStampDoubleStructure
{
daeDate date;
daeTimeDouble time;
} daeTimeStampDouble;
or may be cast to the C "tm" structure:
typedef struct daeTimeStructure /
{
int tm_sec; /* seconds (0-62)(allows leap-seconds)*/
int tm_min; /* minutes (0-59) */
int tm_hour; /* hours (0-23) */
int tm_mday; /* day of month (1-31) */
int tm_mon; /* month of year (0-11) */
int tm_year; /* years since 1900 */
int tm_wday; /* days since Sunday (0-6) */
int tm_yday; /* days since January 1 (0-365) */
int tm_isdst; /* not used */
} daeTime, *daeTimePtr;
The tm_isdst value in this structure are not used; time is assumed to be in UCT.
F.4.10 YEARMONTHINTERVAL
A year-month-interval is an interval between two dates, given in years and months. The maximum range is +/- 99999 years. This is intended to conform to the SQL92 specification of year-month intervals (see "YEARMONTHINTERVAL" in Section 9, "Language" ).
Specification:
- Syntax: YEARMONTHINTERVAL
Content:
The value must represent a time interval expressed in years and whole months, and it must be able to store the required range of values.
META_TYPE yearmonthinterval;
years : INTEGER;
months : INTEGER;
WHERE
year_valid : { 0 <= ABS(years) <= 9999 };
month_valid : { 0 <= ABS(months) <= 11 };
sign_valid : (( 0 <= years ) AND ( 0 <= months )) XOR
(( 0 >= years ) AND ( 0 >= months ));
END_META_TYPE;
Express-I:
attribute --> YEARMONTHINTERVAL {
years --> IntegerValue;
months --> IntegerValue; };
Ex: interval --> YEARMONTHINTERVAL { -- positive 2 months.
Ex: years --> 0;
Ex: months --> 2; };
Ex: interval --> YEARMONTHINTERVAL { -- negative 2 years 7 months.
Ex: years --> -2;
Ex: months --> -7; };
Interface:
The value may be cast into a structure that represents years and months. Non-zero members of the structure must be all positive or all negative.
Years will be signed, except when years is zero. Non-zero members of the structure must be all positive or all negative.
typedef struct daeYearMonthIntervalStructure
{
daeInteger years;
daeShort months;
} daeYearMonthInterval;
A year month interval may be cast as if it were a quantity value of quantity type `time', but with some possible loss of precision. The length of each year shall be the same and the length of each month shall be one twelfth the length of a year. The casting algorithm shall take into account that the value can retain only whole months and round to the nearest month.
F.4.11 DAYTIMEINTERVAL
A day-time-interval is a time interval measured using certain combinations of days, hours, minutes, and seconds. The maximum size is +/- 99999 days. This is intended to conform to the SQL92 specification for day-time intervals (see"DAYTIMEINTERVAL" in Section 9, "Language" ).
Specification:
- Syntax: DAYTIMEINTERVAL`(' precision_spec `)'
- precision_spec = required minimum precision in fractional seconds, positive integer.
Content:
The value must be able to hold a time interval of up to 99999 days to the precision specified for seconds. For example, a double precision floating point number can support a daytime interval with 4 significant figures for seconds.
META_TYPE daytimeinterval;
days : INTEGER;
hours : INTEGER;
minutes : INTEGER;
seconds : REAL ( precision );
EXTERNAL
precision : INTEGER;
WHERE
day_valid : { 0 <= ABS(day) <= 99999 };
hour_valid : { 0 <= ABS(hour) <= 23 };
minute_valid : { 0 <= ABS(minute) <= 59 };
second_valid : { 0.0 <= ABS(second) < 60 };
precision_valid : 0 < precision;
sign_valid : (( 0 <= day ) AND ( 0 <= hour ) AND
( 0 <= minute ) AND ( 0 <= second )) XOR
(( 0 >= day ) AND ( 0 >= hour ) AND
( 0 >= minute ) AND ( 0 >= second ));
END_META_TYPE;
Express-I:
attribute --> DAYTIMEINTERVAL {
days (M) -- IntegerValue;
hours (M) --> IntegerValue;
minutes (M) --> IntegerValue;
seconds (M) --> RealValue; };
Ex: interval --> DAYTIMEINTERVAL {
Ex: days (M) --> 12;
Ex: hours (M) --> 4;
Ex: minutes (M) --> 16;
Ex: seconds (M) --> 12.11; };
Interface:
A value of type DAYTIMEINTERVAL can be cast as if it is a quantity value of quantity type `time'. The units defaults applying to `time' also apply to a DAYTIMEINTERVAL value.
In addition it may be cast into a structure which represents the seconds as a single or double precision floating point number.
typedef struct daeDayTimeIntervalRealStructure
{
daeInteger days;
daeShort hours;
daeShort minutes;
daeReal seconds;
} daeDayTimeIntervalReal;
typedef struct daeDayTimeIntervalDoubleStructure
{
daeInteger days;
daeShort hours;
daeShort minutes;
daeDouble seconds;
} daeDayTimeIntervalDouble;
Non-zero members of the structure must be all positive or all negative.
F.4.12 QUANTITY
A quantity value consists of a real number and a unit of measure, qualifying the real number. Each quantity attribute is specified with a quantity_type. Each quantity_type has a set of alternative units of measure defined. These constrain the choice of unit of measure to one of the set.
Specification:
- Syntax: QUANTITY `(' quantity_type `,' precision_spec `)'
- quantity_type = the name attribute of Ref_quantity_type, a variable string with maximum length of 40.
- precision_spec = required minimum number of significant figures, positive integer.
- Notes:
- The specification of the units sets is done by instances of Ref_quantity_type within the
Epicentrereference schema . - The control parameter quantity_type refers to the name attribute value of the entity Ref_quantity_type instance to use
- The Ref_quantity_type instance specifies one or more units of measure, one of which is used for a value instance of the data type.
- The Ref_quantity_type instance specifies a value range which constrains all instances of the type instance. The range limits are specified in a unit and are applied to account for the selected unit of the quantity type instance.
Content:
The content must reproduce the value, with at least the minimum precision specified, and with a unit of measure.
The Epicentre data model specifies the permitted units of measure for each quantity type [diagram MTP: Reference Properties] and the conversions between different units of measure [diagram MTU: Reference Unit of Measure].
META_TYPE quantity;
real_value : REAL ( precision );
ref_unit_of_measure : ref_unit_of_measure;
EXTERNAL
quantity_type_name : STRING(40);
precision : INTEGER;
WHERE
precision_valid : 0 < precision;
units_valid : SIZEOF ( QUERY ( tmp <* USEDIN ( ref_unit_of_measure,
'REF_QUANTITY_TYPE.ALTERNATIVE_UNIT_OF_MEASURE') |
tmp.name = quantity_type_name ) ) = 1;
END_META_TYPE;
Express-I:
attribute --> QUANTITY { -- name of ndt is recommended
real_value (M) --> RealValue;
ref_unit_of_measure (M) --> @InstanceId; };
Ex: pipe_length --> QUANTITY { -- ndt_length_midrange
Ex: real_value (M) --> 30.016;
Ex: ref_unit_of_measure (M) --> @PRV_ft; };
Interface:
For each session, there are three modes of accessing quantities with units. First, DEFAULT_UNITS, in which all quantity values are converted from stored units to the default units on retrieval and converted from default units to stored units on input. Second, NO_DEFAULT_UNITS, in which all quantity values are retrieved in stored units and input with explicitly specified units which are converted to stored units. And third, REPORTED_UNITS, in which all quantity values are retrieved in stored units and are stored in their explicitly specified units with no units conversion taking place.
For passing a value with units, there are two structures defined: one for single precision and one for double precision values.
typedef struct daeQuantityRealStructure
{
daeReal quantity;
daeAcronym unit;
} daeQuantityReal;
typedef struct daeQuantityDoubleStructure
{
daeDouble quantity;
daeAcronym unit;
} daeQuantityDouble;
When working with default units, a quantity data type may also be passed as a float or double C value.
F.4.13 ANYQUANTITY
A value of type anyquantity can hold the value of any physical quantity. The value consists of the quantity type, a real number, and a unit of measure qualifying the real number. After a quantity type has been defined, the value may be treated like a value of type quantity.
Specification:
- Syntax: ANYQUANTITY `(' precision_spec `)'
- precision_spec = required minimum number of significant figures, positive integer.
Content:
The content must include a reference to Ref_quantity_type as well as any content required to represent a value of type quantity.
META_TYPE anyquantity_value;
real_value : REAL ( precision );
ref_unit_of_measure : ref_unit_of_measure;
ref_quantity_type : ref_quantity_type;
EXTERNAL
precision : INTEGER;
WHERE
precision_valid : 0 < precision;
units_valid : ref_unit_of_measure IN ref_quantity_type.alternative_unit_of_measure;
END_META_TYPE;
Express-I:
attribute --> ANYQUANTITY {
real_value (M) --> RealValue;
ref_unit_of_measure (M) --> @InstanceId;
ref_quantity_type (M) --> @InstanceId; };
Ex: value --> ANYQUANTITY {
Ex: real_value (M) --> 16.11729554;
Ex: ref_unit_of_measure (M) --> @PRV_dega;
Ex: ref_quantity_type (M) --> @PRV_plane_angle; };
Interface:
For setting the value there are three structures defined: one for single and one for double precision and one for integer.
typedef struct daeQuantityRealStructure
{
daeReal quantity;
daeAcronym unit;
daeName quantity_type;
} daeAnyQuantityReal;
typedef struct daeAnyQuantityDoubleStructure
{
daeDouble quantity;
daeAcronym unit;
daeName quantity_type;
} daeAnyQuantityDouble;
typedef struct daeAnyQuantityIntegerStructure
{
daeInteger quantity;
daeAcronym unit;
daeName quantity_type;
} daeAnyQuantityInteger;
After an attribute value is assigned a quantity name, any of the casts permitted for a quantity type are allowed.
F.4.14 ANGLE
An angle value is a quantity value with quantity type that represents a plane angle and has a permitted unit of degrees. It may be used as if it were a quantity or it may be passed in a structure containing degrees, minutes, and seconds.
Specification:
- Syntax: ANGLE `(' quantity_type`,' precision_spec `)'
- quantity_type = the name attribute of Ref_quantity_type, a variable string with maximum length of 40.
- precision_spec = required minimum number of significant figures, positive integer.
- Notes:
- The specification of the units set is done by instances of Ref_quantity_type within the Epicentre reference schema.
- The control parameter quantity_type refers to the name attribute value of the entity Ref_quantity_type instance to use.
- The Ref_quantity_type instance specifies one or more units of measure suitable for angles, one of which is used for a value instance of the data type.
- The Ref_quantity_type instance specifies a value range which constrains all instances of the type instance. The range limits are specified in a unit and are applied to account for the selected unit of the quantity type instance.
- The valid representations are: a real number with any one unit specified by quantity_type and an integer number of degrees, an integer number of minutes within degrees, and a real number of seconds within a minute.
Content:
An angle is specified as degrees, minutes within a degree (0 to 59) and seconds within a minute (0 to less than 60).
META_TYPE angle;
ABSTRACT SUPERTYPE OF ( ONEOF(angle_quantity, angle_dms) );
END_META_TYPE;
META_TYPE angle_quantity;
SUBTYPE OF (angle, quantity);
END_META_TYPE;
META_TYPE angle_dms;
SUBTYPE OF (angle, quantity);
degrees : INTEGER;
minutes : INTEGER;
seconds : REAL ( precision-6 );
EXTERNAL
quantity_type_name : STRING(40);
precision : INTEGER;
WHERE
minute_valid : { 0 <= ABS(minutes) <= 59 };
second_valid : { 0 <= ABS(seconds) < 60 };
precision_valid : 0 < precision;
sign_valid : (( 0 <= degrees ) AND ( 0 <= minutes ) AND
( 0 <= seconds ) XOR (( 0 >= degrees ) AND
( 0 >= minutes ) AND ( 0 >= seconds ));
END_META_TYPE;
Express-I:
attribute --> ANGLE_DMS {
degrees (M) --> IntegerValue;
minutes (M) --> IntegerValue;
seconds (M) --> RealValue; };
or
attribute --> ANGLE_QUANTITY {
real_value (M) --> RealValue;
ref_unit_of_measure (M) --> @InstanceId; };
Ex: longitude --> ANGLE_DMS { -- 96:12:15.23 West
Ex: degrees (M) --> -96;
Ex: minutes (M) --> -12;
Ex: seconds (M) --> -15.23; };
or
Ex: longitude --> ANGLE_QUANTITY { -- ndt_earth_angle
Ex: real_value (M) --> -96.20423056;
Ex: ref_unit_of_measure (M) --> @PRV_dega; };
Interface:
A value of type ANGLE can be cast as if it is a quantity value of a quantity type that represents a plane angle. The units defaults that apply to `plane angle' also apply to an ANGLE value.
In addition, an angle may be cast into a structure representing the seconds as a single or double precision floating point number.
typedef struct daeDMSRealStructure
{
daeShort degrees;
daeShort minutes;
daeReal seconds;
} daeDMSReal;
typedef struct daeDMSDoubleStructure
{
daeShort degrees;
daeShort minutes;
daeDouble seconds;
} daeDMSDouble;
Non-zero members of the structure must be all positive or all negative.
F.4.15 LINE
A continuous line described in a specific coordinate system. One representation is given consisting of a 1D grid of points where the grid may be indexed using an axis of the coordinate system, or it may be parametrically indexed. The points are measured with respect to a specified reference vertex or with respect to the origin of the coordinate system. This is illustrated in Figure F-1.
Specification:
The value instance of line consists of a reference to an instance of the entity Grid_1d, which contains the grid index values, the remaining set of grid point coordinates for the specified coordinate system, and the units of measure of the coordinate values for each coordinate system axis.
Properties may be attached to the nodes and edges of the line grid using the data type ELEMENT. The line data type is declared as follows:
- Syntax: LINE `(' [ type ] `,' [ constraint] `,' coord_precision_spec `)'
- type = `grid'
- constraint = the name attribute of Ref_coordinate_system_constraint, a variable string with maximum length of 40.
- coord_precision_spec = the minimum necessary number of significant figures for the coordinate values, positive integer.
- Notes:
- The control parameter constraint refers to the name attribute value of an instance of Ref_coordinate_system_constraint.
- The Ref_coordinate_system_constraint instance defines the number of axes the coordinate system of the line instance must have and the set of alternative property types that can be used to specify each axis of the coordinate system.
- The units of the coordinate values are restricted to one of the alternative units of measure specified by the selected coordinate system axis.
- If constraint is unspecified, then any Coordinate_system instance can be chosen.
Content:
The only representation of a line is as the geometry on a 1D grid, implemented in a geometry frame as described in this Data Access and Exchange specification.
The content of a value of line data type is that it is a geometry frame with the following additional rules:
- A line value is a geometry frame of type FT_LINE, FT_SLINE, FT_CLOSED_LINE or FT_SCLOSED_LINE with one grid dimension (I).
- The grid of the geometry frame must be a subtype Grid_1d.
See also Appendix F.5, "Content Model for Frames" .
Express-I:
For a non-sparse representation. The dimension is described by a descriptor. The detailed_type of `FT_CLOSED_LINE' means that the last point will be connected to the first point.
attribute --> LINE_GRID {
gframe = GEOMETRY_FRAME {
detailed_type (M) --> `FT_LINE'; -- or `FT_CLOSED_LINE'
descriptor (M) --> LIST(@descr_1); (* There is only one
descriptor for a line (grid_1d) *)
leaf_frame (M) --> SET(@geom_leaf_1, ... ); (* There is a
leaf frame for every axis in the coordinate_system.
This may be (in general) one, two, or three. Only one
will be shown below. *)
grid_or_mesh (M) --> @InstanceId;
coordinate_system (M) --> @InstanceId;};
descr_1 = DESCRIPTOR {
dimension (M) --> `INDEX_I';
lower_bound (M) --> IntegerValue;
count (M) --> IntegerValue;};
geom_leaf_1 = LEAF_FRAME {
data_type (M) --> `DAE_C_...'; -- usually DAE_C_FLOAT.
ref_unit_of_measure --> @InstanceId;
coordinate_system_axis --> @InstanceId;
data_values --> LIST(array of count data values); }; };
For a sparse representation, a leaf is needed which will give the "array" of grid indexes.
attribute --> LINE_GRID {
gframe = GEOMETRY_FRAME {
detailed_type (M) --> `FT_SLINE'; -- or
`FT_SCLOSED_LINE'
descriptor (M) --> LIST(@descr_1);
leaf_frame (M) --> SET(@index_leaf, @geom_leaf_1, ...);
(* In addition, there is a leaf frame for every axis
in the coordinate_system. This may be (in general)
one, two, or three. Only one will be shown
below. *)
grid_or_mesh (M) --> @InstanceId;
coordinate_system --> @InstanceId;};
descr_1 = DESCRIPTOR{
dimension (M) --> `INDEX_UNDEFINED';
count (M) --> IntegerValue; };-- size of leaf arrays
index_leaf = LEAF_FRAME {
index_name --> `I';
data_type (M) --> `DAE_C_INT';
data_values --> LIST(array of "count" grid indexes); };
geom_leaf_1 = LEAF_FRAME {
data_type --> `DAE_C_...'; -- usually DAE_C_FLOAT.
ref_unit_of_measure --> @InstanceId;
coordinate_system_axis --> @InstanceId;
data_values --> LIST(array of "count" data values);}
... };
Interface:
A line value maps directly to a geometry frame of frame type FT_LINE, FT_SLINE, FT_CLOSED_LINE or FT_SCLOSED_LINE. The geometry frame retains the references to coordinate system and grid.
The geometry frame has one leaf array for each coordinate system axis. Where the coordinate values for a coordinate system axis are held in a grid axis, the corresponding leaf is not filled in. For sparse frames, one index leaf must be defined representing dimension I.
F.4.16 SURFACE
A continuous surface described in a specific coordinate system with positions measured with respect to a specified reference vertex or with respect to the origin of the coordinate system. Three types of surface representation have been defined:
- TRIANGULATED MESH
- GRID
- CONTOUR
The surface contains a value that is one of these three.
Specification:
All three representations share the same declaration syntax.
- Syntax: SURFACE`(' [ type ] `,' [ constraint ] `,' coord_precision_spec `)'
- type = `trimesh' | `grid' | `contour'
- constraint = the name attribute of Ref_coordinate_system_constraint, a variable string with maximum length of 40.
- coord_precision_spec = the minimum necessary number of significant figures for the coordinate values, positive integer.
- Notes:
- The control parameter constraint refers to the name attribute value of an instance of Ref_coordinate_system_constraint.
- The Ref_coordinate_system_constraint instance defines the number of axes the coordinate system of the surface instance must have and the set of alternative property types that can be used to specify each axis of the coordinate system.
- The units of the coordinate values are restricted to one of the alternative units of measure specified by the selected coordinate system axis.
- If constraint is unspecified, then any Coordinate_system instance can be chosen.
Content:
A surface value is either a surface mesh, a surface grid or a surface contour. The content is described as one of those three. See also Appendix F.5, "Content Model for Frames" .
Interface:
If type is not specified, it is not possible for an application to directly retrieve the value of an attribute of type surface. First, an application must retrieve the internal data type using a call to daeGetAttributeType. This call returns the internal data type (daeDtype), which distinguishes between the mesh, the grid, and the contour.
Triangulated Surface Mesh
This data type represents a surface as a set of interconnected triangles. Each triangle consists of three nodes and three edges. An edge may be shared by one or two triangles and be defined by two nodes. Any triangle can be reached from any other triangle by traversing their shared edges. The intent is illustrated in Figure F-2.
The type instance references an instance of the entity Grid_trimesh, which defines the number of nodes, edges, and triangles, and their connections using integer numbers to identify each mesh component. The type instance also references a coordinate system and contains the coordinate values of the mesh nodes evaluated in the selected units of the corresponding coordinate system axes.
Additional properties may be attached to the mesh nodes, edges and triangles using the ELEMENT types.
Content:
A surface mesh value consists of a property frame with the following constraints:
The content of a value of surface mesh data type is that it is a geometry frame with the following additional rules:
- A surface mesh value is a geometry frame of type FT_MESH with one dimension labeled INDEX_UNDEFINED. A position on this index represents a node on the mesh. The number of points on the frame dimension must equal the number of nodes in the mesh.
- The grid of the geometry frame must be a Grid_trimesh.
See also Appendix F.5, "Content Model for Frames" .
Interface:
A surface mesh value maps directly to a geometry frame of frame type FT_MESH. The geometry frame retains the reference to the coordinate system and grid instances.
The geometry frame has one leaf array for each coordinate system axis.
2D Grid Surface
This data type represents a surface using a two dimensional grid, consisting of nodes, edges and faces. The function of the grid is to uniquely describe every point of the surface. Each node is identified by two indices, i and j. Edges are defined between adjacent nodes, and faces are defined by four adjacent nodes. An edge may be shared by one or two faces and all faces can be reached from every other face by traversing the common edges. Additionally, the space of a face can be described by another 2D grid, otherwise known as local grid refinement. This is illustrated in Figure F-3.
The surface type instance references an instance of Grid_defined_grid and the selected coordinate system instance. Two of the coordinate system axes may be used to index the Grid_defined_grid. The remaining coordinate values of the nodes are contained by the surface type instance. All the coordinate values of a coordinate system axis have the same unit of measure, which is restricted by the Ref_quantity_property instance of the coordinate system axis.
Property values may be attached to some or all nodes, edges or faces of the grid using the ELEMENT data type.
Content:
A surface grid value consists of a geometry frame with the following constraints:
- A surface grid value is a geometry frame of type FT_SURFACE or FT_SSURFACE, with two dimensions (I and J).
- The grid of the geometry frame must be a Grid_defined_grid, with two axes defined.
See also Appendix F.5, "Content Model for Frames" .
Express-I:
There are two possibilities that allow for sparse or dense storage. This section will give only the case of `FT_SURFACE'. The variations for sparse will be given after this pattern.
attribute --> SURFACE_GRID {
gframe = GEOMETRY_FRAME {
detailed_type (M) --> `FT_SURFACE';
descriptor (M) --> LIST(@descr_1, @descr_2); (* There
are two descriptors -One for each grid axis *)
leaf_frame (M) --> SET(@leaf_1, ...); (* There is
one leaf for every axis in the coordinate_system.
This may be, in general, one, two, or three. Only
one will be shown below. *)
grid_or_mesh (M) --> @InstanceId;
coordinate_system (M) --> @InstanceId;};
descr_1 = DESCRIPTOR { -- parameters for the first grid index
dimension (M) --> `INDEX_I';
lower_bound (M) --> IntegerValue;
count (M) --> IntegerValue;};
descr_2 = DESCRIPTOR { (* parameters for the second grid index *)
dimension (M) --> `INDEX_J';
lower_bound (M) --> IntegerValue;
count (M) --> IntegerValue;};
leaf_1 = LEAF_FRAME {
data_type (M) --> `DAE_C_...'; -- usually DAE_C_FLOAT
ref_unit_of_measure (M) --> @InstanceId;
coordinate_system_axis (M) --> @InstanceId;
data_values (M) --> LIST(array of count_1 times
count_2 data values); }; };
For a sparse representation, the detailed_type will be FT_SSURFACE and there will be one DESCRIPTOR using `INDEX_UNDEFINED'. There will need to be two index leaf frames, one for each of the grid axes. These two index frames together will define the pair of gird indexes that place the value on the grid. See the Express-I sparse example for LINE.
Interface:
A surface grid value maps directly to a geometry frame of frame type FT_SURFACE or FT_SSURFACE. The geometry frame retains the coordinate system and grid instance.
The geometry frame visible in the interface has one leaf array for each coordinate system axis. For sparse frames, two index leaf must be defined representing dimensions I and J.
Contour Surface
This data type represents a surface as a set of contours, where each contour is an iso value line of a surface specified property located in a 2D space. The 2D space is specified by selecting two coordinate axes of a coordinate system which conforms to the Ref_coordinate_system_constraint specification of the type and the surface property is specified by selecting any instance of the entity Ref_property_kind.
Each contour line, describing the surface, contains the value of the line. It is either open or closed and is described by a sequence of 2D coordinate locations.
Content:
The contour value consists of a set of lines, one for each property value. The contour value representation is quite different than the other surface representations.
META_TYPE surface_contour;
isoline_set : isoline_set;
END_META_TYPE;
Express-I:
attribute --> SURFACE_CONTOUR {
isoline_set = @isoset; };
isoset = ISOLINE_SET {
identifier (M) --> `string value';
ref_property_kind (M) --> @InstanceId;
ref_unit_of_measure --> @InstanceId;
isoline <-- SET( @isoline1, ... ); };
isoline1 = ISOLINE {
identifier (M) --> 'StringValue';
isovalue (M) --> RealValue; (* Specifies the value
associated with the contour, for example the
elevation. *)
line_geometry (M) --> LINE {...}; (* A line geometry
frame (see LINE) that holds the array of coordinate values.
Note that the line geometry can specify that the contour
is open or closed. *)
isoline_set (M) --> @isoset; };
Interface:
Contours are represented as instances of the Epicentre entity Isoline_set which contains a reference to a property and a set of Isoline instances. Each Isoline instance contains an isovalue for the property and a LINE geometry frame holding positions of points along the line. Different isolines may have the same isovalue.
F.4.17 VOLUME
A continuous volume described in a specific coordinate system, with positions measured with respect to a specified reference vertex or with respect to the origin of the coordinate system.
The 3D grid can be regular 3D, irregular 3D, or unstructured 3D.
- Regular 3D Grids
The intention of the 3d Grid representation is illustrated in Figure F-4.
Property values may be attached to some or all nodes, edges, faces or cells of the grid using ELEMENT data type.
Specification:
- Syntax: VOLUME`(' [ type ] `,' [ constraint] `,' coord_precision_spec `)'
- type = `grid'
- constraint = the name attribute of Ref_coordinate_system_constraint, a variable string with maximum length of 40.
- coord_precision_spec = the minimum necessary number of significant figures for the ordinate values, positive integer.
- Notes:
- The control parameter constraint refers to the name attribute value of an instance of Ref_coordinate_system_constraint.
- The Ref_coordinate_system_constraint instance defines the number of axes that the Coordinate_system of the volume instance must have and the set of alternative property types that can be used to specify each axis of the coordinate system.
- - The units of the ordinate values are restricted to one of the alternative units of measure specified by the selected Coordinate_system_axis.
- If constraint is unspecified, any Coordinate_system instance can be chosen.
Content:
The structure, refinements, and missing cells are modeled within a Grid_defined_grid having 3 axes [see diagram MTG: Grids and Meshes]. When Grid_1d_equal and Grid_1d_unequal are used to describe a grid in a 3D coordinate system, the positions of the nodes may be defined by the information stored with the grid instance.
The content of a value of volume data type is that it is a geometry frame with the following additional rules:
- The frame type must be FT_VOLUME, FT_SVOLUME, FT_CORNER_POINT or FT_UNSTRUCTURED with three dimensions (I, J and K).
- The grid must be a Grid_defined_grid having 3 axes.
See also Appendix F.5, "Content Model for Frames" .
Express-I:
attribute --> VOLUME_GRID {
gframe = GEOMETRY_FRAME {
detailed_type (M) --> `FT_VOLUME';
descriptor (M) --> LIST(@descr_1, @descr_2, @descr_3);
(* There are three descriptors - One for each grid
axis *)
leaf_frame (M) --> SET(@leaf_1, ...); (* There is one
leaf for every axis in the coordinate_system. This may
be, in general, one, two, or three. Only one will be
shown below. *)
grid_or_mesh (M) --> @InstanceId;
coordinate_system (M) --> @InstanceId;};
descr_1 = DESCRIPTOR { (* parameters for the first grid index *)
dimension (M) --> `INDEX_I';
lower_bound (M) --> integer value;
count (M) --> integer value;};
(* descr_2 and descr_3 differ from descr_1 in that
they use `INDEX_J' and `INDEX_K' instead of
`INDEX_I' *)
leaf_1 = LEAF_FRAME {
data_type --> `DAE_C_...'; -- usually DAE_C_FLOAT
ref_unit_of_measure --> @InstanceId;
coordinate_system_axis --> @InstanceId;
data_values --> LIST(array of count_1 times count_2
times count_3 data values); }; };
For a sparse representation, there will be one DESCRIPTOR using `INDEX_UNDEFINED'. There will need to be three index leaf frames, one for each of the grid axes. These three index frames together will define the grid indexes that locate the value on the grid. See the Express-I sparse example for LINE.
Interface:
A volume grid value maps directly to a geometry frame of frame type FT_VOLUME, FT_SVOLUME, FT_CORNER_POINT, or FT_UNSTRUCTURED. The geometry frame holds the references to the coordinate system and grid instance.
The geometry frame visible in the interface has one leaf array for each coordinate system axis. For sparse frames, three index leaf frames must be defined representing dimensions I, J and K.
F.4.18 ELEMENT
This data type attaches property values to the elements of a Grid_or_mesh instance. The ELEMENT instance consists of an array of fixed or variable length values for a specified set of property types, where the array index corresponds to the node, edge, face, or cell indices of a specified Grid_or_mesh instance. The unit of measure used for each property type is also recorded.
One or more property types may be attached to a single grid element type. The element type and property types that can be specified in an instance are constrained by the declaration parameters.
Specification:
- Syntax: ELEMENT`(' [ grid_type ] `,' [ element_type ] `,' [property_set ] `,' precision_spec `)'
- grid_type = `trimesh' | `grid' | `grid1d' | `grid2d' | `grid3d' | `grid4d' | `grid5d' | `grid6d' | `grid7d' | `grid8d' | `grid9d' | `grid10d' | `grid11d' | `grid12d' | `grid13d' | `grid14d' | `grid15d' | `grid16d' |
- element_type = `node' | 'edge' | `face' | `cell'
- property_set = the name attribute of Ref_property_set, a variable string with maximum length of 40.
- precision_spec = the minimum necessary number of significant figures for the property values, positive integer.
- Notes:
- grid_type restricts the type of Grid_or_mesh instance that the instance specifies.
- element_type constrains the choice of grid or mesh element described by the property values. The instance selects only element type. If element_type is not specified any one of the element types is chosen.
- The control parameter property_set refers to the name attribute value of an instance of Ref_property_set.
- The Ref_property_set instance defines the set of candidate property types that can be used to describe the elements. More than one may be selected for an instance.
- The units of the property values are restricted to one of the alternative units of measure specified by the Ref_quantity_type of the selected Ref_property_type.
- If property_set is unspecified, then any of the available Ref_property_type instances can be chosen.
Data instances of ELEMENT can refer to the same Grid_or_mesh instance allowing the Grid_or_mesh to be reused to add additional properties.
Content:
A value of element type is a property frame with the following additional rules:
- The frame type must be consistent with the specification of the attribute in terms of the types of grid and element. It will have the dimensions shown in the table below.
- The frame will have one leaf node for each property held.
See also Appendix F.5, "Content Model for Frames" .
Express-I:
attribute --> ELEMENT {
pframe = PROPERTY_FRAME {
detailed_type (M) --> E..._...; -- such as EGRID_3DNODE
descriptor (M) --> LIST(@descr_1,...); (* There is a
descriptor for each grid axis. Only one will be
shown below *)
leaf_frame (M) --> SET(@leaf_1,...); (* There is a leaf
frame for each related property. In general, there is
only one leaf frame for a pty_....data_value. Only one
will be shown in the example below. *)
grid_or_mesh (M) --> @InstanceId;};
descr_1 = DESCRIPTOR { (* parameters for the first index of the grid *)
dimension (M) --> `INDEX_I';
lower_bound (M) --> IntegerValue;
count (M) --> IntegerValue;}; (* descr_2 and descr_3
(if needed) differ from descr_1 in that they use
`INDEX_J' and `INDEX_K' instead of `INDEX_I'. *)
leaf_1 = LEAF_FRAME {
ref_property_kind --> @InstanceId;
coordinate_system_axis --> @InstanceId;
data_type --> `DAE_C_...'; (* usually numeric such as
DAE_C_FLOAT but may be DAE_C_CHAR *)
ref_unit_of_measure --> @InstanceId;
data_values --> LIST(array of "count 1" times "count 2"
times "count 3" data values); }; };
For a sparse representation, the frame type will be a sparse variation such as SGRID_3DNODE and there will be one DESCRIPTOR using `INDEX_UNDEFINED'. There will need to be one index leaf frame for each of the grid axes. These index frames together will define the gird indexes that locate the value on the grid. See the EXPRESS-I sparse example for LINE.
Interface:
There is no special C structure for passing Elements back and forth between the application and the layer. None is needed because an element maps directly to a property frame having a grid. The property frame contains the reference to the grid, and one of the element types listed in the daeEtype data type. The element type determines the indexing system.
There will be one leaf frame for each property and, in the case of elements instantiated as sparse, one leaf frame for each dimension index.
F.4.19 SAMPLE
This data type contains repeat sample values of a specified set of property types or independent variables. Each sample has a sample index and a set of property values, where the property types apply to all indexed samples. No dependence between indexed samples is implied.
Specification:
The sample data type instance specifies the set of property types and the unit of measure used for each type.
- Syntax: SAMPLE `(' [property_set] `,' precision_spec `)'
- property_set = the name attribute of Ref_property_set, a variable string with maximum length of 40.
- precision_spec = the minimum necessary number of significant figures for the property values, positive integer.
- Notes:
- The control parameter property_set refers to the name attribute value of an instance of Ref_property_set.
- The Ref_property_set instance defines the set of candidate property types that can be used to describe the elements. More than one may be selected for an instance.
- The units of the property values are restricted to one of the alternative units of measure specified by the Ref_quantity_type of the selected Ref_property_type.
- If property_set is unspecified, then any of the available Ref_property_type instances can be chosen.
Content:
A value of the sample data type is a property frame with the following additional rules:
- The sample is a frame with a frame type of FT_SAMPLE and one dimension labeled INDEX_UNDEFINED.
- There is no grid defined for a sample.
- There is one leaf frame for each property carried by the sample. The leaf frame must identify the property by a reference to Ref_property_kind.
See also Appendix F.5, "Content Model for Frames" .
Express-I:
attribute --> SAMPLE{
pframe = PROPERTY_FRAME {
detailed_type (M) --> `FT_SAMPLE';
descriptor (M) --> LIST(@descr_1); (* There is only one
descriptor. *)
leaf_frame (M) --> SET(@leaf_1,...); }; (* There is a
leaf frame for each stored property. Only one
will be shown in the example below. *)
descr_1 = DESCRIPTOR { (* parameters for the first index of the grid *)
dimension (M) --> `INDEX_UNDEFINED';
count (M) --> IntegerValue;};
leaf_1 = LEAF_FRAME {
ref_property_kind --> @InstanceId;
coordinate_system_axis --> @InstanceId; (* if appropriate *)
data_type --> `DAE_C_...'; -- usually DAE_C_FLOAT
ref_unit_of_measure --> @InstanceId;
data_values --> LIST(array of count data value); }; };
...};
There is not a sparse alternative for sample.
Interface:
The sample value is presented as a property frame with the above content.
F.4.20 UNSTRUCTURED_3D_TOPOLOGY
A set of cells, nodes, faces, and edges, and a description of the relationships between them. This data type is needed to support 3D unstructured grids. Compared to grids which Epicentre supported in V1.0, unstructured 3D grids contain a vast amount of information describing the relationships between the cells, faces, edges and nodes of which they are comprised. The definition of the cells and their components and relationships could have been done by creating a set of entities which would fully describe the grids. However, because the data is voluminous and of interest mainly to application programs rather than casual browsers, POSC decided to embed this information in a data type. This requires no parameters, all of the information being integer based.
Within the context of the discussion on UNSTRUCTURED 3D TOPOLOGY, a node is defined as a point having a single set of coordinates within the agreed upon coordinate system.
UNSTRUCTURED 3D TOPOLOGY embodies the following concepts:
- Unstructured 3d topology consists of a set of cell definitions.
- A cell is described by a set of faces, and may be further described by a node center.
- A face is described by a list of edges, and may be further described by a node center and a list of adjacent faces.
- A face participates in one or more cells.
- An edge is described by a list of nodes, and participates in one or more faces.
- A node may participate in zero or more edges
- A node may describe the center of zero or one cell.
- A node may describe the center of zero or one face.
These concepts lead to a set of usage conventions:
- Cell adjacency is handled only via faces. "Cell adjacency" is not a strict topological concept and may be used when faces share only one point or are considered to be close for practical purposes.
- When cells share a face, the face is defined only once and listed as belonging to each cell. When two cells have overlapped faces, the overlapping section may be defined as a separate face, which participates in both cells, or the face adjacency list may be used.
- Although it is possible to define cells such that a given arbitrary area in the 3D volume is specified as being inside more than one cell, usage convention states that grids should not be refined in this way. The proper way to refine a cell or group of cells is by Grid_modification.
Specification:
- Syntax: UNSTRUCTURED_3D_TOPOLOGY`(' `)'
Content:
The UNSTRUCTURED_3D_TOPOLOGY value is represented as:
META_TYPE us3_geom;
ordinal : OPTIONAL INTEGER;
cell : SET [0:?] OF us3_cell;
END_META_TYPE;
META_TYPE us3_cell;
ordinal : OPTIONAL INTEGER;
center : OPTIONAL us3_node;
face : OPTIONAL SET [0:?] OF us3_face;
END_META_TYPE;
META_TYPE us3_face;
ordinal : OPTIONAL INTEGER;
adjacent_to : OPTIONAL SET [0:?] Of us3_face;
center : OPTIONAL us3_node;
edge : OPTIONAL SET [0:?] OF us3_edge;
INVERSE
cell : SET [1:?] OF us3_cell FOR face;
adjacent_from : SET {0,?] Of us3_face FOR adjacent_to;
END_META_TYPE;
META_TYPE us3_edge;
ordinal : OPTIONAL INTEGER;
node : OPTIONAL SET [0:?] OF us3_node;
INVERSE
face : SET [1:?] OF us3_face FOR edge;
END_META_TYPE;
META_TYPE us3_node;
ordinal : OPTIONAL INTEGER;
INVERSE
edge : SET [0:?] OF us3_edge FOR node;
center_of_cell : us3_cell FOR center;
center_of_face : us3_face FOR center;
END_META_TYPE;
Where
- ordinal:
- The ordinal number of the element. When properties are assigned to elements of the grid, the ordinal number should be used as the "i" index value in the index leaf. Properties can only be assigned to unstructured grids using the sparse specification.
Interface:
The following C structures are used to pass information about Locations between the layer and the application.
typedef enum {
DAE_US_CELL,
DAE_US_NODE,
DAE_US_FACE,
DAE_US_EDGE,
} daeUSGridElement;
typedef struct
{
daeInteger faceCount;
daeInteger *face;
daeInteger center;
} daeGridCell;
typedef struct
{
daeInteger adjacentCount;
daeInteger *adjacent;
daeInteger edgeCount;
daeInteger *edge;
daeInteger cellCount;
daeInteger *cell;
daeInteger center;
} daeGridFace;
typedef struct
{
daeInteger faceCount;
daeInteger *face;
daeInteger nodeCount;
daeInteger node;
} daeGridEdge;
typedef struct
{
daeInteger edgeCount;
daeInteger *edge;
daeInteger faceCenter;
daeInteger cellCenter;
} daeGridNode;
Cells, nodes, edges, and faces are all assigned implicit identifiers, which are zero-based ordinal numbers. The numbering is arbitrary, assigned by the definer of the grid. There are no missing numbers in the scheme. The API accepts and presents arrays of the structures identified above, and the identifiers are the indexes into individual structures in these arrays.
These cell, node, edge, or face identifiers also serve as the INDEX_UNDEFINED ordinals in the ELEMENT(unstructured3d,<cell | node | edge | face>,,) property frame as appropriate, thus tying a set of properties to a specific structure in the grid. This allows us to overload the operations currently used for ELEMENTS of type "trimesh, node" for unstructured properties.
In a similar manner, the node identifiers are used as the INDEX_UNDEFINED ordinals in the VOLUME unstructured 3d data type which is used to store the coordinates of the nodes in some specific coordinate system. This operation is the same as operations currently used for SURFACES of type "trimesh".
The UNSTRUCTURED_3D_TOPOLOGY structure and its operations are made more complex by the fact that no upper bound can be set on any of the relationships. Therefore, the actual lists of related structures must be kept apart from the structure arrays. These lists are kept in individual integer arrays, pointed to by the structures themselves.
For relationships which are lists, a null list is signified by a count of zero and a list address equal to NULL. Since NULL is generally equivalent to 0L and since 0 is a valid ordinal number, null relationships of cardinality 1 are signified by -1L.
F.5 Content Model for Frames
The following EXPRESS indicates the content for the frames as stored. Note that this is a content model and represents the content of a stored value. It does not include the transient control frames which are described in this Data Access and Exchange specification. Its purpose is to illustrate. It is not a model that can be accessed as a data model. Where the attributes are accessible through the interface, they are in C data types or arguments to calls.
The content model is presented as annotated EXPRESS. It is not complete in all the rules and constraints, particularly for consistency with values in the Epicentre model. EXPRESS language is shown in Courier typeface, e.g.:
SCHEMA content;
The frames constructs are validated against instances of parts of the Epicentre model, principally diagrams MTG: Grids and Meshes, MTP: Reference Properties and CS1: Coordinate Systems. For each value there will be either one geometry frame or one property frame. These are control structures for a collection of multi-dimensional arrays.
A sparse representation holds a value of each property for identified occurrences of an element or a pair of elements on a grid or mesh. The representation has leaf frames to hold the grid indices to identify the occurrence of the element. Each leaf frame holds a one-dimensional array of values and each value is related to the grid by the stored grid indexes. An element may be a node, an edge, a face, or a cell. A sparse value may alternatively hold values for a pair of edges, faces, or cells. The grid and element are encoded in the frame type.
F.5.1 Geometry Frame
A geometry frame is a frame that is used to represent, on a coordinate system, the position of nodes on a grid or mesh.
- The number of points on each grid axis must be sufficient to contain the points implied by the relevant dimension descriptor of the frame.
- Each coordinate system axis has its coordinate values stored as a leaf frame. The leaf frame is linked to the coordinate system axis that describes the axis.
- The number of dimension descriptors depends on how the data is populated.
- If the data is densely populated (i.e., not sparse) then there is one dimension descriptor (labeled INDEX_I, INDEX_J, INDEX_K) for each grid axis.
- If the grid is sparsely populated (or is unstructured or a mesh), then there will be one descriptor labeled INDEX_UNDEFINED.
- The number of leaf frames depends on the number of axes in the coordinate system.
- A leaf must be defined for each of the coordinate system axes.
- If the grid is sparsely populated, an index leaf must be defined for each grid dimension (i.e., I, J, K).
- If a grid axis is an equal axis or an unequal axis, the coordinate values for one of the coordinate system axes may be stored in the grid axis. In this case, the grid axis must be defined for one of the coordinate system axes of the coordinate system which is attached to the geometry frame. The corresponding leaf frame need not store the values.
META_TYPE geometry_frame; detailed_type : STRING; descriptor : LIST[1:15] OF UNIQUE descriptor; leaf_frame : SET[1:?] leaf_frame; grid_or_mesh : grid_or_mesh; coordinate_system : coordinate_system; vertex : OPTIONAL vertex; END_META_TYPE;
Where
- detailed_type:
- This is the name of the daeEtype data type constant (i.e., FT_LINE, FT_CLOSED_LINE, FT_MESH, FT_SURFACE, FT_CLOSED_SURFACE, FT_VOLUME, FT_CLOSED_VOLUME, FT_CORNER_POINT, FT_UNSTRUC_3GEOM) which describes the type of frame. This type specifies 6 pieces of information: 1) number of dimensions 2) value connection, always node 3) closed flag 4) sparse flag 5) data type, i.e., line, surface, volume 6) grid type, i.e., grid, mesh, corner point, unstructured 3d.
- descriptor:
- Descriptor for each dimension. For non-sparse, the position in the array is the rank of the index. Function daeCreateGeometryFrame sets the default rank based on the order of axes in the grid but the rank can be altered by daeSetRankByDescriptor or daeSetRankInFrame. For sparse, mesh or unstructured one descriptor of type INDEX_UNDEFINED is required.
- leaf_frame:
- Reference to the leaf frames.
- grid_or_mesh:
- The grid or mesh for which the geometry is defined.
- coordinate_system:
- The coordinate system on which the geometry is defined.
- vertex:
- The vertex, if any, relative to which the positions are measured. If none, then positions are relative to the origin of the coordinate system.
F.5.2 Property Frame
A property frame is a frame whose content is specified through a property set. Each leaf of a property frame holds values for one of the properties in the set.
- The number of points on each grid axis must be sufficient to contain the points implied by the relevant dimension descriptor of the frame.
- Each property has its values stored as a leaf frame.
- The number of dimension descriptors depends on how the data is populated.:
- If the data is densely populated (i.e., not sparse) then there is one dimension descriptor (labeled INDEX_I, INDEX_J, INDEX_K) for each grid axis.
- If the grid is sparsely populated (or is unstructured or a mesh), then there will be one descriptor labeled INDEX_UNDEFINED.
- The number of leaf frames depends on the number of properties.
- A leaf must be defined for each property.
- If the grid is sparsely populated, an index leaf must be defined for each grid dimension (i.e., I, J, K).
META_TYPE property_frame;
detailed_type : STRING;
descriptor : LIST[1:16] OF UNIQUE descriptor;
leaf_frame : SET[1:?] leaf_frame;
grid_or_mesh : OPTIONAL grid_or_mesh;
grid2 : OPTIONAL grid_or_mesh;
WHERE
grid_required_valid : (EXISTS(grid_or_mesh) AND (detailed_type
<> 'FT_SAMPLE')) OR ((NOT EXISTS(grid_or_mesh))
AND (detailed_type = 'FT_SAMPLE');
END_META_TYPE;
Where
- detailed_type:
- This is the name of the daeEtype data type constant (e.g., FT_SAMPLE, EGRID_1DNODE, SGRID_1DNODE, etc.) which describes the type of frame. This type specifies 6 pieces of information: 1) number of dimensions 2) value connection, i.e., node, edge, face, cell, 3) closed flag 4) sparse flag 5) data type, i.e., sample, element 6) grid type, i.e., none, grid, mesh, corner point, unstructured 3d.
- descriptor:
- Descriptor for each dimension. The position in the array is the rank of the index. Function daeCreatePropertyFrame sets the default rank based on the order of axes in the grid but the rank can be altered by daeSetRankByDescriptor or daeSetRankInFrame. For sparse and sample, one descriptor of type INDEX_UNDEFINED is required.
- leaf_frame:
- Reference to the leaf frames.
- grid_or_mesh:
- The grid or mesh for which the property is defined. Required for all but SAMPLE frames.
- grid2:
- The second grid or mesh for which the property is defined. Only used for a sparse grid of edge pairs, face pairs, or cell pairs when the pairs are separate grids.
F.5.3 Descriptor
The description of each dimension of the frame. This information is set by daeSetValuesOfDimension before calling daeMakeFrameInfoPersistent. Any calls to daeSetValuesOfDimension without calling daeMakeFrameInfoPersistent will affect the data accessed via get/put functions but will not affect the persistent description of the data. Get/put utilities have an increment capability but this only affects the access and not the persistent description of the data. For put, it is assumed that all values (i.e., defined at increment of 1) will have been written before calling daeUpdateLeafStatistics.
META_TYPE descriptor;
dimension : STRING;
lower_bound : INTEGER;
count : INTEGER;
END_META_TYPE;
Where
- dimension:
- This is the name of the daeItype enumeration constant (i.e., INDEX_HYPERFACE, INDEX_CORNER, INDEX_EDGE, INDEX_FACE, INDEX_NODE, INDEX_UNDEFINED, INDEX_I, INDEX_J, INDEX_K) which describes the type of descriptor. Indicator as to the meaning and use of the dimension. In a single value, it is adequate to identify an