Modeling and Querying Scientific Simulation Mesh Data

Modeling and Querying Scientific Simulation Mesh Data Byung S. Lee, Robert R. Snapp, Li Chen Department of Computer Science University of Vermont Burlington, Vermont 05405 {bslee, snapp, lchen}@cs.uvm.edu

Il-Yeol Song College of Information Science & Technology Drexel University Philadelphia, Pennsylvania 19104 [email protected] Abstract

Scientific simulation is gaining attention as an inexpensive means of experimentation in scientific computing, as is the data generated by the simulation. Scientific simulation typically generates mesh data, i.e., data in a grid structure, in a sequence of time steps. The data is complex, as is the file structure. Understanding these involves analyzing the topology and geometry of grid points, and the fields at those points. Currently, there is no data model, nor query language, accepted widely for this kind of data. In our work, we developed a compact, generic model of simulation mesh data, and validated the model through implementation using a standard query language on an object-oriented database. In this paper, we present the generic model, its implementation, and ideas for improving queries in our model. To our knowledge, our work is the first successful attempt of modeling and querying scientific simulation mesh data. Keywords: scientific simulation mesh data, object query language, data model, ad hoc query

1

Introduction

Simulation is a cost-effective way of conducting a test without actually building an artifact, and is used in various fields such as physical science, engineering, medicine, manufacturing, climatology, and defense. Scientific simulations, common in the scientific computing field, typically generate data in a mesh structure through numerical calculations. We call this kind of data scientific simulation mesh data or, in short, simulation mesh data. There exist formats (and the associated library interfaces) for storing and manipulating this data, such as Common Data Format, Network Common Data Format (NetCDF) [2], Hierarchical Data Format (HDF) [3], and Silo [4]. These formats are proprietary to the institutions that developed them, and the lack of standard hinders the compatibility of applications written on them. We need a generic data model that encompasses the disparate data formats. In this paper, we present a generic model of scientific simulation mesh data, and validate the model through implementation using a standard query language. The model is based largely on the Silo format, which takes advantage of the features in NetCDF, which, in turn, is an immediate descendent of CDF. All three formats are used to store simulation mesh data in a multidimensional array, with the most diverse features supported in Silo and the least in CDF. HDF, developed independent of these three, can be used to store simulation mesh data in a multidimensional array. However, its features are limited compared with those of Silo. (HDF is meant to be used to store any kind of objects, including such objects as relational tables and image files).

Our model is concise, and needs only three simple data structures that represent mesh topology, mesh geometry, and mesh fields (in a manner similar to those used in computer graphic object modeling [22]), including only four base operators for these structures. The set of base operators is minimal and complete under the criterion of “structural duplicability.” Despite its simplicity, the model is powerful enough to support a broad range of queries on data that covers the aspects of topology, geometry, fields, and any combination of them. The implementation successfully demonstrated the suitability of our data model. Using Object Data Management Group’s (ODMG) Object Query Language (OQL) [7], we validated the sufficiency of the model to support all reference queries we collected. The implementation was done on lambda-DB [23], an object-oriented database management system (OODBMS). An object-oriented approach is not new to scientific databases, as exemplified in the works by Kim [12], Ejlmann et al. [13], and Guu et al. [14]. However, our work is distinct in dealing with simulation mesh data, which has never been addressed in any previous works. As far as we know, our work is the first to be successful in executing ad hoc queries on simulation mesh data and visualizing the query results. Despite profuse production of data today, the lack of ad hoc query tools has been a limiting factor in utilizing the data. The only available query tools are visualization tools [5, 6], which provide only fixed, primitive query operations such as finding points, and displaying iso-surfaces or orthogonal slices. The need for ad hoc query capabilities on scientific simulation mesh data has recently been stressed by Lee et al. [15]. In summary, two main contributions of our work presented in this paper are: • A simulation mesh data model that is generic enough to embrace proprietary file formats of data, concise enough to comprehend easily, and yet general enough to express a broad range of queries. • An unprecedented case of executing ad hoc queries on scientific simulation mesh data and visualizing the query results. This paper is organized as follows. Following this introduction, we first give an overview of simulation mesh data in Section 2. Then we describe its modeling in Section 3, implementation of the model in Section 4, and evaluation of the implementation in Section 5. We also discuss how our data model relates to other conventional data models in Section 6. Then, related work follows in Section 7, and summary and future work in Section 8.

2

Overview of Scientific Simulation Mesh Data

Our focus of the overview is on the concept, characteristics, example, and reference queries of scientific simulation mesh data.

2.1

Concept

In general, mesh data is a grid-structured, discrete sample of continuous data, generated in sequential time steps with a scientific simulation. The geometrical space that contains the mesh can have an arbitrary number of dimensions, but in practice one to three is typical. When visualizing a mesh as a multidimensional grid, we see a one-dimensional (1-D) grid for connected line segments, a 2-D grid for connected polygons, and a 3-D grid for connected polyhedra.

2

We call the constituents of a mesh, mesh elements, and distinguish them further into mesh vertex elements, mesh edge elements, mesh face elements, and mesh volume elements. These elements are distinguished by their levels – 0 for mesh vertex elements, 1 for edge, 2 for face, and 3 for volume. (In this paper, we will omit the word “element” when referring to mesh elements at these levels when it is not ambiguous.) A vertex has associated with it a topological index and geometrical coordinates. A topological index determines the order of vertices in a multidimensional array. Geometrical coordinates locate a vertex in a multidimensional space. A mesh element at any level has zero or more associated field variables, whose values are calculated numerically.

2.2

Characteristics

Shoshani et al. [16] classified mesh data by its structural characteristics such as regularity, time-variation, and density of data points (i,e., vertices). • Regularity is determined by the geometric pattern of mesh vertices. We distinguish between spatial regularity and temporal regularity. For spatially regular mesh data, vertices make a regular grid at each time step. For temporally regular mesh data, the mesh is generated at a regular time interval. Regular mesh data allows the coordinates to be calculated, hence not stored. By contrast, irregular mesh data requires storing spatial, temporal coordinates with the field values. All four data formats – CDF, NetCDF, HDF, and Silo – can be used for both regular and irregular meshes. However, unlike Silo, CDF, NetCDF, and HDF require special conventions to circumvent the lack of inherent support for irregular meshes. • Time-variation is determined by whether vertex coordinates vary with time or not. A time-varying mesh is very common in the simulation of a dynamic process, such as deforming an artifact (e.g., crashing a car, bending a rod) or a natural phenomenon (e.g., weather change). In this case, we should store the geometrical coordinates of mesh vertices associated with their topological indices to allow for tracing of the vertex coordinates changing over time. All four data formats can be used for time-varying meshes. • Density is a measure of the relative number of mesh elements without associated data. For example, an air turbulence simulation typically generates mesh data with field values at every element, hence it is dense. In contrast, a particle collision simulation typically generates mesh data with field values at only a small number of elements, hence it is sparse. All four data formats are applicable to data of any density, although there are some differences in their storage efficiency.

2.3

Example

Figure 1 shows an example of mesh data generated by simulating an aluminum can being crushed against a brick wall. Its file format is Silo [4]. We see snapshots taken at the 10th, 15th, and 20th time steps at the interval of 0.1msec among time steps 0 through 43 in a Cartesian coordinate space of x, y, and z axes. The geometrical structure is cylindrical, and topological structure is hexahedral. There are ten field variables, among which only “eqps” (equivalent plastic strain) is defined in a volume, and the others (i.e., displx, disply, displz, velx, vely, velz, accx, accy, accz) are defined at a vertex. (displ = displacement, vel = velocity, acc = acceleration. The suffixes x, y, and z are Cartesian coordinates.)

3

Figure 1: Crushing can mesh data of field VELZ at time steps 10, 15, and 20 4

2.4

Reference queries

There are two primary user groups: scientists (data consumers) that query mesh data, and numerical analysts (data producers) that design and generate the data. We presume scientists are interested in querying about the fields and geometry of mesh elements, while numerical analysts are interested in the topology and geometry. We collected and categorized query types through inquiries with scientists and our own investigations. The collection of query types covers all three aspects of simulation mesh data structure: topology, geometry, and field. We assert that the collection is sufficiently comprehensive. (The letters in brackets denote the categories the queries belong to – T for topological, G for geometrical, and F for field.) • Find all mesh elements on the boundary of a mesh. [T] • Find all mesh elements that are bounded by other mesh elements at a lower level. – An “adjacency query”. [T] • Find all mesh elements with a certain topological characteristic. – e.g., hexahedral volumes [T] • Find the coordinates of mesh vertices. [G] • Find mesh elements inside a geometrical bounding box. [G] • Find the mesh vertex closest to a given point. [G] – A “nearest neighbor query”. • Find the values of field variables defined at a mesh element. [F] • Find the set of mesh elements that satisfy a predicate on the values of field variables. [F] • Find the coordinates of mesh vertices delimiting a mesh element. [T and G] • Find mesh volumes containing a point in space. [T and G] – A “range query”. • Find the values of field variables at all mesh vertices contained in a geometrical bounding box. [G and F] • Find all mesh elements whose field variables satisfy a predicate condition inside a geometrical bounding box. [G and F] • Find all mesh elements lying on the contact interface between two meshes. [F and T] • Compare between the value of a field variable at a particular mesh element and an aggregate value of the field variable at neighboring mesh elements. [F and T] • Find an aggregate value of a geometric quantity (e.g., volume, area) at mesh elements whose field variables satisfy a predicate condition. [T, G, and F]

3

Data Model

In this section, we present a logical data model of scientific simulation mesh data, describe the abstract data structures and base operators that constitute the data model, prove the soundness of the data model based on the criterion of structural duplicability, and introduce examples of derived operators augmenting the set of operators. 5

3.1

Logical data model n-D Mesh 1 .. *

Submesh

Connected Submesh

Point Mesh

1 .. * *

Element fields[0..*]

Compound Element

Simple Element

1 .. *

Hyper…volume

Volume

Face

Edge

Vertex

{dim=n}

{dim=3}

{dim=2}

{dim=1}

{dim=0} coordinates[0..n]

{‘dim’ denotes the dimension level of the instances of a class.} { Coordinates[0] is time, or equivalently, a simulation time step.}

Figure 2: Logical model of simulation mesh data Figure 2 shows a logical model of an arbitrary n-dimensional simulation mesh data, depicted in Unified Modeling Language (UML) [11]. In our model, a mesh is composed of one or more disjoint submeshes. Each submesh is either a connected submesh or a point mesh. A point mesh is a collection of isolated points. A connected submesh is made of one or more mesh elements. A mesh element is either compound, aggregating other mesh elements one dimensional level below, or simple, i.e., with no component. A vertex is a simple element, for example. The dimensional level is defined for each subclass of the “Compound Element” and “Simple Element” classes as level 0 for vertices, 1 for edges, 2 for faces, 3 for volumes, 4 for hypervolumes, and so on. Any mesh element can have fields defined on them. In contrast, only mesh vertices have coordinates locating their positions. We can arbitrarily choose the first coordinate as the time, or equivalently, a simulation time step.

6

3.2

Data structures and base operators

To implement simulation mesh data as modeled in Figure 2, we need three data structures that describe the three aspects of the data: a mesh topology graph (MTG) for topological indices, a vertex coordinate set (VCS) for geometrical coordinates, and a field vector set (FVS) for field variables. Associated with the data structures is a base operator set (BOS), whose members are parents, children, fields, and coordinates. From these operators we can derive other operators algebraically or computationally. Figure 3 shows the mesh topology graph (MTG) of one hexahedral mesh hypervolume, an equivalent of a time series of mesh volumes. Figure 4 shows three connected hexahedral mesh volumes at time step 15, and their geometry and field information. The corresponding vertex coordinate set and field vector set are in Figure 5. The mesh topology graph in Figure 6 shows the topology information. 3D volume face edge vertex

Dimension Mesh elements

a) Mesh elements 4

hyper-volumes

3

volumes

2

faces

1

edges

0

vertices

t = t1

t = t2

b) Mesh topology graph

Figure 3: Mesh topology graph of one hexahedral mesh hyper-volume element We will now elaborate on each data structure while introducing base operators for each data structure. Definition 3.1 (Mesh topology graph (MTG)) A mesh topology graph is defined as {Gi |i = 1, 2, · · ·} where each Gi is the topology graph of a connected submesh. The submesh topology graph Gi is defined as Gi =< Ei , Li > where Ei denotes the set of submesh elements, and Li denotes the set of parent-child links between two members of Ei whose levels differ by 1. The number of levels is infinite in theory, although 4 is the maximum in practice. The base operator set includes two topological operators: • m.Parents = {m ∈ M|parent(m , m)} Given a set of mesh elements M in a mesh topology graph, this operator finds all mesh elements that are one level higher than the element m. It returns an empty set if there is no higher level. 7

Geometry information: Time = 1.5msec (= time step 15) Coordinate of node n3 = Length of edge e38 = 0.1mm Length of edge e814 = 0.12mm Length of edge e1415 = 0.12mm Length of edge e1516 = 0.1mm 5 Length of edge e23 = 0.2mm

Field information: Temperature, density of a volume Pressure of a face Torque of an edge Velx, vely, velz of a vertex

v1

2

11

v3

6

1

12

v2

7

13 10 16 9

4 z

y

3

15 14

8

x

Figure 4: Connected hexahedral mesh volumes

{, , , , , , , , , , , , (a) Vector coordinate set

, , , }

{, , , } (b) Field vector set

Figure 5: Vertex coordinate set and field vector set of the mesh shown in Figure 4

8

hv1

v1

f1234

e14

n1

f1496

e12

f1276

f2387

f4389

v2

f6789

f671312

f781413

e61 e23 e72 e43 e38 e94 e67 e78 e89 e96 e713

n2

n3

n4

n5

n6

f981415

f12131415

e1312 e126 e814

n7

v3

n8

e1413

n9

f691512

f56910

f5101611

f561211

e1415 e159 e1512 e56 e910 e105 e1016

n10

n11

n12

n13

f1091516

e1611

n14

f12151611

e11,5 e1211

n15

e1516

n16

(hv=hypervolume, v=volume, f=face, e=edge, n=vertex)

Figure 6: Mesh topology graph of the mesh shown in Figure 4 • m.Children = {m ∈ M|parent(m, m )} Given a set of mesh elements M in a mesh topology graph, this operator finds all mesh elements that are one level lower than the element m. It returns an empty set if there is no lower level. For example, in Figure 6, n7.Parents returns a set of edges { e72, e67, e78, e713 } delimited by the vertex n7; e78.Parents returns a set of faces { f2387, f6789, f781413 } delimited by the edge e78; and e78.Children returns a set of two vertices { n7, n8 } delimiting the edge e78. Definition 3.2 (Vertex coordinate set (VCS)) Given a k-dimensional mesh, a vertex coordinate set is de >} where n denotes a vertex, and X  denotes a vector representation of the geometrical fined as V = {< n, X coordinate X =< x0 , x1 , · · · , xk > of the vertex n, where x0 is always a time step. The base operator set includes one geometrical operator, applicable to mesh vertices only: • Coordinates – Given a mesh vertex n, n.Coordinates returns the vector of its coordinates. For example, for the mesh shown in Figure 4, n7.Coordinates returns a vector of , or if time step is used instead. Definition 3.3 (Field vector set (FVS)) A field vector set is defined as F = {< T , F >} where T denotes a mesh element type and F denotes a vector representation of the field variables defined in the mesh element type T . The base operator set includes one field operator: • Fields – Given a mesh element m, m.Fields returns the vector F of fields defined in the type of m. 9

For example, for the mesh shown in Figure 4, v2.Fields returns a vector of field variables define in the type Volume. Summarizing the operators on all three data structures: Definition 3.4 (Base operator set (BOS)) A base operator set is a set of primitive topological, geometrical, and field operators, and is defined as { Parents, Children, Coordinates, Fields }.

3.3

Soundness of the data model

We use structural duplicability to judge the soundness of a mesh data model. This criterion stems from the communication theory. A model is sound if and only if the model is necessary and sufficient for a receiver to duplicate the sent data. Note that the BOS operators are for read-only and therefore an actual duplication is not possible. In order to prove duplicability, however, it suffices to prove that the structure is completely retrievable given the operators. First, let us define the criterion of a data model’s soundness: Definition 3.5 (Soundness of a data model) A data model < S, O > defined by a data structure S and a set of algebraic operators O is said to be sound if and only if S and O are necessary and sufficient for the data to be duplicable. In this case, we also say O is algebraically minimal and complete in terms of the structural duplicability of S. Under this criterion, proving the following theorem has the same effect as proving the soundness of our data model. Theorem 3.1 (Duplicability of simulation mesh data) Simulation mesh data is duplicable given the data structures MTG, VCS, FVS, and the base operator set BOS defined in Definitions 3.1 through 3.4. Besides, the data is not duplicable if any of the data structures and base operators is missing. Proof: The data structures MTG, VCS, and FVS represent disjoint information and therefore any of them cannot be represented using the others. Hence, we have only to prove that the BOS is sufficient and necessary to retrieve the three data structures completely. • Sufficiency part: First, starting from an arbitrary mesh element, we can use “Parents” and “Children” repeatedly to traverse the entire MTG (like the one shown in Figure 6). Since an MTG is a connected graph, there always exists a path (i.e., a sequence of parent-child links) between any two nodes (i.e., mesh elements). Hence, the MTG is duplicable. Second, as we visit each vertex in the MTG, we can use “Coordinates” to retrieve its coordinates, thus retrieving the VCS. Third, as we visit each mesh element, we can use “Fields” to retrieve its fields, thus retrieving the FVS. Therefore, we can retrieve an entire mesh data given the operators in the BOS. • Necessity part: Let us examine the cases of missing each operator in the BOS. Without “Parents”, if we start from any descendent of an arbitrary hypervolume in an MTG, we can never visit the hypervolume; without “Children”, if we start from any ancestor of an arbitrary vertex, we can never visit the vertex; without “Coordinates”, we can never retrieve the coordinates of any vertex; without “Fields”, we can never retrieve the fields of any mesh element. Q.E.D.

10

3.4

Derived operators

Although the base operators in our model are algebraically minimal and complete in terms of structural duplicability, they alone are not enough to retrieve arbitrary information from the data. This is more evident if the computation requires control flow of operations, such as conditional branching (i.e., if−then−else) or iteration (e.g., for loop). Thus, the set of operators needs to be augmented with computational operators available from a host programming language (e.g., C++, Java) or an extended database language (e.g., embedded OQL, PL/SQL, Transact-SQL). We introduce here some derived operators we used in our implementation. The codes are shown in Appendix B. • m.siblings() = {m ∈ M|∃p ∈ M(m = m ∧ parent(p, m) ∧ parent(p, m ))} Given a set of mesh elements M, this operator returns all mesh elements that share the same parent elements as the element m. It returns an empty set if m has no parent element. • m.spouses() = {m ∈ M|∃c ∈ M(m = m ∧ parent(m, c) ∧ parent(m , c))} Given a set of mesh elements M, this operator returns all mesh elements that share the same child elements as the element m. It returns an empty set if m has no child element. • n.distance(point p) returns the distance from a vertex n to a point p whose coordinates are known. (See Appendix A for the definition of the type “point”.) • v.contains(point p) returns whether a volume v contains a point p whose coordinates are known. • v.gvolume() returns the geometric volume calculated for a volume v.

4

Implementation

Our simulation mesh data model was implemented on lambda-DB [23]. We populated a database with the crushing can data (in Section 2.3), and executed OQL queries on it. For queries that retrieve mesh volumes, we visualized the results on a visualization tool meshTV [5]. We present the details of the implementation in this section.

4.1

Data Schema

Figure 7 shows the class diagram of the implemented data schema in UML. The code of the schema, written in lambda-DB ODL, appears in Appendix A. The schema implements part of the logical model shown in Figure 2. More specifically, a single connected submesh in a 3-dimensional space spanning multiple time steps has been implemented. This reduction does not lessen any generality because, for instance, a mesh consisting of multiple submeshes is implemented simply as a collection of individual submesh implementations; a submesh of higher dimension is implemented by adding more subclasses to the class “Element”; and a point mesh is implemented by creating only the instances of the class “Vertex.” We considered alternative approaches to handling the dimensional level and the time step of a mesh element. First, we can identify the level of a mesh element in either dimension-by- extent (DE) approach or dimension-by- attribute (DA) approach. (We used the DE approach in our implementation.) The schema in Figure 7 uses the DE approach, and that in Figure 8 uses the DA approach. In the DE approach, mesh elements are set apart into separate extents by their dimensional levels. As a result, a query can be asked directly against the mesh elements at a particular level. By contrast, in the DA approach, all mesh elements 11

3D Connected Mesh

1 .. *

Element timestep: short fields[0..*]: double

Volume

Face

Edge

Vertex coordinates[3]

parents children 1.. 2

4..* {= n: even}

parents children 2.. *

parents

children 2

3.. * 3..* {= n/2 +1}

Figure 7: Class diagram of 3-dimensional simulation mesh data using DE and TA approaches

3D Connected Mesh

1 .. *

Element

*

parents

*

children

dimension: short fields[0..*]: double

Vertex coordinates[4] {t,x,y,z}

Figure 8: Class diagram of 3-dimensional simulation mesh data using DA and TF approaches

12

are stored in the extent of one class (i.e., “Element”) regardless of their dimensional level. As a result, a query can be asked against the mesh elements at any level distinguished with the attribute “dimension” of the class “Element.” These two approaches have different performance implications. We will discuss it in Section 5.2. Second, we tried two alternative approaches to identifying the time step of a mesh element: a timestep attribute (TA) approach and a timestep function (TF) approach. (We used the TA approach in our implementation.) The schema in Figure 7 used the TA approach, and that in Figure 8 used the TF approach. In the TA approach, time step is defined as an attribute of the class “Element,” and is inherited to all subclasses. As a result, the attribute “Coordinates” of the class “Vertex” needs only three components (e.g., x, y, and z). In contrast, in the TF approach, we use the time step as the first component of the coordinate of a mesh vertex, and define a function that, given a mesh element, retrieves the time step by navigating to the first child recursively until it reaches a vertex. Figure 9 shows the timestep functions we implemented on lambda-DB. (We did not use polymorphism because lambda-DB did not support it.) We will discuss performance implications of these two approaches in Section 5.2. 1. Define a firstVtx_X function that returns the “first” vertex for a given mesh element. define firstVtx_E(e: Edge):Vertex as first(e.children); define firstVtx_F(f: Face):Vertex as firstVtx_E(first(f.children)); define firstVtx_V(v: Volume):Vertex as firstVtx_F(first(v.children)); 2. Define timestep functions for mesh elements at the dimension level 0 to 3: define N_timestep(n: Vertex):float as n.coordinates[0]; define E_timestep(e: Edge):float as firstVtx_E(e).coordinates[0]; define F_timestep(f: Face):float as firstVtx_F(f).coordinates[0]; define V_timestep(v: Volume):float as firstVtx_V(v).coordinates[0]; Figure 9: Timestep functions for mesh elements

4.2

Queries

Each OQL query in this section matches the query listed in Section 2.4. The type (T, G, F) of each query is determined by the expression in the “where” clause. Finding all mesh elements on the boundary of mesh Q1: Find all mesh faces on the boundary of the mesh at time step 13. (That is, faces that belong to only one volume.) select distinct f from f in faces where f.timestep=13 and count(f.parents)=1; Let us repeat the same query for mesh volumes. Q2: Find all mesh volumes on the boundary of the mesh at time step 15. (That is, volumes one of whose faces is on the boundary.) select distinct v from v in volumes where v.timestep=15 and exists f in v.children: count(f.parents)=1; 13

Finding all mesh elements that are bounded by other mesh elements at a lower level Q3: Find all mesh faces bounded by edges e1, e2, e3, and e4 at time step 21. The edges e1, e2, e3, and e4 can be identified with their attribute “no”. (See Appendix A.) For example, e1 can be retrieved as: e1 = element(select distinct e from e in edges where e.no=8 and e.timestep=21); Then, the query can be written as follows. select distinct f from f in faces where f.timestep=21 and f.children = list(e1,e2,e3,e4); Q4: Find all mesh volumes bounded by vertices n1, n2, n3, n4, n5, n6, n7, and n8 at time step 26. (Note that vertices are two levels below volumes in a mesh topology graph.) As in the previous example, the vertices, n1 for instance, can be retrieved as: n1 = element(select distinct n from vertices where n.no = 2 and n.timestep=26); select distinct v from v in volumes where v.timestep=26 and set(n1,n2,n3,n4,n5,n6,n7,n8) -1.2 and z < -10.0 at time step 16. select distinct v from v in volumes, f in v.children, e in f.children, n in e.children where v.timestep=16 and n.coordinates[0]-1.2 and n.coordinates[2] at time step 18 using a Euclidean distance metric. define p():point as list((float)18, 10.2, 15.3, 11.7); select n from n in vertices where n.timestep = 18 14

and n.distance(p) = min(select n1.distance(p) from n1 in vertices where timestep=18); Implementation of the derived operator “distance” is shown in Appendix B. Finding the values of field variables defined at a mesh element Q9: Find the values of field variables of a mesh vertex with a vertex number 391 at time step 28. element(select distinct n from n in vertices where n.no=391 and n.timestep=28).fields; Finding the set of mesh elements that satisfy a predicate on the values of field variables Q10: Find the set of mesh vertices whose field variables ACCLX > 30.0 and ACCLY > 30.0 at time step 19. The field variables of crushing can mesh data are listed in the (zero-based) order of VELX, VELY, VELZ, ACCLX, ACCLY, ACCLZ, DISPLX, DISPLY, and DISPLZ for mesh vertices, and EQPS for mesh volumes. Given this order, we can write the query as: select distinct n from n in vertices where n.timestep=19 and n.fields[3]> 30.0 and n.fields[4] > 30.0; Alternatively, we can mimick the syntax of SQL using OQL “define” statements: define ACCLX as fields[3]; define ACCLY as fields[4]; select distinct n from n in vertices where n.timestep=19 and n.ACCLX > 30.0 and n.ACCLY > 30.0; Q11: Find all mesh faces where field variable EQPS is between 1.0 and 5.0 at each time step ranging from 21 to 30. select distinct f from f in faces where f.timestep>=21 and f.timestep1.0 and f.fields[9] 10.0 at time step 7. select max(n.fields[8]), min(n.fields[8]) from n in vertices where n.timestep=7 and n.fields[8]>10.0; Finding the coordinates of mesh vertices delimiting a mesh element Q13: Find all vertex coordinates of a mesh volume (no. 100) at time step 26. %for each n2 in select distinct n.coordinates from v in volumes, f in v.children, e in f.children, n in e.children where v.no=100 and v.timestep=26; do OutputFile«"Vertex no:"«setw(10)«v2->no «"coordinates:"«setw(12)«v2->coordinate[1]«setw(12) «v2->coordinate[2]«setw(12)«v2->coordinate[3]«endl; We iterate on the returned set of nodes to print its coordinates. (The line preceded by % is an OQL statement embedded in a C++ code.) 15

Finding mesh volumes containing a point in space Q14: Find all mesh volumes containing a point at coordinates < x = 13.0, y = 25.3, z = 17.2> at time step 15. select distinct v from v in volumes where v.timestep=15 and v.contains(list((float) 15, 13.0, 25.3, 17.2)); Implementing the derived operator “contains” requires a computational geometry approach, and we did not implement it. Its algorithm is outlined in Appendix B. Finding the values of field variables of all mesh vertices contained in a geometrical bounding box Q15: Find the values of field variables of all mesh vertices in a spatial range of 1.0