ࡱ> ` bjbj _ w444Fz4"""6"Y"Y"Y8ZY\L6 f]JbLbccArVw+y$hz%E"r@Ar%ccjH: Rc"c""CcZ] 5 W"Yَ k$+THC"C@yne|!~dyyy%%dyyy66dD"7D!667666  Supporting Finite Element Analysis with a Relational Database Backend Part I: There is Life beyond Files Gerd Heber Cornell Theory Center, 638 Rhodes Hall, Cornell University, Ithaca, NY 14850, USA  HYPERLINK "mailto:heber@tc.cornell.edu" heber@tc.cornell.edu Jim Gray Microsoft Research, San Francisco, CA, 94105, USA Gray@Microsoft.com April 2005 Revised May 2005 Technical Report MSR-TR-2005-49 Microsoft Research Advanced Technology Division Microsoft Corporation One Microsoft Way Redmond, WA 98052 Supporting Finite Element Analysis with a Relational Database Backend Part I: There is Life beyond Files Gerd Heber and Jim Gray Cornell Theory Center, 638 Rhodes Hall, Ithaca, NY 14850, USA  HYPERLINK "mailto:heber@tc.cornell.edu" heber@tc.cornell.edu Microsoft Research, 455 Market St., San Francisco, CA 94105, USA gray@microsoft.com Abstract: In this paper, we show how to use a Relational Database Management System in support of Finite Element Analysis. We believe it is a new way of thinking about data management in well-understood applications to prepare them for two major challenges, - size and integration (globalization). Neither extreme size nor integration (with other applications over the Web) was a design concern 30 years ago when the paradigm for FEA implementation first was formed. On the other hand, database technology has come a long way since its inception and it is past time to highlight its usefulness to the field of scientific computing and computer based engineering. This series aims to widen the list of applications for database designers and for FEA users and application developers to reap some of the benefits of database development. Introduction This is the first article of a three-part series. Together, they show how Relational Database Management Systems (RDBMS) can dramatically simplify the well established engineering tool, Finite Element Analysis (FEA). Affordable high-performance computing clusters based on commodity hardware and software will soon make large-scale FEA as standard a tool as desktop FEA packages are today. But large-scale FEA has a substantial data management component in defining the problem, building the mesh, running the computation, and analyzing the resulting information. Current, file-based FEA data management practice lacks the scalability and functionality needed to make it easy for engineers to use on huge problems. Introducing Relational Database technology ameliorates both these scalability and usability problems. FEA is not an isolated example of this size effect, forcing us to re-think the way we handle application data [ REF _Ref99194293 \r \h  \* MERGEFORMAT 1]. This article discusses how to make the transition from a file-based to a database-centric environment in support of large scale FEA. Our reference database system is Microsoft SQL Server 2000 [ REF _Ref88222570 \r \h 6, REF _Ref99194871 \r \h 7], but the arguments apply equally well to any RDBMS with good scalability and self-management features. We will point out some of the deficiencies of purely relational systems in the areas of programmability and handling attribute data. That discussion sets the stage for Part II which describes the new features and substantial improvements that come with Object-Relational database management systems (ORDBMS) as typified by Microsoft SQL Server 2005 [ REF _Ref99194902 \r \h 8, REF _Ref99194911 \r \h 9]. Part II shows how these features help address the shortcomings exposed in Part I. Part III presents a case study on how client applications can benefit from a database-centric server approach. The sample application is a real-time interactive visualization of three-dimensional metallic polycrystal models using OpenDX [ REF _Ref99194384 \r \h 10]. The term Finite Element Analysis (FEA), encompasses the entire process of modeling a physical system, including model generation, meshing, attribute assignment, solution, and post-processing. Each of these phases is a substantial data management task, and the data flows among the phases are also substantial. A general purpose data management solution can accelerate, simplify and unify the entire process not just the individual parts. The methodology presented in these articles has been applied in 3D simulations of crack propagation and in the simulation of plasticity and fatigue of 3D metallic polycrystals in the Cornell Fracture Group [ REF _Ref99852907 \r \h 17]. In both cases, there are substantial topology, geometry, and attribute data, and the finite element mesh alone is not sufficient to analyze and interpret the results. There is an enormous body of recent work on FEA data management [ REF _Ref99434875 \r \h 3, REF _Ref99434880 \r \h 13, REF _Ref99434882 \r \h 14, REF _Ref99434883 \r \h 15, REF _Ref99851543 \r \h 16, REF _Ref99853901 \r \h 2, REF _Ref99853906 \r \h 18, REF _Ref99853908 \r \h 19]. Huge advances are being made in each of the six areas outlined in Figure 1. Their scope and implementation varies with the underlying FEA and, in some cases, the intended user interface. Despite the differences in the applications, the recurring themes surrounding the limitations of proprietary file-based FEA data management are the same: the lack of a unified data modeling capability, the absence of data integrity enforcement and data coherence, limited metadata management, the lack of query interfaces, poor scalability, no support for automatic parallelism, poor application integration, and the lack of support for Internet-scale (Grid [ REF _Ref101410802 \r \h 37]) distributed applications. In addressing these issues, some authors have built their own DBMS and query interfaces. We have taken the approach of basing our FEA tools on a supported database system rather than reinvent one. This paper is not an introduction to FEA or to databases. It is at a level that should be accessible to workers in either discipline. We would like to hear your reaction to these ideas, especially if you happen to be an FEA practitioner or a database expert! Finite Element Method (FEM) The Finite Element Method (FEM) is an approach to modeling partial differential equations (PDE) by replacing the continuum problem with an approximate discrete problem suitable for numerical solution in a computer. The discussion here focuses exclusively on common data management problems in the context of FEM-based simulations. No reference is made to and no knowledge of the mathematical theory behind FEM is required [ REF _Ref99356135 \r \h 12]. To give a very simple example of the FEM approach, imagine that we want to simulate heat flow across a block of inhomogeneous material. The material would be modeled by a space-filling set of voxels (the mesh), each voxel with its own heat conductivity parameters and initial conditions. The differential equations would specify heat transfer among voxels based on the material properties, and the temperature of the neighboring voxels. The solution would iteratively solve these equations occasionally recording the state of the voxels. Post processing would analyze these outputs and put them in a form convenient for visualization. Other popular discretization methods for PDE include Finite Differences, Finite Volumes, and wavelets. The decision which method to use is driven by the geometric complexity of the underlying domain, the nature of the boundary conditions, as well as the regularity of the PDE. This situation is amplified in multi-physics and multi-scale environments where multiple discretization methods are applied over different but coupled spatial and time scales. Each of these aspects creates specific data modeling and management problems. The conceptual similarity among these problems does not justify automatic application of one solution across the board. Before we can move on to the core of this paper the mapping of FEA data onto a relational model we first sketch the nature, flow, and scale of data in an FEA. FEA Data and Dataflow Various data creation and transformation tasks precede and follow the actual numerical solution of a PDE using FEM. The main phases of a FEA described in Figure 1 are: Model creation generates the topology and geometry information, typically representing the material boundary using parametric surfaces like Bzier patches or Non-Uniform Rational Bzier-Splines (NURBS) [ REF _Ref99344997 \r \h 11] in a CAD (Computer Aided Design) tool. The model creation also specifies the system equilibrium and dynamics by defining the interactions as a set of partial differential equations. The meshing phase decomposes the model geometry into simple shapes or voxels like tetrahedra or bricks that fill the volume. Attribute definition and assignment specifies properties of model entities (e.g., material properties of volumes) and imposes initial and boundary conditions on the solution. Solution uses the model equations, mesh, and attributes to simulate the systems behavior. Often, a whole suite of solutions is run with different attribute assignments. These solutions produce vast quantities of data. Post-processing tasks examine the solution output for features or trends. In our case, tools look for cracks, and quantify crack propagation. During all these phases, visualization tools let the engineers or scientists examine, explore and analyze the data. This is a simplified presentation of the FEA process. More complex scenarios are quite common: often the output of one simulation is directly or indirectly part of the input data of other simulations and often the simulation is driven by or interacts with measurements from an experimental system. Most discussion of FEA focuses on the solution phase. That is where 90% of the data comes from; that is where 90% of the computer time goes. But in our experience, the solution phase consumes a minority of the people-time and people-time is the expensive and time-consuming part of an end-to-end FEA. Although the solution phase produces most of the data, the time spent in pre-processing and post-processing complex models far exceeds the solution time. As supercomputers and large workstation clusters become ubiquitous, the model preparation and data analysis tasks become even more labor intensive. Computational cluster tools reduce the solution time to several hours or days, and produce vastly more data. On the other hand, creating a correct and complete (CAD) model is a time-consuming and demanding art. Analyzing the model outputs is equally demanding and time-consuming. Reference [ REF _Ref99279329 \r \h 5] gives a nice overview of industrial FEA data management. In that presentation, and in general, the terminology is ecumenical the term database is used to describe any structured storage beyond a simple file store. The storage spectrum ranges from formatted ASCII or binary files to custom database implementations. More than 90% of FEA data is easily represented as dense tabular data using basic types like integers and floating point numbers. This includes parts of the topology and geometry, the mesh, and result fields (e.g., displacement, temperature, and stress) produced as part of the solution. But, some of the data, especially attribute data, is more complex. Reference [ REF _Ref99284275 \r \h 4] gives a fairly comprehensive overview of attribute data, both how it is defined and its management requirements. Attributes are used to specify a wide spectrum of FEA parameters, including solution strategy (solver type, tolerances, adaptivity) and data management issues (e.g., sharing and versioning). Although the attribute data is relatively small compared to the solution output, FEA attributes and the associated metadata are fairly complex involving inheritance from parent structures, and involving complex relationships with neighboring model components and with data from other simulations or from measurements. FEA attributes often have context, scope, and behavior metadata. The attributes reference-frame is a good example of an attribute context attributes on curved surfaces are often more easily described using a local non-Cartesian coordinate system, like polar or cylindrical coordinates. An attribute assigned to a volume may be inherited by all voxels in the volume, or by all its bounding faces. Attribute hierarchies and grouping allow sharing and reuse. Time dependent attributes are common. Attributes are also defined as equations that use other attributes as well as references to external resources via hyperlinks, XPointers [ REF _Ref101066790 \r \h 33], and WS-Addressing [ REF _Ref101066802 \r \h 34]. FEA attributes and metadata are inherently multi-faceted and do not easily lend themselves to a tabular representation. Attributes seem to be well suited to the capabilities of XML and the related X* technologies (XML schema [ REF _Ref101412012 \r \h 42], XPath [ REF _Ref101412027 \r \h 38], XSLT [ REF _Ref101412040 \r \h 41], XQuery [ REF _Ref101412056 \r \h 40, REF _Ref101412059 \r \h 39]). This idea is explored later in this series when we talk about SQL Server 2005 features. We are primarily interested in unstructured meshes meaning that the local (graph) structure of the mesh (the number of neighboring vertices) varies from vertex to vertex. Structured or regular meshes allow the data to be stored in a dense array but adaptive and unstructured meshes require sparse-array or database representation where each voxel or vertex is an independently addressed item. In contrast to a structured mesh, an unstructured mesh is data and metadata at the same time and the metadata cannot be separated from the data. The entire mesh and most of the attributes serve as input to the FEA solution phase. The mesh is the largest input component its size depends on (1) the resolution of the discretization, (2) the geometric complexity of the model, and (3) the desired accuracy of output. In practice, the mesh varies between hundreds of megabytes to several gigabytes. Whats more alarming is that the solution output can be several orders of magnitude larger than the input. In this paper, we are interested in large scale FEA, i.e., meshes with millions of elements resulting in systems of millions of equations. The necessary memory and processing resources needed to obtain a solution in finite time are typically not found in workstation class machines. Large multi-processors in the form of clusters of workstations or supercomputers are used instead. Two problems present themselves when working with these large problems and systems: We need an intelligent and scalable (with the size of the objects and the number of nodes) way to move data between the different levels of the memory hierarchy (cluster nodes memory, local disk, networked file servers, database servers, and tape library). By intelligent we mean that it should be easy to split I/O streams and determine which subset of information needs to go where. Post-processing typically starts from results in permanent storage. The sheer size asks for analysis in place (including the necessary CPU power) and/or an efficient querying capability. Apart from size-driven constraints the importance of a simple, data-independent definition and manipulation language can hardly be overstated. To fully appreciate this, lets review some basic facts about relational databases. Relational Databases The six phases of Figure 1 are connected by data flows. In general the whole process is data-driven. Traditionally, when one changed anything in one phase it had a ripple effect downstream requiring all the other programs in the pipeline be revised to handle the new data format. As the complexity of FEA systems increases, this tight coupling between programs and data formats becomes untenable. One of the driving factors behind the development of the relational model was a desire to simplify application design and maintenance. Developers noticed that frequently a substantial part of an (enterprise) applications code was non-problem-oriented code, code that only parsed, reformatted, or transformed data rather than doing any semantic computation. At the heart of the problem was the poor separation of the physical and logical data layout from the programs [ REF _Ref101000831 \r \h 32, REF _Ref99194293 \r \h 1]. Databases solve this problem by introducing the concepts of schema and view. The schema is a logical and abstract description of the data. A view is a mapping from the schema to a particular data layout as seen by one or more applications. Different programs may want different views. These different views can be automatically created from the same underlying schema and database. In addition, the schema can evolve, adding new information, while still providing old programs with the old data views. This data independence was a major reason commercial applications adopted database technology. As FEA systems become more complex and more interconnected, this desire for data independence will be a major reason for using database technology in FEA systems. Current file-oriented FEA systems represent schema metadata as structures (typically in .h files). There is no automatic connection between the files and the corresponding metadata. There are no good tools to evolve the file representation. When one wants to change something, one must change the .h file, change the programs, and then reformat the data files. There are self-defining and portable file formats like HDF and NetCDF, but there is no good language support for a view mechanism on them. (HDF and NetCDF provide a simple schema mechanism but no view mechanism.) Both are intended for array-oriented data with simple attribute assignment. Several arrays (variables) can be included in a single NetCDF file, but relationships and referential dependence must be stored separately. NetCDF allows constraint-like definitions for variable ranges and extreme values. However, they are not enforced by the standard API. NetCDF is very good at accessing slices or array subsections. Indexing in a wider sense (which would lead to general non-array subsets) is not supported. Write access is limited to one writer. NetCDF can use underlying parallel I/O on some platforms but it is not an inherent part of the API or NetCDF package. In summary, HDF and NetCDF facilities may be adequate for the solution phase of simple structured meshes. Even for those simple problems they do not address the issues of end-to-end analysis because they lack a view mechanism, metadata management, and indexing. Array-like structures are inadequate for unstructured meshes. Although many mesh constituents can be represented in tabular form, the (irregular) relations between them are an inherent part of the model but cannot be expressed using simple index arithmetic. Most commercial FEA packages supporting unstructured meshes use their own proprietary formats, creating myriad formats/versions and conversion tools. The APIs to manipulate the objects in these files are buried in the corresponding application stacks. As a result, the only safe way to share data is to get a copy in your favored format. Unlike formatted files, database metadata is unified with the data in a database. Relational databases describe all data in terms of tables. Each table is a set of rows and each row has the same collection of columns. Each column has a name, datatypes, and a set of integrity constraints. Rows in a table are referenced through their identifier or primary key, which might consist of one or more columns (compound key). In general, SQL encourages associative and content-based access to data through predicates on the data values. Since for an application the primary key is the only means to reference the data and since applications can be insulated from the data by views, the application will continue to function correctly despite changes in a databases internal layout and even despite some external schema changes so long as the old data views can be computed from the current data. The objects in a relational database are defined and manipulated using the Structured Query Language (SQL). SQL is a fairly simple language compared to, say, C++ or even some scripting languages. It is a functional (as opposed to imperative) language, where one specifies what is needed as a query describing what is wanted rather than giving a procedure for how to get the answer. As other authors have pointed out, coming from an imperative language, the hardest part about learning SQL is to unlearn procedural habits. This means in particular: Think in terms of sets rather than items, think in terms of goals rather than paths, and think at a high level! Database systems also separate data access from storage representation. One can add indices and reorganize the data as the system evolves without breaking any programs. Indeed, the standard way to speed up a slow program is to add an index to speed its data access. Increasingly, the selection and addition of indices is an automated process, based on the workload. There are no language extensions or libraries ( la MPI [ REF _Ref101412136 \r \h 43] or OpenMP [ REF _Ref101412149 \r \h 44]) for parallel SQL. It is completely up to the optimizer and the database engine to detect and exploit parallelism in a query. Microsoft SQL Server 2000 an Example Relational Database System To make this article concrete, we describe our experience with a particular RDBMS, Microsoft SQL Server 2000. The approach described in this paper, can be implemented using almost any database system that has adequate quality, tools, manageability, performance, scalability, security, and integration with the existing infrastructure. Microsoft SQL Server 2000 [ REF _Ref88222570 \r \h 6, REF _Ref99194871 \r \h 7] is available on the Windows platform in various editions. SQL Servers dialect of the SQL language is called Transact-SQL (T-SQL) [ REF _Ref100462830 \r \h 22] and is compliant with the entry-level ANSI SQL-92 standard [ REF _Ref100391022 \r \h 20]. The built-in types include a variety of integers (1, 2, 4, and 8 bytes long), as well as single- and double-precision floating point numbers. Fixed and variable-length data types for storing large non-UNICODE and UNICODE character and binary data (like images) are supported. T-SQL can be used as a programming language for stored procedures and other user-defined functions. User-defined functions are stored with the data in a database and can access it efficiently since they execute as (sandboxed) threads within the SQL process. T-SQL can invoke other processes, send mail, and generally do almost anything (subject to security restrictions), but best practices argue against this. The standard advice is to just use T-SQL to encapsulate data in the database. External dynamically linked libraries (DLLs) can be accessed from SQL Server through extended stored procedures, but again, this is considered guru-programming and best-practices recommend against it. The general advice is to use SQL as a non-procedural programming language to retrieve exactly the subset of data that you need (retrieve the answers rather than the intermediate results). For example, when a computation is working on a particular region, it should retrieve only the requisite attributes for that region. SQL Server running on top of Windows supports symmetric multi-processing (SMP) architectures (like the 64-way Unisys ES7000 [ REF _Ref100544504 \r \h 28]). Effective auto-parallelization is the (un-fulfilled) dream of every MPI or OpenMP programmer. In T-SQL it is reality: depending on the parallelism inherent in a query and depending on the available resources, the SQL optimizer will generate and schedule multiple tasks (threads, fibers [ REF _Ref100655704 \r \h 31]) for a single query. If the hardware resources are adequate, SQL can deliver nearly linear speedup on an SMP. Another means to exploit parallelism in large SQL Server databases are so-called distributed partitioned views (DPV) [ REF _Ref99194871 \r \h 7]. A logical table (view) might be physically spread across a cluster of multiple linked servers. A query can be directed against any server in the federation, which will determine where the data are located and the query is to be executed. Features like high availability, replication, data mining, and data cubes are supported in SQL Server but are beyond the scope of this discussion. SQL Server can be accessed from programs running on Windows using the traditional ODBC/JDBC libraries or the more object-oriented OLE/DB and ADO.NET interfaces. UNIX-based systems can interoperate with SQL Server via client APIs like ODBC or OLE/DB. Mapping an FEA Data Model onto a Relational Model Figure 2: A polycrystal model consists of many crystals (grains). Each grain is decomposed into tetrahedra (not shown). Tension is applied at the top surface of the cubical specimen. The bottom face is fixed in normal direction. To prevent rigid body motion, the corners are pinned (the corner closest to the viewer in two directions, the others in just one direction). The material properties assigned to grains and grain boundaries vary from grain to grain and boundary to boundary. The load is applied in increments (and/or cycles), and, after it reaches a certain level, some grain boundaries will start to de-cohere and ultimately fail (de-bond). The underlying database schema has about 60 basic tables plus views and several user-defined functions (see the third article in this series for more details). As outlined earlier, the objects in an FEA form a hierarchy implied by the topology, geometry, mesh, and attributes that map to physical fields. There are other mappings between the objects of the hierarchy, for example, how a topological face is decomposed into parametric patches and how a given volume is tessellated by tetrahedra. Well see several examples of complex topology and geometry in Part III that discusses, among other things, the representation of 3D models of metallic polycrystals in a database. Figure 2 gives a hint showing how geometry, material properties, and dynamics interact. Schema design is driven by data semantics and by the questions (queries) wed like the database to answer. A good starting point for database design is a list of Frequently Asked Queries (FAQ). There is no one FEQ list; different communities have different needs. However, there is a substantial common subset of typical questions among FEA applications. Reference [ REF _Ref99434875 \r \h 3] has an example of such a list and its implementation. The list includes simple adjacency queries as well as more advanced queries about geometric proximity and point-in-cell queries. We will see an example of an adjacency query below and come back to geometric queries in the subsection on indexes. Some geometric queries can be seen in action in an animation prepared by Chris Pelkie for the SC2002 conference [ REF _Ref99853901 \r \h 2]. The first step in mapping FEA problems into a relational schema requires a mesh representation. Roughly speaking, a mesh or grid is a collection of vertices plus connectivity, in other words, a graph. In addition, there is information about how a geometric curve is split into mesh edges and the parametric coordinates of the vertices on the curve. The graph structure often exhibits regularity at the local level: certain clusters of vertices are the corners of the simple shapes or elements (tetrahedra, hexahedra, etc.) that form the basis of the mesh. To translate this to relational database terms, a table of 3D vertices can be defined as follows: CREATE TABLE Vertices ( VertexID int PRIMARY KEY CLUSTERED, x float NOT NULL, y float NOT NULL, z float NOT NULL) Although the number of elements sharing a given vertex may vary from vertex to vertex, we know that every tetrahedron has exactly four vertices. Based on this observation, we can define a tetrahedra table as: CREATE TABLE Tetrahedra ( ElemID int NOT NULL PRIMARY KEY, v0 int NOT NULL REFERENCES Vertices, v1 int NOT NULL REFERENCES Vertices, v2 int NOT NULL REFERENCES Vertices, v3 int NOT NULL REFERENCES Vertices, CONSTRAINT Tetrahedra_UNQ UNIQUE(v0, v1, v2, v3), CONSTRAINT Tetrahedra_CHK01 CHECK(v0 != v1), -- Add the 5 other pair-wise comparisons ) This is a very compact definition for tetrahedra. Before we discuss its shortcomings, lets understand its content: Each tetrahedron can be represented as a quadruple of vertex identifiers (its corners). Each tetrahedron vertex ID (v0, v1, v2, v3) must indeed appear as a VertexID in the Vertices table (see the referential constraint). The same quadruple cannot be a representation of different elements (see the uniqueness constraint). A tetrahedron must be non-degenerate, i.e., no two vertex identifiers can be the same (see the six check constraints). For most practical purposes, that is all there is to say about a tetrahedron. The tetrahedra definition above specifies the relation between tetrahedra and vertices. One problem with the definition is that it is not in first-normal form (1NF) [ REF _Ref100490453 \r \h 21, REF _Ref100497671 \r \h 23]: representing the sequence of vertices {v0, v1, v2, v3} as attributes makes some queries awkward. For example, to find all tetrahedra that share a given vertex, the query would be: SELECT ElemID FROM Tetrahedra WHERE @VertexID in (v0, v1, v2, v3) A normalized version of tetrahedra can be defined as: CREATE TABLE TetrahedronVertices ( ElemID int NOT NULL, Rank tinyint NOT NULL CHECK(Rank < 4), VertexID int NOT NULL REFERENCES Vertices, CONSTRAINT PK_TetrahedronVertices PRIMARY KEY(ElemID, Rank), CONSTRAINT UNQ_TetrahedronVertices UNIQUE(ElemID, VertexID) ) This representation expresses the same facts as the previous definition but now the query is more straightforward: SELECT ElemID FROM TetrahedronVertices WHERE VertexID = @VertexID We could have obtained a normalized view from original table definition as follows: CREATE VIEW TetrahedronVertices AS SELECT ElemID, 0 AS Rank, v0 AS VertexID FROM Tetrahedra UNION ALL SELECT ElemID, 1 AS Rank, v1 AS VertexID FROM Tetrahedra UNION ALL SELECT ElemID, 2 AS Rank, v2 AS VertexID FROM Tetrahedra UNION ALL SELECT ElemID, 3 AS Rank, v3 AS VertexID FROM Tetrahedra Conversely, we can re-create the quadruple representation from the normalized relation: CREATE VIEW Tetrahedra AS SELECT ElemID, A0.VertexID AS v0, A1.VertexID AS v1, A2.VertexID AS v2, A3.VertexID AS v3 FROM TetrahedronVertices AS A0 JOIN TetrahedronVertices AS A1 ON A0.ElemID = A1.ElemID JOIN TetrahedronVertices AS A2 ON A1.ElemID = A2.ElemID JOIN TetrahedronVertices AS A3 ON A2.ElemID = A3.ElemID WHERE A0.Rank = 0 AND A1.Rank = 1 AND A2.Rank = 2 AND A3.Rank = 3 What do we do in practice? Either representation works well for small meshes (less than 100,000 elements) the virtual table (view) lets applications see the other perspective. For large meshes, we store both representations and use whichever performs better in a given context. FEA Data I/O The problems of moving data in and out of databases is often called the impedance mismatch programming language datatypes and procedural interfaces are a different world from tables and non-procedural set-oriented access. There has been a lot of progress in ameliorating the impedance mismatch over the last decade with languages like SQLJ and with interfaces like JDBC and ADO.NET. SQL Server supports several client APIs including ODBC and OLE/DB. Most scripting languages provide convenient libraries or modules for database programming. However, massive data load and dump operations demand the bulk copy client utility (bcp.exe), the T-SQL BULK INSERT command, or Data Transformation Services (DTS) for better performance (about 10x better). The most I/O intensive parts of FEA are: The initial loading of the mesh into the database. The attribute and input data generation for the equation solver. The dumping of analysis results to the database. Loading the mesh is a straightforward bulk copy and there is nothing particularly interesting or challenging about it. Communicating the mesh and attributes to each of the solver processes is more interesting, and moving the solution output to the database also requires some care. The solver is an ordinary MPI program running on the cluster of N (~100s) nodes. To run these programs without change, we need to deposit their inputs on the nodes local disks and harvest their outputs from their local disks. Before the solver runs, each node contacts the database and requests its partition of the mesh. The database responds with the result (a few tens of megabytes) from a simple JOIN of the full vertex or voxel table with the partitioning table filtered by partition. (In reality its slightly more complicated, because neighboring partitions share some voxels or vertexes.) Conversely, when the solver completes (or as it is running) the output data is asynchronously streamed from local file stores into the database. How do we get those partitions? A bootstrapping, two-step partitioning approach works well for us. It first generates a few coarse bootstrap partitions (typically 8 or 16) in the database using a fast but coarse partitioning method like Recursive Coordinate Bisection [ REF _Ref101412670 \r \h 45] written in T-SQL. Then the bootstrap partitions are refined using a high-quality partitioner like ParMetis [ REF _Ref100545821 \r \h 26] that, given a finite element graph and the desired number of partitions, maps each vertex and each voxel to one of the N servers. The resulting partitioning is used to scatter the mesh and attributes among the N cluster nodes. (As an optimization, the data is reorganized before being scattered such that the bootstrap nodes communicate only with disjoint node sets.) Bringing the solutions output data back into the database is decoupled from the job execution on the cluster. The solution output file data is first copied from the nodes onto scratch disks near the database and then bulk-loaded into the database. This is done using the Extract-Transform-Load (ETL) facilities of SQL Server (aka: DTS). It has packages that pull the data from the solvers to a staging area and then bulk load it to the database. It would be a waste of compute resources and a bottleneck if all the nodes attempted a bulk load simultaneously. Note that SQL Server does not (yet) replace a file server or a parallel file system. All it does is to largely eliminate non-problem-oriented code (all it takes to create almost any input format are a few queries!) and store the metadata, like partitioning, with the data. Dedicated I/O systems greatly accelerate the data transfer between file servers and cluster nodes. However, from an end-users perspective, this does not ease in any way his or her task to extract meaning from the data. Indexes High-speed query execution is the result of good design and good indexing [ REF _Ref100497671 \r \h 23, REF _Ref100539221 \r \h 24]. If the optimizer cannot come up with an efficient execution plan, a query will perform poorly no matter how fast the hardware. Our tables are big (millions of rows) and full table scans are devastating for performance but an appropriate database index can avoid such scans, taking the query to exactly the desired database subset. Indexes on a table work exactly like the index found at the end of a text book. It is common to implement them as B-trees [ REF _Ref100497671 \r \h 23] (B as in balanced.). For a clustered index, the leaves of the index tree are the rows of the table. For a non-clustered index, the leaves are pointers (bookmarks) to actual rows. The SQL query optimizer will automatically discover appropriate indexes and use them when executing the query. FEA geometric queries that determine which cell contains a given point are an easy application of indexes. In CAD tools or mesh generators, these queries are usually implemented using octrees. SQL can mimic an octree traversal (this is what the search algorithm does) as an index scan (a B-tree traversal) as follows. Lets assume we are given the following table of non-degenerate cells (boxes): CREATE TABLE Cells ( CellID int PRIMARY KEY, x_min float NOT NULL, y_min float NOT NULL, z_min float NOT NULL, x_max float NOT NULL, y_max float NOT NULL, z_max float NOT NULL, CONSTRAINT CHK_Cells_x CHECK (x_min < x_max), CONSTRAINT CHK_Cells_y CHECK (y_min < y_max), CONSTRAINT CHK_Cells_z CHECK (z_min < z_max) ) Our point-in-cell query would look something like this: SELECT CellID FROM Cells WHERE @x BETWEEN x_min AND x_max AND @y BETWEEN y_min AND y_max AND @z BETWEEN z_min AND z_max Without an index, a full table scan will be performed. A simple index that will considerably reduce the search space is: CREATE INDEX Idx_Cells ON Cells (x_min, x_max, y_min, y_max) Detecting the index, the optimizer will translate the query into an index seek plus bookmark lookup. More sophisticated geometric queries can be defined after all, not everything is a box! Also, space-filling curve schemes (Peano, Hilbert curves and others [ REF _Ref101412974 \r \h 46]) can be used to generate surrogate keys. Often fast lookups combine a cheap, coarse-grained search producing a small candidate list with an (expensive) brute-force search on a small subset. We use all these techniques to achieve good spatial indexes [ REF _Ref100542869 \r \h 27]. FEA Attributes and Metadata So far the discussion focused on dense tabular data which can be easily incorporated in a relational model. It is true that the bulk of FEA data fits this model, but our solution would be of limited use if we couldnt integrate the remaining 1% of mostly attributes and metadata. After all, the main argument for using a database is to unify the data and metadata and to provide a common store for both that all parts of the FEA can use. References [ REF _Ref99284275 \r \h 4, REF _Ref99279329 \r \h 5] explain that attributes come in many forms: boundary conditions, material properties, solver parameters, control information and so on. In most cases, it would be possible to force them into a tabular form, but that would be a clumsy and brittle representation, and, for the lack of manipulative power, the management API would have to be implemented outside the database. This is another example of the impedance mismatch between traditional database models and real applications. XML and the related X* technologies (XML schema, XPath, XSLT, XQuery etc.) are ideal candidates to bridge this gap. SQL Server 2000 support for XML [ REF _Ref100645669 \r \h 30] is limited to conversion from relational data to XML (FOR XML, XML templates) and the extraction of relational data from XML documents (OPENXML). Put another way, XML is an add-on to SQL Server 2000 rather than being a fully integrated datatype. The newer version of SQL Server (2005) and newer versions of other systems like DB2 and Oracle have much better integration and support for XML. Part II of this series shows how we have used XML and SQL Server 2005 to solve our problems! Before that, we used the text data type to store ASCII representations of XML documents in a table and did the XML processing using the .NET Framework on the client side. The image data type was certainly adequate for storing binary data, including manually serialized objects. This brings us to the question of user-defined types (UDT) in general. On page 239 of [ REF _Ref99194871 \r \h 7] we read: A user-defined datatype provides a convenient way for you to guarantee consistent use of underlying native datatypes for columns known to have the same domain of possible values. This is an interesting way of saying that there are no real UDTs in SQL Server 2000. In fact, there are none in the relational model and they are against the spirit of normalization and non-procedural programming. The SQL-99 standard introduced collection types like ARRAY and ROW which would allow arrays and C-struct-like UDTs. In Part II, we will see that almost any public class of the .NET Common Language Runtime (CLR) can be used as a UDT in SQL Server 2005. This does not mean that the tabular structure will be submerged in or replaced by the UDT. To get all the SQL performance benefits (sorting, indexing) and not overly suffer from CLR invocation overhead, a well thought-out table and UDT co-design are necessary (see Part II). Practical Considerations This subsection gives some practical advice about using SQL Server 2000 for FEA. The Microsoft SQL Server 2000 Desktop Engine (MSDE 2000) is available as a free download from Microsoft [ REF _Ref101248396 \r \h 35]. If you are just starting, make sure you start with SQL Server 2005. The tools and basic functionality are identical to the enterprise editions, but it is limited to storing 1 GB databases. For academic users, the MSDN Academic Alliance gives you (nearly) free access to all the development tools and server products, including SQL Server and the programming tools. The client tools of all SQL Server editions include the Query Analyzer, Enterprise Manager, and Online Books, as well as a collection of command line tools. The Query Analyzer is a graphical shell which can be used for query execution and debugging, as well as for analysis and profiling of execution plans. The Enterprise Manager is the main administrative tool. It can also be used as a design tool and to generate diagrams of database schemas. It is helpful for SQL novices to use a graphical design tool, but we recommend you take control and become fluent in T-SQL. Databases grow automatically, but you may not want to unconditionally rely on auto-growth. The default growth rate is 10% and, depending on your needs, you might want to set it to something more generous or manually adjust the size. SQL Server 2000 does many good things for you without you knowing about it, in some cases more than you need. After all, it was designed to perform well in an enterprise environment, doing online transaction processing (OLTP) or data warehousing. Naturally, it can do many things we do not or cannot take advantage of that may get in our way. For example, by default SQL Server keeps a log of all your changes until you archive the log. This enables you to go back in time to pretty much any previous state of the database. (Version control systems for files are not quite as good, but similar.) This luxury does not come for free, i.e., without a performance impact, but it is the (correct) default behavior. For the data access and update patterns in FEA described in this paper a more relaxed simple recovery model can be applied [ REF _Ref99194871 \r \h 7]. Column and table constraints reflect important assumptions about the data. An FEA database typically has what we would call primary and derived tables. The former are populated through bulk operations from raw (in general, unchecked!) data. Checking constraints at this level is of particular importance. The derived tables are generated based on the primary tables and the validity of the imposed primary constraints is assumed. For performance (and after testing!), you might want to keep the constraints on secondary tables to a minimum. Otherwise, like it or not, on any INSERT, SELECT, UPDATE, etc., SQL Server will check these constraints and (if they are large) the derived table generation might be slower than expected. During insert operations you can aggressively lock these tables using, for example, the TABLOCK hint. As far as hardware goes, you should get as much memory and as fast a disk subsystem as you can afford CPU speed is less of an issue than I/O and memory. To start, just spread all the data across all the disks, but if you have performance problems, segregate log files to different drives. If the hardware is sufficiently reliable (if you can tolerate reloading or regenerating the data), use RAID 0 (striped disks) to maximize I/O performance. Though not formally ANSI/IEEE 754 [ REF _Ref101255153 \r \h  \* MERGEFORMAT 36] compliant, SQL Server 2000 does a good job for floating point arithmetic and conversion of string representations of floating point numbers, as long as you stay within the limits set out by the standard. Caution is advised, if your application relies on standard-conforming exception handling: the SQL Standard and SQL Server 2000 have no notion of NaN. Normalization [ REF _Ref100490453 \r \h  \* MERGEFORMAT 21, REF _Ref100462830 \r \h  \* MERGEFORMAT 22] is an important concept in relational design. The goal is to eliminate redundancy in the representation of facts, which otherwise might lead to inconsistent updates. (Since the facts to be modeled determine normality, it is inaccurate to speak of the normality of tables independent of the underlying facts.) Performance might sometimes overrule normalization, but non-redundant representation should be the starting point of (and will ease!) your design. As in real code, avoid premature optimization! Finally, dont be fooled by the almost exclusive coverage of business-related applications in the (vast) database literature. Learning the basic moves is not very difficult, but we acknowledge that, for the time being, the supply of nutritious scientific or engineering examples is rather limited. You can help change this! Final Remarks This first part in the series describes how our FEA pipeline uses SQL Server as a common data store for both the simulation data and the metadata. It uses SQL Server as a data-shell, as the communication medium and glue among the six solution phases (modeling, meshing, attribute generation, solution, post-processing, and visualization). Subsequent articles will describe how the design has evolved to leverage the new object-oriented and XML features of Object-Relational database systems. Though it might seem straightforward, it is not easy to quantify the advantages of the approach advocated in this article over the traditional approach to FEA data management. Metrics suggesting themselves are development time, code size, maintainability, administrative and infrastructure cost, and turnaround. Among the implicit assumptions would be a fixed problem size and complexity, equivalent task structure, and the same underlying hardware. In practice, this is hardly ever (read: never) the case. In our own simulations, we have seen the problem sizes grow by more than two orders of magnitude over the last five years. The hardware to accommodate these problems grew proportionally. The search for data management alternatives was first and foremost driven by this (continuing) drastic increase in problem size and complexity not by the desire to write a paper. (In that sense, we threw away the ladder for something better, after we climbed up on it.) There are many moving parts in an FEA: geometric modelers, mesh generators, attribute managers, and visualization tools are under constant development, and new requirements are emerging (Web services). This development should be as concurrent and decoupled as possible. The individual components deal with different subsets of the data, but must not be locked into a particular view or subset because requirements might change. The fundamental data management question is how we can efficiently define, debug, diagnose, verify, select, manipulate and transform data, and ultimately guarantee the sanity and integrity of the data. Without a well-defined data model these terms dont mean anything and separation of the metadata from the data has to be paid for, with among other things, replicated and brittle non-problem-oriented code. If we had to summarize the key lesson learned in one sentence, it would read like this: Using a database-centric approach puts you in control of your data regardless of their size. Acknowledgements We gratefully acknowledge the support of Microsoft and Microsoft Research. The first author enjoyed the support of the Cornell Theory Center, and of the head of the Cornell Fracture Group, Professor Anthony R. Ingraffea. He would like to thank all members of the Cornell Fracture Group for years of inspiring collaborations and for their continued help in understanding the challenges of engineering. References  HYPERLINK "http://research.microsoft.com/research/pubs/view.aspx?tr_id=860" Gray, J. et al.: Scientific Data Management in the Coming Decade. Microsoft Research Technical Report MSR-TR-2005-10 (2005)  HYPERLINK "http://www.tc.cornell.edu/~heber/movies/FView.wmv" FView - A video demonstrating the capabilities of an FEA viewer prepared by Chris Pelkie for the SC2002 conference, Cornell Theory Center (2002)  HYPERLINK "http://www.cs.uvm.edu/tr/Papers/CS-02-7.pdf" Lee, B.S., Snapp, R.R., Chen, L., Song, I.L.: Modeling and Querying Scientific Simulation Mesh Data. University of Vermont Computer Science Technical Report CS02-7 (2002) OBara, R.M., Beall, M.M., Shephard, M.S.: Attribute Management System for Engineering Analysis. Engineering with Computers 18, pp. 339-351 (2002)  HYPERLINK "http://www.nafems.org/publications/downloads/benchmark/july_2003/data.pdf" Rennet, A., Zieglar, M.: Data Management Systems for FEA Data. BENCHmark Magazine July 2003, pp. 8-12 (2003)  HYPERLINK "http://approjects.co.za/?big=sql" http://approjects.co.za/?big=sql Delaney, K.: Inside Microsoft SQL Server 2000. Microsoft Press, ISBN: 0735609985 (2002) DeBetta, P.: Introducing Microsoft SQL Server 2005 for Developers. Microsoft Press, ISBN: 073561962X (2005) Beauchemin, B., Berglund, N., Sullivan, D.: A First Look at Microsoft SQL Server 2005 for Developers. Addison-Wesley, ISBN: 0321180593 (2004)  HYPERLINK "http://www.opendx.org" http://www.opendx.org Marsh, D.: Applied Geometry for Computer Graphics and CAD. Springer, ISBN: 1852330805 (1999) Brenner, S.C., Scott L.R.: The Mathematical Theory of Finite Element Methods. Springer, ISBN: 0387954511 (2002)  HYPERLINK "http://www.engr.ncsu.edu/SMiRT-16/1915.pdf" Zhou, Y., Yan, F.: A General Finite Element Analysis Data Management Technology. Proceedings 16th Intl. Conf. on Structural Mechanics in Reactor Technology, August 12-17, 2001, Washington, DC, USA  HYPERLINK "http://www.stanford.edu/~junpeng/research/journal_paper2.pdf" Peng, J., Liu, D., Law, K.H.: An Online Data Access System for a Finite Element Program.  HYPERLINK "http://www.stanford.edu/~junpeng/research/overview_Com_Str.pdf" Peng, J., Law, K.H.: Building Finite Element Analysis Programs in Distributed Services Environment.  HYPERLINK "http://www.sc-conference.org/sc2004/schedule/pdfs/pap160.pdf" Tu, T., OHallaron, D.R.: A Computational Database System for Generating Unstructured Hexahedral Meshes with Billions of Elements. In Proceedings SC2004, November 6-12, 2004, Pittsburgh, PA, USA.  HYPERLINK "http://www.cfg.cornell.edu" http://www.cfg.cornell.edu Heber, G., Lifka, D., Stodghil, P.: Post-Cluster Computing and the Next Generation of Scientific Applications. Proceedings SCI 2002/ISAS 2002, July 14-18, 2002, Orlando, FL Chew, P. et al.: Computational Science Simulations Based on Web Services. Lecture Notes in Computer Science, Vol. 2660, pp. 299-308, Springer (2003) Gruber, M.: SQL Instant Reference. Sybex, ISBN: 0782125395 (2000) Otey, M., Conte, P.: SQL Server 2000 Developers Guide. McGraw-Hill Osborne Media, ISBN: 0072125691 (2000) Henderson, K.: The Gurus Guide to Transact-SQL. Addison-Wesley, ISBN: 0201615762 (2000) Gulutzan, P., Pelzer, T.: SQL Performance Tuning. Addison-Wesley, ISBN: 0201791692 (2003) England, K.: Microsoft SQL Server 2000 Performance Optimization and Tuning Handbook. Digital Press, ISBN: 1555582419 (2001) Tow, D.: SQL Tuning. OReily, ISBN: 0596005733 (2003)  HYPERLINK "http://www-users.cs.umn.edu/~karypis/metis/parmetis/index.html" http://www-users.cs.umn.edu/~karypis/metis/parmetis/index.html  HYPERLINK "http://research.microsoft.com/research/pubs/view.aspx?type=Technical%20Report&id=736" Gray, J. et al.: There Goes the Neighborhood: Relational Algebra for Spatial Data Search. Microsoft Research Technical Report MSR-TR-2004-32 (2004)  HYPERLINK "http://unisys.com/products/es7000__servers/index.htm" http://unisys.com/products/es7000__servers/index.htm Ben-Gan, I., Moreau, T.: Advanced Transact-SQL for SQL Server 2000. Apress, ISBN: 1893115828 (2000) Griffin, J.: XML and SQL Server 2000. New Riders, ISBN: 0735711127 (2001) Russinovich, M., Solomon, D.: Windows Internals. Microsoft Press, ISBN: 0735619174 (2004) Date, C. J., An Introduction to Database Systems, Addison Wesley, ISBN: 0321197844 (2003) Wilde, E., Lowe, D.: XPath, XLink, XPointer, and XML. Addison-Wesley, ISBN: 0201703440 (2003) Cabrera, L.F., Kurt, C.: Web Services Architecture and Its Specifications. Microsoft Press, ISBN: 0735621624 (2005)  HYPERLINK "http://approjects.co.za/?big=sql/msde/downloads/download.asp" http://approjects.co.za/?big=sql/msde/downloads/download.asp Overton, M.: Numerical Computing with IEEE Floating Point Arithmetic. SIAM, ISBN: 0898714826 (2001) Joseph, J., Fellenstein, C.: Grid Computing. Prentice Hall PTR, ISBN: 0131456601 (2003) Holzner, S.: XPath Kick Start: Navigating XML with XPath 1.0 and 2.0. Sams, ISBN: 0672324113 (2003) McGovern, J. et al.: XQuery Kick Start. Sams, ISBN: 0672324792 (2003) Katz, H. et al.: XQuery from the Experts: A Guide to the W3C XML Query Language. Addison-Wesley, ISBN: 0321180607 (2003) Mangano, S.: XSLT Cookbook. OReilly, ISBN: 0596003722 (2002) Binstock, C., Peterson, D., Smith, M.: The XML Schema Complete Reference. Pearson Education, ISBN: 0672323745 (2002) Snir, M., Gropp, W.: MPI: The Complete Reference. MIT Press, ISBN: 0262692163 (1998) Chandra, R. et al.: Parallel Programming in OpenMP. Morgan-Kaufmann, ISBN: 1558606718 (2000) Berger, M., Bokhari, S.: A partitioning strategy for nonuniform problems on multiprocessors. IEEE Trans. Computers, C-36 (1987) 570-580. Sagan, H.: Space-Filling Curves. Springer, ISBN: 0387942653 (1994)  For non-linear simulations results are typically stored at the Gauss point level. Each Gauss point hosts a state variable holding S floating point numbers. For N quadratic tetrahedral elements using G Gauss points each with S state variables, the output will include at least N"S"G double precision floating point numbers (8 bytes each). For example, a 3D material stress calculation might have S = 12 values for the stress and strain tensors, and G = 11, so about 12"11"8 ~ 1,000 bytes for each of the N tetrahedral elements. The output consists of many samples of these values during the solution. If T time samples are taken, the solution output is T"N kilobytes.  The next version of the product, Microsoft SQL Server 2005, will ship later in 2005. In Part II of this series, we will highlight the new features and extensions beneficial to FEA. Some of the shortcomings with respect to FEA modeling found in SQL Server 2000 have been addressed as well.  The order of the vertices in a quadruple representing a tetrahedron defines an orientation of the element. However, any even permutation of the vertices defines the same orientation. This fact, for example, is not captured in the above table definition and the insertion of an even (or any non-identical) permutation of a previously inserted element would not be detected as an error. Also the fact that two tetrahedra overlap or that there are unintended gaps would not be detected.  There are five basic normal forms.  The Version 1 of the database interface in the .NET Framework, called ADO.NET, is not intended to handle large datasets and lacks support for bulk operations. ADO.NET 2.0 and SQL Server 2005 address both these issues.  On extremely rare occasions, a query might perform poorly because of server configuration errors or hardware limitations. Windows and SQL Server 2000 ship with excellent diagnostic tools to detect this!  If we had defined the index to be a clustered index, no bookmark lookup would be necessary. In SQL Server, the number of clustered indexes per table is limited to one.  A heroic effort to introduce complex arithmetic on SQL Server 2000 can be found in [ REF _Ref100637708 \r \h 29].  Beware that the default behavior of bulk operations is to disable constraint checking (for performance). You can either check the constraints manually, with a query, after the bulk operation (recommended) or force the checking during bulk loading (not recommended).  Indexes certainly work no matter if the data pages are resident in memory or on disk. We have worked with databases of 2 TB on machines with 4 GB of RAM. Of course, the more you can hold in main memory the better.  Ludwig Wittgenstein, Tractatus Logico-Philosophicus, 6.54      PAGE 12 STYLEREF \lauthor \* MERGEFORMAT Gerd Heber and Jim Gray  STYnop{     ^ i j z { ŶŤskcXMkMEMhGCJaJhV{h1CJaJh1h*B*CJaJph#jh1h1CJUaJjh1h1CJUaJh1h1CJaJh1h1CJ\aJh1hV{h15CJ aJ h1h15CJaJh1CJaJKnop{   K ^ _ j { | $]^a$gd1gd1*gd1$]^a$gd1$a$gd1z O r K ^ gd,%sP22Eƀf]2^2gd,%sgd=E*gd=Egd=E$a$gd=Egdv_v$a$gd1 + O r   , ? E K ^ f g h z |tldh'1h&6h'1hk}6h'1h$6h'1heo36h'1h/6 hT6h'1hT6h'1h26h2h{f/h2h=E0J8 h0(h=Ehh h=E0J+>*B*phjh h=EU h h=Ejh h=EUh0(h=E5CJaJh=EhM/'  F J ^ j k v    % / 0 k  ǿǷ}ume`eXh'1hT6 hQ6h'1h$^6h'1ht6h'1h>e96h'1hr6h'1he6h'1hv6 hT6 hr6h'1h^6h'1hO6h'1hF+6h'1hl76h'1h06h'1ho6h'1hN6h'1hn$6h'1hVC6h'1hVx6h'1hk}6h'1h&6 5>Clº򕪍}umieieieahch{f/h=Ehs{hN5h'1h6h'1hjU6h'1hM16h'1h,6h'1hT6 hs{6h'1h6h'1hdh6h'1hk6h'1hyE 6h'1h6h'1hj6h'1h/"6h'1h!_6h'1hy]86h'1h[6 hT6h'1hmq6%'Jgh*.34 ,/0=D  !"JPQRjk{|}~̷̫̠̿h=Eh8,ah jhU2UjhU2Uhh huhyYhU2hU20J.hU2hVhhh Gh%hc9hp1HhFshgeqh{f/hch-:3 !V$&''D(c*++,.12Z4gd<,gdg=gdyR h^h`gdlh^h`gdlgd=Egd0Tgd=Egd'vgd=Egd $0@BC[\]^_`ayz{|}~9:Z[dkp()3BDŽɽhnh@ch6hZBh5Tjh=E0J.hhB7h%h(yjh}qUh"jh"UhTZh8,aj)h}qUh?A[jh?A[UhV^h0ThYCh&hn=h=Eh{f/2DE]^_`abc{|}~ *29GN]_ķijįħ䟧Ćjh,%sUmHnHujh}qUjh]Uh]hHh[e<hUh5Tjh=E0J.h%h=Eh0XhB70J.hB7hnjh}qUh8,ajh}qUhMjhMU3 *I,Eh{}'0236Nkl123<MOؼإhvhj+ h'vh'vh2h_+sh0Th h8,ajh$SUh}jh}Uh@4h5hluh<`"hc6hFh20GhwhYfh>0hh%hB7h6h'v4OVW[\bhrstu    '()ؾسبܤɜzjrh$SUjh[Uh[jh$SUjhXUhXj|h#Ujh#Ujh#Uh8,aj h#UhJjhJUhOh hvhh-25hj+hZ0)*+,-EFGIJKLdefhijk%&'/3BFahƾƺƶΞhkhEVhSzh> h%hLhfhgh#h5)OhbhZhbNahhx/hnQhh&i&j&n&y&&&&&&&&&&''&'''D'F'J'V'v''''''((($((()(>(C(D(R(S(Z(\(](a((((((((((((ȷhOCchOCcOJQJmH sH hw^Jh|Rh[gh$wh5h^UhEOQh$w0J.hOCchd*<hJ`]h|+h|Ph;hh/Tnh=Ehz9hhJDhw h>0hDm[h0T5((()) ) )))()))*),)-).)1)8)P)T)U)))))))))** *!*+*2*B*E*K*`*a*b*c*d*ÿÿ{wnh,h0J.hh`h[ohah0J.hhXhQ:hWLhFVh8,aj h~bUh}-jh}-UhowhOCch$w"hOCcCJOJQJ^JaJmH sH hOCchOCcOJQJmH sH hOCcOJQJmH sH h0-OJQJmH sH )d*m*w*{*|***************++++++!+*+4+:+<+@+J+K+W++++++,,,,,,,,,,,-)-C-¾ֶҶ֩֩֍։֍օօh%dhdhyh}hy0J.h}hl0J. hl0J.hlh $Uh0J.hhLhD/hhh|5hQth*eh<,hx>h`hY;h`0J.hk5hk50J.6 hk50J.hY;hx>0J.4C-O-Q-R-v----------...\.].{.}.../// /7/:/J/R/S/W/e/z///////////0 000*0w0x00000000111#1$171E1F1I1J1i1j1ȼԼԼԳ̼h\Sh=E0J.h&ohu"hb9h&h~hhIh=EhAdh<h<,hbhx>hh0;$h:h%dhFj11111111111111111111122222(2)2+2,2627282B2K2_2u2v222222222222224Y4Z4e4hhaho@h_f^hhTWhM~hVh;hYh*h^Uh|h 4hNVhShN *h\Sh8,ajV hUh*jh*Uhg=h 7h=Eh~hh<,6e4f4~444444444444660646666 77*73747576797777777777777888086878;8@8c8g8j8k8o888ԠhmUh hhwhz hnhhZhTHhbh[~hyhlhph:h{+h}hKhahu"h^Uhr `h8,aj hUhjhU78888888889 9(9W9X9l9m9o9p99999999999999999999=:>:~:::::::::::Բؽ讪ŐjF hSlUh6ljh6lUh hkh~+l hVhwh/hj hW*UhpHhTh8,ajL hW*Uh;jh;Uh*}hUhahlh`bhQ[h{hw1Z49;=?yABCDWRgdEsI$ & FEƀ1b.gdK}AI$ & FEƀ1b.gdK}Agd=Egd$<gdM3gd::::::::::::;;;;;;!;#;$;=;>;?;A;B;C;D;];^;_;a;b;c;d;;;;;;;;;;<<!<%<&<Ǧ~zhbih5h9hRhr/hV0hrf0J.hrfhd hh hVhwj:hSlUj hSlUh| hkh~+lj@ hSlUhgj4hLrh8,aj hSlUh6ljh6lUhY0&<(<A<J<h<i<<H=====>->.>3>W>Y>Z>m>q>>>>>>>>>>>>???$?9?:?\?e?l?z????????1@2@4@U@ÿûǷh8(hhZyhzhB h$<h$<jh[20JUhK;h:PhXdh h~h0[h hAhz2heh<h$< hM3hM3 hjx}0J hC0J hr/0Jhv?hRhr/4U@|@@@@@@@@@A$A%AEAwAxAyAAAAB B(B0BEBGBSBTBhBpBxBzBBB?CPCjCCCCCCCD,D?DEDFDxDӿӻӷӳӫӧh2KhAXhrKh,hEsh3hu3h#Oh"e^h+h@hLh1JhX`hb.h|hXh38~h$GlhBhahK}Ah`h]KhKh8(hO(,hOh__hh0J.h0xD}DDDDDD E EZE[EEE2F;FhkPh=E hK}AhEsh2Kha} h y2DD=FJK'Q{SVY[ \M\] `cgbh\iill$&`#$/Ifgdgdgdjgd6gd=EGGGGGGGGGGGGGHHHH,H-H.H0H1H2H3HKHLHMHNHOHPHQHRH\H~HHHHHHI@IIIIIIII,h8,ajhP UjhE UhE ht'hE h<hm\hihNVhz%2EJFJHJMJ^JKKKKJLKL~LLLLLL@MAMMMMMMMMMMMNNNN N)N.NcN|N}N~NNNN&OAOpOqOOOOOOOȼĬĬԜh[hYAh3n?h hc]6h<hchZDhD]hho6hVhMhShJ;h{<hlhdK9h3?h3wh>hVfhk$whk\hIh\}h*hmD6hmDhE h*4OOOOOOP PPP&Q'QOQ\QcQdQrQsQxQQQQQQQQQQQQQQQ'R(R8R9Rh2hEh`h@bhhHZbh#X.hhhy hyhj hyhyh'NhE hk\hlh]4h[:zS{S|SSSSSSSSSSSSSSTTTTTTTUUUUUUUUUUVV0VgViVVVVVVVW WWCWGWĽĹ~zh?iIhj\hU-hq;hh:8hK}h hh8yh hUH%0J. hr(0J. hj\0J.hdhd0J.hVhdhhxhWhMhLhj\h>hsx0J.hsxh `:hzK hQhr(h)th Zvh hL3h.h h*43[4[;[=[>[W[X[Y[[[\[][g[i[j[[[[[[[[[ \ \\#\1\;\K\L\M\\\\\]]`]j]]]]]]]]]]]]]אjhUhb=jhb=Uh/hR hZr|hj\jhml0JUh1hj\hxCh7qZ hr(hr(hEj,hSlUh8,ajhSlUhf;'jhf;'Uh hr( hJ<^J2]]]]]]]]^^^,^.^V^u^w^x^^^^^^^^^^^^^^^^^^^^^^_ _%_&_'_<_A_B_U_ɞɚ咚Ƀ{w{hB hUhz7hjhUUjhUUhUh1h<hOgjh qUh?jh?Uh@hrhh ,h>h;;hvdh5KhRh/h8,ajhb=Uj$hUhb=.U_V_a_b______ ` `m`n`o`` a a aaaaab/b0b@bbbcbbcc+d4dEdKdYdddkdldqdxdzd{ddȸд~vrhvjhvUhwhr]hxeh1h*O%hpnh5shk/h5s0J.hk/h[0J.h[h`h9'h ;h'&h._RhT jh2d&h>4)hK*Yhq&hJPh)h6h`hhIh;t_hQahz7hK+dddddddddddddddddeeee2e;eGeTereveeeeeeeeeeeeeeeeeee%f&f*f@fIfJf蘠hejh|UhwnpjhwnpUh~'h&#hh}|Lh2+bh1hQ,ch hj hh0Xh>h=hnhch h5shxehwh8,ajhvUjhl U2JfSfXffffffffffffffffg'g?g|ggggggggggh8hD&h6hQh8,ajh|UhIv@jhIv@Uh mmhk/h0J.h _h1iiiiiiiiiiiiikkkkkkwllllllllllllmmm7mCmSmTmmmtmmmmmnnnnn$n+n,n/n0n¾ºh mh:fhL[h(0h>0hh~hSh$h/Hhj0hD.h'%h9'hIhVhMsMjhh>h>h14 hh14 h145hQ4dh1455llllllloohrta\\\\gdhvkd$$Ifli0.$ t 6`0644 la$&`#$/Ifgdv?v@vLvWvZv\v]vavhvpvqv|v~vvvvvvvvvvvvvvvvvvvvvvvvvvvvww֪ҟҔҪ֪z֪zhnh)SB*phhnh)SB*phh)Shnh/TB*phhnh/TB*phh}PhYh5B*ph hj"jhYhYhYB*ph hj"jh5h/Th%w h:h5hT"hnhT"B*phh5hMsMh"oh6d0www wwwww#w-w0w1w0hnh:h6Y h6Yh6YhhhnhwKB*phheYh%wmH sH heYhwKmH sH heYhwKB*mH phsH hwKhnh)SB*phhnh)SB*phh)Sh}Ph%w,x%x6x7x8xOxWxvxxxxxxxxxxxxxxxxyyyYyayyyyyyyyyyzz?z@zܺܥ}yoykh_jhO:0JUhyXh~"hL4h[h>s hi5+hXlh|/hwhh)xh2V h~hYCJOJQJ^JaJ he 7haCJOJQJ^JaJ hYhYCJOJQJ^JaJhYhB*~hCnhh5KhO,hqhD_hq)@zBzCz]z_zjznzzzzzzzzzzzz{{{{{{{!{"{#{%{&{'{({){*{C{m{{{{{{{{{{{{{ƻʷʳҜ}h%whYNdB*phhXlhBhkhn8h_hWmjhJTUjhr!Uhr!h8,ajvhl UhDjhDUh&E.jh}r0JUhr[hYh hG~dhIh1hGhMsM/{{{{{{||| | |||| |4|B|V|b|{||||||||||||||||||||||||||}}}'}(}5}6}7}9}:}ÿڿÿڿÿÿڿÿÿڥhcrh}h%whz+B*phhz+h%wh_:KB*phh_:Kh%whw`B*phhw`h%whw`B*phhIh hh%wh%whYB*phhNh%whYNdB*phhYhYNd5|7}v}y}}0~~~~NK0$$EƀcFgd%w 0$$gd%wgd+F0EƀcFgd@gdlO0gdI0gd%w:}D}E}]}c}u}v}w}y}}}~}}}}}}}}}}}}}}~~~0~~~~~~~~~~~~~~~~~z~z~z~z~zvkvh%whB*phhhih%whiB*phh+h%wh@h%wh@B*phhV(hO*hHh4hW!1hIhlOhw`heYh%wmH sH heYhQB*mH phsH heYhQmH sH heYhcrmH sH heYhcrB*mH phsH *~~~~~~)*/89?JLVXabfqrw*4OQVXdfkmy{ִּh%whJlB*phhJlh%wh%wh=B*phh=hfih%whfiB*phh%wh^B*phh^h);Gh%wh);GB*phhIB*phh%whiB*phhIhi;~*r-<Wl/kȂՂgdgdFy0gd%wgd=0gd);G 0$$gd%wԀրڀ݀37LNRTjkmrʁˁ`arsƂǂȂ̂ӂՂ&/GK¾h h hW!16h h[6hW!1hBgh+.hL( hFyhFyhN %h-h10hav hL;hL;hL;hKnYh8 hh);G h=hJlhJlh%whJlB*ph9փTUWZ[#*GIPQS]hp…ÅŅ  $.8=PYaµ±ҤҠҜƄƔh0hch;Zh0%h_Qh9hh2 hah2OJQJ^Jh7h? h? OJQJ^Jh? hh hZh2h-Hh;hd%h0hbjhZjhW!10JUhW!1hs{3Ղą fM$ & F Eƀ1b.^gdW!1gd9FEƀdFgd9 aݑ c^^YYYTOgdTugdngdrUgd3M$ & F Eƀ1b.^gdW!1M$ & F Eƀ1b.^gdW!1 aemp͆چ DMNbڇۇFJQ/=AMNUX]^ˉ։׉ȸ̴ȫȤ̤̤̓̌̌ hIhs{hmhWhIOJQJ^J hIhIhIhI0Jhs"hIhI6ha_h|DhIhs{h,2sh``,hq+Lh-hh~:h}hhfh'Sh\hh7NQ`~ĊŊ !"ʋڋ݋ދ/0IJKMNOPTU[ٞŞًٖهك| hh$<4h:bh|jh!uUjh!uUhg]h$h8,ajphSlUhJTjhJTUh^h-HOh-HOh-HO6h9h#h!u h+h$<4 h+h *hIh~hs{hhI/[\^ЌьԌߌ24Zvw|čōɍ͍؍./3¾Ώ{hk&hK FhphDhhhCjh\ h-HOh{* h-HOh-HOh-HOh-HO0J.6 h-HOhk#7hk#7h~%hht h4h;Xh!u hhf hhs{hs{ hh)Z hh$<4 hhEh% hh!u03HPV]lmy~ɏʏяӏߏ$CDEV^lmuĐŐƐҾںҶh= Vhhc-hDsh/rhp#qh2zhzhp+hOhEhhAh!uhA4h3Ah+Fh zh\|hghphrh] hxwhf.d hxwh-HOhh]Xha[hk&h-HO1"bcdnoq}בܑݑ !.01JKLNOPQjkl¾¶{p{jhl UjhZoUhZoh8,ajjhl Uh*"jh*"Uh*rha?hYhn hX[h9DvhuIh?h``,hn hIS(hn h!dhZphIh0QQh;h_Lh1thD4hG)h>ehT;h,lnopqrВLǓғ./12389;<UVWYZ[emnpuw¾¾¾®~uq~h hW_hTu0J.hTuhhh1h=hg 0J.hg jdhl UhujhuUhth3h+h\Ah|h``,h:5KjhS0JUh ^h*Euh h:> hUPhPhuIh*rjhZoUh8,a+ƔӔٔ,ds|~ĕ>?BC *9=>BCHIQRÿ߿~h+he'B*phh+he'B*phhwh}qhe'h+h't B*phh/}h't hIWh IhIph[NhO _h Ah%h2,hL2kh_WhS th+h)h:h%lhlh0J.hhN~q1 !;×#RTȘę#ٝЧgd5)gd2PgdG'gdM|G0gd6x0gdRgdTu0gd+ 0$$gd+0gd+RSXY^_ghinotu}×ŗϗܗ %/<AQR~~sosoh,h+h,B*phhXhjhjhf<h+hRB*phhRh+hRB*phh h-{h't /Ùę'()*O]^`aǚɚʚ/>OvwǼ˸۴߰߬۔z h*h./hj^hl UhXjhXUh7h0n&h.h`h4hD}Uh-h8,ajhSlUh{jh{Uhw@hYWhD;chGlh$ihNbjht--0JUhRi hh vh0{hZ=hwh8"h[h;h:lhD;chlhgUh nh;OJQJ^Jh nh-,OJQJ^Jh-,hgUh[|OJQJ^Jh[|hYh/th=h8,ajh=Ujh=U) 45HMR]asã $%&'(2CGKL (=>?tûðûì~z~zzh#h@jht0JUh=hMhhh#h-HOhrhPJh4jNhmUjhmUhmhTh\hU2hM@hyhQhQOJQJ^JhQhh~khc)h vhN,.ԥ!)*14RY'+S}ϧЧ 089=SXfglÿû{hAlh vhAl6hk>h!hc/hhh vhOh)Khr?hwrhGh+h\hgh&8h%)hp@hKh*h{ehQjhh4h;yhpDh]ghah1h6OJQJ^Jh6h .lqr¨Ĩ!ASTst2CJMOU^ixΪ*+67T^dսչյձխեթhq5hOhrh} hWeIhR-eh>hOhlh"|Yhch`0hNh?jh"7h]hUh?jh2h vh8,ajh30Uh jh Uhc/hAlhNF4de|} "-CTfhklmuƬȬʬ(08;<TUVejk}y}h~;?h hJhJhmh-HOh vh%yh*1h9jh0h9h;hi{OhedhJh;[hxh'%hw6hOhEmhj}hhr\bhQYh[h;h:oh\eh}hbhh/mVoع*x}gd%}gd=EgdFEƀfgdgdZ5(gd 9hgd22gdUxgdh5dgdxhgd xigdJgdbkopuíϭѭ18LMWbmpzŮϮ 2>PTXab̯үӯ Jrxļh%h v0J.h68hQh]}_hQ1h FhRhYhnh!:hhQOh;MhgZXhh$=hw=hch}!hdhE$h#h vh' h@h:;h Vhh-HO5xy@H GOefv̲ͲѲղļyuho;xh8h8OJQJ^Jh8hWhIBjh$,hNWh@hheL hh^nphpjhH{C0JUhh#h=?hxhhy)h8,ajFh-Uh%jh%UhEh68hEh680J.h v,=BVZbrsѳ.36KOY^`dop|ojh!:hgj0JU h!:hehS h!:h?4hF h!:hWh=hWhy) hxhhxhhK hK hK OJQJ^Jh0*hBEhMhh h3zhhz hZ!h?\h8h8OJQJ^Jh8hgOJQJ^J( D}~ʵصڵ۵ ,1:IXĽ}vovkd h!:hBh- h!:h2J h!:hr4 h!:hcJ h!:h9h8,a h!:h%jh!:h30U h!:hujh!:huU h!:h 3 h!:hUx h!:h9q h!:h<)/ h!:h7[ h!:hq' h!:h5N h!:hChSY h!:hW h!:h{{$Xֶ׶).134HZ\nop~ȷɷٷڷȽrn`jh!:hIUh8,aj>h!:hIUjh!:hIU h!:hI h!:h& h!:hUxhcm h!:h!:h4: h!:hRd h!:h0' h!:h+'hP; h!:hp h!:h  h!:h\ h!:hb h!:h& h!:hHH h!:hu h!:hAe%ڷܷݷLֹ׹ع %9IUVܝzvzohoaZ h!:h k h!:h~B h!:h; h!:hp,h9\ h!:h x h!:hc h!:h* h!:h 9h h!:h22 h!:hZr h!:hHi h!:h\* h!:h0 h!:hbA h!:h= h!:h h!:hyH h!:hW h!:h h!:hs< h!:hIjh!:hIUh8,a!̺Ѻֺ׺)*ovȻϻл߻BFJVWdevŽƽÿ|xtpth(|hfhhh!hho3hThhoxh~h71h+hyh.;[hzUhuhh0 h 9hh 9hhI>ph_gehF4< h!:huN h!:h8W\h/ h!:h/ h!:hF4< h!:hv h!:h k h!:hd",=>BLMNkl׾۾'()HY˿̿)*/KOZ[]츴|hNOh~ hFJhZh5hhYhh8h$hNm=h`khP:hTh8,hv:hYh`?MhsSUhh'NGhWnhh ihFCh(Eh%h|he=hSh8h2F"hfh0(;Ts ,2e ¾º~zh~eh1hwGh^xhAhkh?]h;hhnhoBgh-hj+lh1hj29h\-h}chyIh8hDhqhVWhh|h eh.0hs+h}hjUChP*jh_h0JUh~ / #,QRS  !R^imryǿǻó}tplhdh@$lh%}h=Ehuha$h)3 0J. hU0J. hg0J. hBc0J. hy0J.ha$hT0J.ha$h\W=0J.h[^haZ{hSvhVhh*Lbh1bh\W=h \h'2h!h:h7Lh^rh h]#h%^Lhj+lh ehj+l0J.h^xhj'1245BCJN]suy| )*/3KUX\jkwxy|ohbbhu>*B*ph!jhbbhu>*B*Uphh\ 4h=Eh! h%}h%}hh~ROh(hkhqEh"h shhdhWhsjh|\Sh5 Mh#hGhdhh-nh/zh/;hhh4$h7h%}(xQ$XO & F&Eƀ1b.^&gd! O & F&Eƀ1b.^&gd! gd>HOPQR#$%&_ȹȰڣ{w{soskgVIhbbh<@>*B*ph!jhbbh<@>*B*Uphhf hh4hKCh;h]whMh4=h<@0J+j)h}qUh4=jh4=Uhbbh\:>*B*phhbbhu0J+hbbh\:0J.>*B*phhbbh\:0J+hbbh*0J+!jhbbhu>*B*Uph'j8hbbh}q>*B*Uph_`a 8l7fghi ڵڵڵxtpgpc_[cph%Ihh(hhT$0J.hT$hhC/h<@0J+j!h<@Ujh<@U'j hbbh<@>*B*Uphhh<@0J.h<@hbbh<@>*B*phhbbh<@0J.>*B*phhbbh<@0J+!jhbbh<@>*B*Uph'jhbbh<@>*B*Uph#$ _O & F&Eƀ1b.^&gd! O & F&Eƀ1b.^&gd! h_O & F&Eƀ1b.^&gd! O & F&Eƀ1b.^&gd!  w_O & F&Eƀ1b.^&gd! O & F&Eƀ1b.^&gd!  #L]eovw')*+@ABCMN|}t}pl}hRh#hhu0J.huhmhhd0J.hdh+bh<@hah\:0J+jw"h\:U h\:h\:h\:jh\:UhvUh)hhBV0J.hBVhNh Mh[ hphhp0J.hh@ 0J.h@ h'wC_O & F&Eƀ1b .^&gd! O & F&Eƀ1b .^&gd! C_O & F&Eƀ1b .^&gd! O & F&Eƀ1b .^&gd! IJK\]^y𫛐}tk`PEhI~<hI~<B*phjhI~<hI~<B*UphhhPB*phhhP0J+hh0J+$j $hhy B*UphhhB*phjhhB*Uphh jhNvRB*phh jhS!0J+H*h jhS!0J+h jhNvR0J+$jF#h jhy B*Uphh jh jB*phjh jh jB*Uph_O & F&Eƀ1b.^&gd! O & F&Eƀ1b .^&gd! jklm:<K{|}~wld`UdLdHhB)/hahhUr0J+j&h$SUhahjhahUhPh B*phhPh0J+hPh0J+hPh 0J+$j%hPhy B*UphhPhSB*phjhPhSB*UphhI~<hPB*phhI~<hP0J+hI~<h@0J+jhI~<hI~<B*Uph$j$hI~<hy B*Uphl~_O & F&Eƀ1b.^&gd! O & F&Eƀ1b.^&gd! ~r_O & F&Eƀ1b.^&gd! O & F&Eƀ1b.^&gd! 2qr*1CEIJK`)?IOaivÿп~zzvzrh%h_% h h+}hhtX<h0J.htX<h0Mp0J.h0Mphrgh hEGhEGhtX<hbF0J. hEGhbFhEGhkhI%[htX<hY0J.hYhThYhtX<h40J. h4h4h4htX<h|*B*phh\h}0J+h\hh~ 0J.>*B*phh\hh~ 0J+'jj(h\hl >*B*Uphh\hA>*B*ph!jh\hA>*B*Uphh=9hOhO0J+j{'hl UhOjhOUhPQThtX<hqOY0J.hqOYh,PhHMh%htX<h%0J._O & F&Eƀ1b.^&gd! O & F&Eƀ1b.^&gd! _O & F&Eƀ1b.^&gd! O & F&Eƀ1b.^&gd! 8ai{ '45XZhiz{)ST˾˺}yplyhE@shnhe0J.hehhnh{0J.h{h hE hE hE hE 6hE hNVh phnh0J.hhrh*(htX<h 0J.h h\?htX<hG0J.hGh^ch^c0J+jh^cUj)hl Uh^c)_O & F&Eƀ1b.^&gd! O & F&Eƀ1b.^&gd! '_O & F&Eƀ1b .^&gd! O & F&Eƀ1b.^&gd! T_O & F&Eƀ1b".^&gd! O & F&Eƀ1b!.^&gd! TU:;GXfghy <=N<i¹Ʃ~zqzmdmh+hVb0J.hVbhZhv0J.hvhN]h'0J.h'h`hh!Ej0J.h!Ejh*h#Ch2 &0J.h2 &hh~h^8hnh7L0J.hSh7Lh$k=hnhQ20J.hQ2hf~dhqwhf~d0J+j`*h30UhqwjhqwU%T;_O & F&Eƀ1b$.^&gd! O & F&Eƀ1b#.^&gd! ;_O & F&Eƀ1b&.^&gd! O & F&Eƀ1b%.^&gd! =_O & F&Eƀ1b(.^&gd! O & F&Eƀ1b'.^&gd! i_O & F&Eƀ1b*.^&gd! O & F&Eƀ1b).^&gd! i~%'.34Xvwxkl¹ӱӦ{{{s{l{l{s h6^JhXdh6h.h0J.hjh0JU hEGhh h|rh 0J.h h^hmzh^hmz]h^h^0J.h^hmz0J.h^h?Qhmzh`wGh}hh<h5hVh }h<h/(5mHnHujh15UUhhh5jhhh5Uhh/(0JmHnHujh0JU h0J!LEREF \ltitle \* MERGEFORMAT Supporting Finite Element Analysis with a Relational Database Backend PAGE 13 Figure 1: FEA Phases Model generation Meshing Attribute assignment Solution Post Processing Visualization Products _O & FEƀ[f.]gdB7O & FEƀ[f.]gdB7_O & FEƀ[f.]gdB7O & FEƀ[f.]gdB7_]]]O & FEƀ[f.]gdB7O & FEƀ[f.]gdB7O & F&Eƀ1b..^&gd! ? 000&P:p14BP/ =!"#8$%h8 nq7Lʍ-`;HPNG  IHDR@FMYPLTEkDp]EL$szejf4%~itod[6B`d*$q| bsvbSt<44urSjbTh܃ьrf8H,$l{uTdքM;Dr j vXdެtbԗ!J#9)t|DxRKStt|ak_|z S2646l\F{wjT{{|rT\D.D;l4l\D,,6t\> kif儬OlymݘGQ}XtDI󊄜 \ g{{ kw|~+-QM{LN'=jqlftČ幄D4,nJl]\t~ĀDC\&l4&ds54slSj$Bdl*bKGDH pHYs@> cmPPJCmp0712HsnIDATx^}tW}&znXNR#15vwRۗ_g6l„EjlG@f4Đˀ\ܴ$S҆fB+P̴Y@oцp' vEs4o?6q~; ##}ῑ7oK?E0aöG}خ|Rl<w'_ÖsDwicz@[ds+33d%W~k mo}x_ f1C#Gueէӹcx&qȞ=ή= Wws}[oJ0:µM ՛+ ; d|Ía~d~M}摍y/2Yq$748K4lx +Mx##}[gdrwxU7s# ]Ʃ&F5^׫{kXDlM iϿYpƞ-' G]` QnX^~?Ie˾;9W]Ox饄B bJa# agE5|Z ,Eؼ&ˏ4ӹI5硻$n>BʆBH~<^o2Y}ga Wފ#kdϹ7 x&ۖŕ<4,gr|\ϻ萳o ˔ YaAnXԈF+'&#)ͼng^UR-ngF<o'yŹ?,kĈD,`- owTiR,4^9]I>Y7E/y_~3)hZ푇~CŜ#EG:P+*˩hDѴfeWf6FxY6ZǗJ^Z-nr5;[D*i;D)j٘$e@yJ 0)7|368ժHdf-T{qѫ>~Ei1myWovfJT^Ltό2 jYؼST^UΞDwv||wِbAJ1˷P2|hM57i.q{NT|W]ot⽼~ͻ;HͱdoBx}#rxoo/akC 3 g t]cgW}@'nF]&F4+0}1ɭ_)~!9WG ܃5W82zncQ&neW56P[֝=%Xs_{0V4;C[&9҇^31i6oit!<·X0$D*yUecG&ΝxgSgPDseOǙ}5s}{~̾ E_Gf(ҍ ^:~+g :MM~ >o/CVeL%go`%ǍzJ۳ %}mɘйqu_Y@swLؽ:cWIjp+\z 06t5"7`-bбe'9kϘ:9hr@| "BֵuEfQCp₇!aa[W 9kT&G&?pcڷvLЮ ^0*j>WbPU!neZ*V xݤ{m)0gCV&w螝&xgN[,;ZnKJlCapXܤ3ny'#H&{pJ~7rϝ]ӳo{27MaS_of (*%؈.mAL@ɮe״N첩N)0Ƅ,A呾ɫ^gMP]}rXm[ AWntW,w*oJplfX2Vː6uwezq2ᬐ~a{vQr}z Sk;_(x9qUKT+2GaǔįyZb߁}icUT:DnD;F߻Q ltYb籕b볇st̚P"d_!b^ tu^75uzL,#,*X;}-/)QMU})-yY.x%UM8dŻfD.82ZЩRґtVUkTE{^KgߙLoC^_a|ez5֬Yo߳v:cï֋RxaI_[d_.P0~w`/ dhx'o.gcJrOE^`i=ky'4! v駟sU^)O޴fM۾&`C:η;m=vO>Mn56a-Lˀl) s]ͳ }l`>e#EqՀ KύW~^{|iӦ}k:Mt؈~M ZNOˉ ͫӒ;!ԗֳ\|>޵wϔUuBP-}>Ok\@=?|coz߾7~soʓ?gӚ=Y@:ϊEӣbk퍭}; $)+k5~S(wDBi$8dRՑٽ{-ů2YE$Kv[9Foo|7l޴fzξ}g׌:ڢm40(4?=.nz0 eF-(ÿ4<9嚨Y0{- I67}+{GlDTc9) N,#UΛ.[qvSqO) v#:9&VbD2?pVX^#?DԜMTM&V{ _v`)Gjĝ8f=˓?AMٿi~z&kQJi_@ыAo,9.LR2mw2$Qfun37MnU0R %(ҙRVq7{h9#m~yy>3*_aE`.f-=fTL&]S O^DZ.7΍p]m6r$BC_ct|y (@ڹ[k;t.%h@f^ p S G>kRfغ=o`ޠO[{~TQj࢖$r/uy?[NJ iH+,Q۷|؋N'a. L,=OU9YypyzAr[J/{քwH t[N@k!Lb{~ii 4CcGʉ/OЕMjTԺNO͞\2KMLmubhg$~w,sL RYWhȳ aֽo ,(g.sL/(O -3v vk3abOaeem6' <0'9LIeGRQ[41j5URGѵmRrsx||jH67t)޼Ѱ6fOAc!=#dxCn.5<0<ԑl%~7VEJ2Z| %H.M} vPaGq\; ۗDA!Kx:%Buxr_hmqqbqLb0KbW0ؕ:m$h(nǣT|GYJ-`J"s" 0(o瞮] 3vY9N\V%ѩƟ95?6.v7LL| u&RRCS=dVlpKh؂ ЮZ2o/OnQW_k:#D^7ga{Ԕh ۚ({^%$jvWھZ3O=)mdWvla08ߣIն*u0)b\(D4sgyt ] ->%:ZJWM*A%rdayYr&jCGk{fk:CVR ;c홞c{!aHX.£Y'kDL.@e_KZG(l(>ݗCgMQQG)jH8Y.YXF:ШK(\?tth 0tR8]1vbifh"zᦰ(&ƳtZ*qM|FYP#j7HW[yhđ112="hjLX0'"h]ja7A}=V̅ J}NSHOf~qq~=5 oiXQ_Zf:5,?mF䴾G0gm꜍#[dǢ(J)5=;@4-hm:HЙa5K/!e9 H8~:tƧyZ%,ߜk1u|W5^h%-Z0ba$UtG8nt;Eb_DBA*xzbf] T,9}鳙 t0U+":p~h002Kj2m=jc\iJ- XY#3giD8n+Âc\; j2$Sl疐& 1bUwA{S~} VNڬ!`LY c*y,MYǢ5Og d^ x )C?#@/ZAҷF2!Uoazpt?Z>;Eݸ`vHmi34XawEV{,˃@8=9\O{nǣ?]w قxO}YgҨqnx qіoı Kʷ ?ǁ,3W7 Ahe5*gsy ?,z6NuÓ#ְE̒ @p#\0 .]F)pU w*9}VwX۳Jeܧ\3B^hq$<Š*CLpҷO,I0_ NJ Um)IZ  4#2 r>6xx tҫDA,RUBJ=ŗqNQXgAOFP:H6-[ ;?c'V1-zzMҩ!30TKd'Ls;xnv,-^Äo-(GEJPtQ )6Dl9& S/:BUzX+")gC{Cώ[ގVY*Ai|ݝ"f[2K _Q^Hrqg:҂HBPtc"ĪDAR0.' ('LZA,gU5ҝЇT*_idaU8 sȤmff(YH Rs .n 2 as<ogQE,A$MbT wCذ /1E`/S%;&-\%Kx%F.ՠr%fT&~S~@)fRۣTD(N/$#"}f8=;cg<()A u,ؗ hTzEֱ?i:庮 MIw\ -cbVۨvȹ47%c =rti :ӳʦ=.9%&33;E/3p~~IyC'^gOB<p%ݞ~3a {n 渚(;[ Xkݽ:l=/Z3Szػk` }҄=PfFb wPj6/bsׄD/`PgL{gI^_%ޔkg&)ŧťȝJl> ,ab W<+du6R=045lӻm`V(ĚׅJw/7`8Eg~eO(MO%|>[ݑ"_[Eޏ3 XCЧ\jPJS&63;B1 fޙNC@8:}T#%.gBY;%ۿJ2:0ue;gÿR?=$$ ֙=uRV[!r^xXv '`Fp\C: %QVh8&vjXFhBXony^r2gsY{߷RRURw@@Ǵ`L f2MUS#ʿ( J5tpz opF$t! )46$꙲$gU/Sѿǁzsf9[L{UlX̀ ?>}=|5}ѐ۽3>ӍJ[]EHxjŸFxd_A[ icHDTLG d>nT)TKa'{~#ghiY0lʺ.X̘p/L *?zˈ=G &Kµʛ,q7=r5!aW"*3.6z7V\x^de!K#7=jUQm1sȸ`Iةݟ|9h0P@oU]5 x@ݗcgp 922oC*٥lsk0Jx%PM/X=.RZf*0Pi1W v%!<8 f.FbHC%f*SDPGu$GH{dV/ .Dȸy2?ѩ=AN'r4sli2&#MS3ʗR <Ŀ[!%%~ %!>3Ovbz̮cb.qyS"] ,2wV %/?tWTDUKmF@ ; ǖAAv2hVQ>(d9}yzV J CQ̋nFz{jΒVBRacWSWXە9Zۃ"Ue=SJ PHiT\ mh?SpM1Tby b %l^"(THi EYhwjy͈_p (yЂSՓ ]9d-pm~LfT8H(YBjdH*ۃ=)fXƺ2Dja&j/kMce8ih&ӲA|%Ͼu>!"I6dcc]+&۟o$6j^;.H{jڗeaFVgd_)y=M)o vQdbU#'MH$ pvFj. z/ @W.Hl]LZ<67|zF2 @\%֓70tJN ɮ BS1XUc '֟8qbiZLs+&/  |}K^ reIdEΠkolzE^͐Ik:vύ`γU2a~}GUn$Oxj/Oz<`*&p?Bk޻~l1+rܲ8*OӊH4NȜ9(r+7.S:5|gbܵy06#n\@DzP >dAbD3OJA84>aWz6׏?#:\|L(q' ܒ ~_95cq\ i3{0P0:HPcdM3t6l^aѐ!׉lZ̭Z5^SdaR&\GyȯtKuFJ0ՠ;?aOsC&TX ~T?m`DbOĭk /Ð)k>2|ə133Ӭ\j/lYf d>d0( 1IE~SG1h[{u$;7x}|t! N\MkT3b*FЁſ>*0YbWA ׂ$Y3hG.6$vG:oXeU|lMA-)C>č8D|7߻MpQiު7)bw(XdCqk'uQ9(,NYTR|MX\ސei8ڃs-P[XJ'i?rrn%xaHi*t}}3$D=޼3x~^D FrWt&VL}i]˽QiL&g&W!z(fQGZ"gR<#[T8w …=uurFCuVȜ3ؽ}'wr#ZH>h\7dMg1ٽ]̜j-sx3K[Xe"g%QLnM& F<˂u: C'_' kur`@;nMumn՜;ß{)Oc1|H"fSm`0%#+ҵ?-sCGknc;pkzy3UeD䏊7Tg pU >tS¤]{bfG~7ˌXF oGBJ_}Fqd$#"k($:ExlpsSO] x+\K s6@uG&dPY>{Ϟs]7, WJCJ=5=qO$-oc#ù{12"CA"j`8Q$ܘ-{S"yD:yrCz꾻?N:x2`1Bt+nk|yE]jvr70] )}F(c>Jk|A;g`w83? W0\X FBӡ_rz1hrٵ^lwÜ=]Gjn{#kOpVUD*`n`ݛoB so3ۚs*D*4lsSz lݴP5UQ$?6pnH#oE '06Zj Qn`dbBpzjzUÂ'N 7|mc|kiəUלoUpY^uUqÆݻqx7Y )Jyb!C-e{oBoһn,J/;=Y>}5a8f=j̪0+!KHYa N(J8LUɵOAXw \2znɃw߽v`}cr^mXvVdɗa07;u7>Um9hbҙiIpx@H0h b( pZ+{2R)`^3 )«vY\Ze|)oq~N7TF8ȟ ]pNvу 8ן<>Z!U}#ugWnbyM3B |4 *!УR5>w`|ppD"^0]L,6Ae҈YIЬDZhA2튄J #:884Xl6DuxzN u 0?1_w#н^^ppjKRZXc.${l/4yfN-JWD+0gOˬ,:PIHj@ǁ;ԻvkwԯD#0C  ,lɆv/w%~œRX&4_cl"YoG5ب "hv%Bu{s(,@h!ɿs.`=ڣ'-@/9? \ʺڔ۽0EcE!t{9;)n $PY: ^Y݆i}XJy[#XJ QKQ""m/@0؝QǮ9Xb$p:y!p/ΩGSo'98'(f8{_!EqT2ː8g d6eHWD!M,ɼ|cȈ -)AF"#h3`-kZ1g %|ixOeI94 onͅVDf:/!*AI"N&[֭p @8NVm``B`/H%Sማaf.XSx8t @$P,C\Y¬ڋUH*k |$aAn>u]ޯl#Pkx⣿y{=ǻ?ːt{vjg. TA+i}j݉Zi[0#]_6809!$G6Z-]?y-]݅<ܢ"tx߮'_$>D?'_7߾b;˷V/*癙YY֗g`6!U"~Gy^MC1Ķs Av[`o9z-Gߢ[N;y?zak'' pPJ40YuQ:1P;w~ Sw_$I >֣ko`Ǻ4 睬}]5Ϊ >DGuժ WW -}=?[]?763w|} ?w|co?@s׮]SsWxxa uð@V wE:pU>ByfgW9^f&Ë$sB2bk15ޘÁe}e U7"ޡ98kpѯ?'/h[Pܞ2;K;ui>ϵwp#wh! mϥbX!O;~8Hu!_! @DuCEk =L}c:X'j &FK1#X%׭Hq k_o/cۗoٰiS;o?o_96YXU'D"v zBLǰX-(NJtU ʗB{|"X_ ]m( 7IvYy_4*Q2 BwD5FzXT_j;OWo?_?##?#x?9d^[?ڧnk'|#1&0u.lq–e/VDHz(cF:ۮd鳳U ߦu@M06ʡ;7r,s WpE|h]bwݵcү[-a到rann#WV#ydC?׆Yp3}PtwY?W>S*Os+R(Ӻs{%! $m$t# Ṁ=J'X0l8zRHsά ]w_~>1qh(o,ؠ+>8G ^R JD$r+wP#Ypi1r lTM @xطͦRE2֏~0s5NcCv'6r+n)1"< ڷ8WxbKj5ۚn{d#t}w|"U89=q,P6.J,%=vBn|*LkcZF}-9T*FaG__[nkΆm3 '[Cy&^JbJa}81R`~!JARNes$sYM f:_`Z֘m''hzE_Fڥz2H='QQ*k/]2 Bdë͢"\ t@= $hgF5/"(%q{l+smeB3paL1#C 5`H hAgľ[ߟ$e 8ozOyᮓ wk'\Ltamxս!3t(rF}̹db]TI][UC+WyT֥T!{*>dڍttW[yG??~w#k Qw :Uf)«,Vh-q 9:1@τ^)3 j2;e u}$Pe] B38_|$# <3kx>;ℒ '=uO9jikevfF6NB̕0>5!i?Igp i}49OtYl{ԏbl"j7GխY^C=9wxBOWПPSXHԕABL&RC:xFʖ#Q;~;EAʿD9N%WEuӭCV ?Ƈ4ȕaTB4? O8zjnahS_<$. _Cm5_kNń&lVӔynN_Tɰpqb *&$9BD) {YL0n%~%sc4/G7w$\]b蘸{鄹CُQZm"ׅ2\!T7VƔn>3/}Hsg\Ȭ8)#j:\ zZCV_|kWR㞿E]H'8MTͥEuE/[\Nd zFEL" QG2Y- r9RXn,1qF tѤMyh 1m*]HL>]ÓyrЫ ;s C_F@V%3"oI}y3ToLSKg ZŌwҒ^OB 1Ӻ0)+KqdWhh:W>R:+:s/ɡ@K֖ڃ(ͧ.NdGs."Dfv 5}@GJ,!_#C /m>ljy׶E!Ė%i@xe,YV9a^sχ*gְ3SZ%RӠ_a;[:r:,żnXrT1fl&>1 ,%_Q\b삡knr‘9$YELXX0FU.:;cb>BVRRx ڰ1OvGx'Dh5ݛ{&6oisAF/(ܞVT 5 [7bRH^P8D擟'rAA>&\sFA ;%iD&f37W 5 ewBmi5C ӈHK0Zon+b`z#n?2w#,l&5#~=&fli 9Daf`X$@U\#qU?#ԻP6S췩֊40XpE{`>$a !c;\@kl^SV_VX3sY#ء}a ӏ|\Wq 1^\CrR0=ȘBWfiRtܧy2+Qv3JZ O <z,KRm| w`J;/HD!W_DkOJZ(UyP`CbGvXmx&f)Liz6XMACr8C6N6&3 O2aIW\`]ڃԅ\Kq+A]\|} yF:g%Fl;Nd--'~dUB):DyUiƋQ v6?LmbY&PYcrlcBIOZ?tq<6*r,Rp0'·cE dʅy[RXEsdVߕ_Q_Y5kd 5Rjo*VSii-NUᆇ~ӿ1 tt< F4f wޘ-2|UDa+F{-I/5@t`ܪc1K`6<٥(7w1rjJf^ CVMl4|`JTט;p݅Xz>ݾ +99ʇkW$asipq )cp@t+NPpTDkk1f)x®\mp(VB.^k4Q-Fְ=!ޕ4%ֆ|vr2|+zHl! CH(㎳ 5(nRCwz:1z͡*t^j,\Og޽1;0BnA)-NjCu/M̕~dcpeM?)cF%hGgQ Txg.@#(2Օh2\_ĉ_&DZRl){E΅K{ޟ4,DчKzg=Iq$gZZ#GgqThW 55V$`! A/)2gV؟Bˋ.z@!\ʍq5 wXEZJGFŔzy<*TqǸo_D+P~ye[d>ЏeQq/jcZ+;;h.:lSAChr3]&ٙLiJXgٻYtdo\ns]! %F}U!ڬ Yxxg ȗe^r^P|fkZȹL/ڏeVD,RO Pez, 2ZHY=OH-aUyiքZ9Q`spjKhzs.2`E9nc<}`T 2k.*^ByqkӘ)? r]h  ;ñX!y5ap~a6 {^l~ d_[K`ZQ L iC/2^|9/ V풝!N,D%teBU#<?=l0U%ΆqɗK:ym( $nY8|OmC҂F5?+ [\{ua= `jW)ZjߨTT@%g`e[%AE >& |9DP_蟿_AevsP>Kx|;B}'Qy箃zelkec,΃FP AĊȣ;|o@F&k].0 bͰ|EZ3mK#zKYW+T`sNFrIKpWRN0|O}fS̡i++axZ2z( 0 rkbj٢<6EX#" nW!nT"3^q>)?vj2͙ TGpV8x&DuG9LEsa>FSz()BjK+;biŽAcbxlg[bU)A3do/D>i[tm;m&YprMdϹ1(ԭ{%\eшءa߆'c6;z;B`F \Um55lHH =!nCDrWX30ʝx=H`~'ǾefůPB8Hh8?o?yJQVIn5u}` Y+$@uL%G$pp'Vf nYmwQ(QQxb?͂U+[ȚÄ`WMK@D93nS~ͳ\#7D>3aKfe079@xbplf?Jf,GPeJ,#> O>懌y (-ެگW!NH @o>^ss1Fv1WUB JY f+k. &a Ź33f޻ۣyt3)aCh< M~a1T\? xޑ8”`P$Ð ^ ͯ[xEHh:-]E=c.]vŒ"+-B[{bώYI{6ؘ$elD`j|?F-!mlOzzX";ԂW!_*.2P;b6?"/3&ءSWv}xrBClBΒ GX 嗅[ڛEB'Cnrijس4?zcg#u`8qyTc6KqsOsPEk,okM"v3[ڐp+T͑FߘS!1W;"QE*.{ژpnj yn )L0v~6ΰ&Zf6Ot#C ,'4VzF1ii|E"cWtޅڋx/-)}Rw~ͥ!t1ץ] ""TA-C)!PZ)x 3ebhg⪦'+ܼn":O8a}pp!=8 .Շ"a\ N0n%sekrM]!V>UIF$̣rPmb]$ ОRJ侥̩H l0La'ˑ]ՊS4&A,,2Jj\괝\3ӳgy;0UV m  @vZzeU4JN݉b ͑tQ0>fr0Yð!/2g L+]#3?E ,ª6F2pN@j3C3g!8hQNSεD9Z=j|7ϵD3&\1g"ܲi)R[ \U-u0 dϠYf kMMAH&*0|t c1*wٌůiOIn7(A%sP…l*l>H (ʝy6|J&}v}x02#X)6ܥB9:=fIQ{|i\?z M:[<'s\M<0Ơi0{uiu6^97A݈kJTقI77bcU:Ӕ6uⰍpBG!fLR@|(5a[JYfC)ZɩT_'0E5g孽R)IBOoY.ͮdqB7!i?Ӕs^;N`CN6#PV^25x6$L.9RЭ$2'1HÑV(HT-z05UL2+QN.b*'&9S)\O,6fI!MM,Wg?/hr2}tkA?%G;O[kwy{5y+SOtHko_6 qAfg8Ӳ1ZxXAA J%J2dD #QM]{4Gq=W.ixjour2/PX=Y&Twe.p0H2Ǥ<*-&K:"R_ҏÀ]jVF?Nҫ!:әq4ݼ&%SY%%l]#yVnQ(^w׍.g++6(CQ1ؒ|P+eؽ(w8& j kh@mS]SC9CHqjڮ=)3fOEP9ZbE,aP/]KaβDe M[1♍T+AMyc\3ֿ+%Rُѐu,R6wAP5RÔEPցzg@r8 ꆨ|:쀦uvH+̪nEQahZ8r"S͒/7T 7W$bi1[a7Ub0msn%AAPNN ih@mTS M jiw{U7:+H8b-)_J -/4H!|`p\/|Oj/OpYR}6HU7SnEr*+muJEZ)fmpc *ru L,+|}q"mU|r`= B&e=gH.WGryY2h+e9l,/OYE/fM}_ceh &VX527aA7nt=DTy]`a!?h,|xMIBYvwI\ e>a2)4뱢@%P.IY)7|,vaap&uS#⟀TTPs^@,$Lrm`1BCLLj}.h$|s ұcG~mpÄXSY'0,IgdHGo}o~ yl\-֛=BWDRUb<2}UN§>lI#|fbj|b[- b q enL$ğ;Fj1QN`BhZP pk5T`&Fc U[k|΍)&ݪpc!)%髰&SVkl5wW]4`J'2{嘄_)qgm&%%#IJJWe.56HBniS[60ao'#翊*"ŊD0ֶBseOeٟ~jp8^i"66T$= |H&ryyB IЫASAϾɑs뾍##kFx'fv7')UjڞGv+` fQq= 2L4SY0m$*=`ӞkP򺹿,{:ENHm{“|"/nJyw%`Y\,rYp4Q=.TZWmTBVѰNf+X_ȸ:u+sz4w}!|iu0叶5[%f̸(8p Kz[ֽ`-c nAJV:a TZܿHk:%:M<<ё}Yfz}Jnߔ %L%Ă^"SkYW6"eZZXp|̋27?W"e,M P}{trrMcR%(7Ur_7`͖FcO0)S̘SXZTl}Dni囐V3e.*>".#B~=ݷZt;W|K|""{s :{p#/,Y:vM$2CѠT,z'o,42'/vA'G6i+CizevL s_=&'%.{ͣyJCM]U% %u;5IENDB`DyK heber@tc.cornell.eduyK 8mailto:heber@tc.cornell.eduDyK heber@tc.cornell.eduyK 8mailto:heber@tc.cornell.edu{DyK  _Ref99194293{DyK  _Ref88222570{DyK  _Ref99194871{DyK  _Ref99194902{DyK  _Ref99194911{DyK  _Ref99194384{DyK  _Ref99852907{DyK  _Ref99434875{DyK  _Ref99434880{DyK  _Ref99434882{DyK  _Ref99434883{DyK  _Ref99851543{DyK  _Ref99853901{DyK  _Ref99853906{DyK  _Ref99853908}DyK _Ref101410802{DyK  _Ref99356135{DyK  _Ref99344997{DyK  _Ref99279329{DyK  _Ref99284275}DyK _Ref101066790}DyK _Ref101066802}DyK _Ref101412012}DyK _Ref101412027}DyK _Ref101412040}DyK _Ref101412056}DyK _Ref101412059}DyK _Ref101000831{DyK  _Ref99194293}DyK _Ref101412136}DyK _Ref101412149{DyK  _Ref88222570{DyK  _Ref99194871}DyK _Ref100462830}DyK _Ref100391022}DyK _Ref100544504}DyK _Ref100655704{DyK  _Ref99194871p$$If!vh55#v#v:V7li t 6`655{DyK  _Ref99434875{DyK  _Ref99853901}DyK _Ref100490453}DyK _Ref100497671}DyK _Ref101412670}DyK _Ref100545821}DyK _Ref100497671}DyK _Ref100539221}DyK _Ref100497671}DyK _Ref101412974}DyK _Ref100542869{DyK  _Ref99284275{DyK  _Ref99279329}DyK _Ref100645669{DyK  _Ref99194871}DyK _Ref101248396{DyK  _Ref99194871}DyK _Ref101255153}DyK _Ref100490453}DyK _Ref100462830DyK yK http://research.microsoft.com/research/pubs/view.aspx?tr_id=860DyK yK dhttp://www.tc.cornell.edu/~heber/movies/FView.wmvDyK yK Xhttp://www.cs.uvm.edu/tr/Papers/CS-02-7.pdfDyK yK http://www.nafems.org/publications/downloads/benchmark/july_2003/data.pdfDyK yK :http://www.microsoft.com/sqlDyK http://www.opendx.orgyK .http://www.opendx.org/DyK yK Vhttp://www.engr.ncsu.edu/SMiRT-16/1915.pdfDyK yK zhttp://www.stanford.edu/~junpeng/research/journal_paper2.pdfDyK yK ~http://www.stanford.edu/~junpeng/research/overview_Com_Str.pdfDyK yK zhttp://www.sc-conference.org/sc2004/schedule/pdfs/pap160.pdfDyK yK 8http://www.cfg.cornell.edu/DyK yK ~http://www-users.cs.umn.edu/~karypis/metis/parmetis/index.htmlDyK yK http://research.microsoft.com/research/pubs/view.aspx?type=Technical%20Report&id=736DyK yK jhttp://unisys.com/products/es7000__servers/index.htmDyK yK rhttp://www.microsoft.com/sql/msde/downloads/download.asp}DyK _Ref100637708:b@b {f/Normal$$x5$7$8$9DH$`a$OJQJ_HmH sH tH `@` Heading 1+$$$ d@*$@&`5CJ\@\ Heading 2,$$ d*$@&`5\@\ Heading 3,$$ d*$@&`5\@\ Heading 4$ & F<@&`5CJOJQJT@T Heading 5 & F<@&` CJOJQJX@X Heading 6 & F<@&`6CJOJQJP@P Heading 7 & F<@&`OJQJT@T Heading 8 & F<@&` 6OJQJZ @Z Heading 9 & F<@&`56CJOJQJDA@D Default Paragraph FontVi@V  Table Normal :V 44 la (k(No List 4@4 Header  p#4 @4 Footer  p#.)@. Page NumberRO2R title&$$$$ d*$a$5CJ2OB2 author $a$:OR: authorinfo$a$CJ0O0 email$a$CJVOV ,%sheading1#$$ @*$`5CJROR ,%sheading2#$$ @*$`5NON 8heading3$$ @@*$`5JOJ equation $ ]@xx^a$HOH figlegend$$x`CJTOT tablelegend$$x` CJmHsHHObH abstract77Xx]7^7CJ*O* p1a `BOB reference^`CJH&@H Footnote Reference CJ EHH*lOl Running head - left( $ ]d`a$CJJOJ Running head - right!$a$O1" Bullet Item_">TTfO Item# & F >T-Tf^`O1B Numbered Itemf$ & F>T.TfR@RR  Footnote Text% @V^`VCJvObv programcode=&$ QOM @@@@@@@@xx^`a$OJQJbOrb /Funotentext.Footnote' V^`VCJ6"6 Caption (xx5<O< .heading4)@`64OR4 =Eaddress*$a$CJ6U@6 =E Hyperlink >*B*phFV@F 4=FollowedHyperlink >*B* phVOV VK figure legend-$$d$x`CJNON )\S heading4 Char6OJQJ_HmH sH tH hOh 'dFunotentext.Footnote CharCJOJQJ_HmH sH tH 6O6 OGSQL 0` CJOJQJHH {f/ Balloon Text1CJOJQJ^JaJB'!B vComment ReferenceCJaJ424 v Comment Text3@j12@ vComment Subject45\4+R4 NV Endnote Text5>*a> NVEndnote ReferenceH*@s `PS Table Grid7:V70$7$x5$7$8$9DH$`a$NON 2 heading3 Char5OJQJ_HmH sH tH >L@> 1Date9$`a$OJQJ7KTJC'I{KNQS TMTU X[_b`\aaddddddddgghjllm5mnmom@nZn~nnno.ocoooo@rs tVtytttt7uvuyuu0vvvv*wrwwwx-xJC'I{KNQS TMTU X[_b`\aadddghjllm5mnmom@nZn~nnno.ocoooo@rs tVtytttt7uvuyuu0vvvv*wrwwwx-x3A3C3^3a3@-@0@2@L@N@=SXS[SiSSSUUUUUUwVVVVVVz\\\]]]^^^hhhHjbjdjrsss"s%s/JM0KNPkn;VYɒ %'ڭ~ٯܯӾOQ$%` fh*@J]jl|~iTXXXXXXXXXXXXXXXXX @X[}!  !t 34,b$7Lʍ-`;HqA 0e0e     @ 5% 8c8c     ?1 d0u0@Ty2 NP'p<'pA)BCD|E||s " 0e@        @ABC DEFGHIJK5%LMNOPQRSTUWYZ[ \]^_ `abN 5%  N 5%  N    5%    !"?N@ABC DEFGHIJK5%LMNOPQRSTUWYZ[ \]^_ `ab@X 3(   & 1  C F. PcSPcS3"t   s *X99? "`& 1Z   3   & 0[ (h 6 ")A # #" x  S .Acrystal"`6 ))=  s *x?"6@`NNN?N: :>NAB  <D?"0@NNN?N: 6<W?AB   <D?"0@NNN?NP8=W?AB !B <D?"0@NNN?NW/8]?A\B " 3 "`A"G+B S  ?d _% @-$Tt2 _Hlt101000252 _Hlt101000253 _Ref99194293 _Ref99853901 _Hlt101080395 _Hlt101080396 _Ref99434875 _Ref99284275 _Ref99279329 _Ref88222570 _Ref99194871 _Ref99194902 _Ref99194911 _Ref88222550 _Ref99194384 _Ref99344997 _Ref99356135 _Ref99434880 _Ref99434882 _Ref99434883 _Ref99851543 _Ref99852907 _Ref99853906 _Ref99853908 _Ref100391022 _Ref100490453 _Ref100462830 _Ref100497671 _Ref100539221 _Ref100545821 _Ref100542869 _Ref100544504 _Ref100637708 _Ref100645669 _Ref100655704 _Ref101000831 _Ref101066790 _Ref101066802 _Ref101248396 _Ref101255153 _Ref101410802 _Ref101412027 _Ref101412059 _Ref101412056 _Ref101412040 _Ref101412012 _Ref101412136 _Ref101412149 _Ref101412670 _Ref1014129742@2@Ծa w+ClrKij';=i@@@@  !"#$%&'()*+,-./01O@O@O f v@@j|qJh&S:<h,=Q=Q=Q,=Q=Qe=Q`=Q =Q- =Q =Qt+ =Q$ =Q0 =Q z=Q=Q,=Qt=Q=QL=QL=QD=Qt =QT=Q<=Q=Q=QD=Qč=Q=Qd|=Q\=Qd  =Q!=Qd"=Q #=Q\a$=Q9%=Q&=Qd'=Q/(=Qi)=Q*=QJ+=Q,f,=Qpr.=@Gvvvxxxxxxxxy8y8yLyjffoii(      !"#$%&'()*+z|;?EJJvvvxxxxxxyyyKyNyNymmqqpp*!!     !"#$%&'()*+=(*urn:schemas-microsoft-com:office:smarttags PlaceType=**urn:schemas-microsoft-com:office:smarttags PlaceName9%*urn:schemas-microsoft-com:office:smarttagsState8'*urn:schemas-microsoft-com:office:smarttagsCity9&*urn:schemas-microsoft-com:office:smarttagsplace>$*urn:schemas-microsoft-com:office:smarttags PostalCodeB#*urn:schemas-microsoft-com:office:smarttagscountry-region>,*urn:schemas-microsoft-com:office:smarttags PersonName d,,**('&%$#&'%$#'&%'&%'&%'&%'&%&'&%'&%#&&'&#&Q  B ~ D ktjlpqy ,!.!/!1!2!3!))))))e,,,,,,o11111111111122222222233!3"3#3B3C3b3d3@P@R@[@\@a@3S4S=S]S^S`SaSgSiSSSSSSUUUUUVwVVVVVVVVVVVWz\\\\\\\\]]]]]]^^^^^^hhhhhh&j,jHjfjhjkjljqjmmmm]ncndngnnnnnnn oo2f3?R@AASSUV[\\]K^^hhigj8m9mnnnnnnooKoRooorstt$u(u]udu}}҄ajrq=BٕxL:Š׮o %A[zbhswx33333333333333333j|  k C3k'-]D U!))Z,,01>2e3<<SSU-V.VV[\\]K^^hhigjrszzԃՃфqp#ٕxKП:Ġ֮o *xQ n NwC~<4Ki'+T;h=>ix[zawxwxlSD  ؞1ZO &4+`ΫlqhI{HhӎH$qhI)3qhI^5qhI7qhI].[Gn&tPqhIp dqhIjqhI8EmqhI@ OJQJo(@ OJQJo(@ OJQJo(@ OJQJo(@ OJQJo(@ OJQJo(*h^`OJQJo(hHh^`OJQJ^Jo(hHohpp^p`OJQJo(hHh@ @ ^@ `OJQJo(hHh^`OJQJ^Jo(hHoh^`OJQJo(hHh^`OJQJo(hHh^`OJQJ^Jo(hHohPP^P`OJQJo(hH::^:`OJPJQJ^Jo(n  ^ `OJQJ^Jo(hHo^`OJQJo(hH  ^ `OJQJo(hHz z ^z `OJQJ^Jo(hHoJJ^J`OJQJo(hH^`OJQJo(hH^`OJQJ^Jo(hHo^`OJQJo(hH@^`. **^*`B*o(ph. ^`hH. pLp^p`LhH. @ @ ^@ `hH. ^`hH. L^`LhH. ^`hH. ^`hH. PLP^P`LhH.@^`.^`o(. ^`hH. pLp^p`LhH. @ @ ^@ `hH. ^`hH. L^`LhH. ^`hH. ^`hH. PLP^P`LhH.@^`.@^`.h hh^h`hH.h 88^8`hH.h L^`LhH.h   ^ `hH.h   ^ `hH.h xLx^x`LhH.h HH^H`hH.h ^`hH.h L^`LhH.@^`.^`o(. ^`hH. pLp^p`LhH. @ @ ^@ `hH. ^`hH. L^`LhH. ^`hH. ^`hH. PLP^P`LhH.@^`.@^`.={H7H$=ZO 8Em+`l&tPj^5].[Gp d)3= @ ^`OJQJo(> 0@ ^`OJQJo(-         Ff                          43.v"Y*r?!TVa~kj{|/}} " 4?AOCNORzU]XX`cjn{c b,--pCNFIIKL[H^/cLv?j'5OS U^4ehhijlO{*)\*n++..14I9 ;;>N\l_aehgj>rIt-{E, 'v#8:C'NS\_/r\"'->BPVR\\*ees[| z%!)r.j2;>bA1J?R'S/T~bc,i f+$6'09<}@HT,``hvze ! , b- )6 E P \ l -m 't }  N  & 2' N0 4 B6 ; @ yE E F J N T [ a r t w y ~ # _% ?> O T W Hp cs v a} d  ! # 2 )3 1= eL f &p y Ky { t     ' B E bG H zK Q R _ >s w z h~ Q  ~%%%&89;FMNRZQaTct{| {R24;H4NkOPT>eij&t5pDOPR-W/tqw%y'z#$:&qow =D?!$N')3n5O@U]4fNhkmLr  .~(8;I[dygh"b)-0<NXg;vi ).?p@f0w|Q#+54:.C-DUDZZ\mlmBuu|C#O,M3=@BB2KKQhlUr|ma,k>S4_~ 2't01<=@@ShjvR)>, /D/611!:g==?BN-Vh;jE~o] mr"LY[}hl8qrQtuK}j}23 %,<,-1:3AB_a@bilcm8ntuy}N - 68]8;BEY_]demsv a3! #('@WNbkn 2 V%+'.-6999b=e@xNXdxmnsNv  u  n    p$ % 2 8 :> K K VO T ^ c m (| !!!!.!2!>!M!S!Z!n!y!"*"""S""""C"$"'","/"8"2F"J" U"_"<`"`"d"e"g"Zq"r"u"q## #p #} ###&#2#e4#6#fJ##X# Y#i#S$$$+$N$k $$$V'$%-$8$I:$0;$GC$zE$E$T$n$7o$'%N %5 %%%"%0%%=.%/%0%UH%*O%Y%`%8a%c%Eh%&Q& &U&2 &'&>D&W&Z&2d&d&>k&0n&n&q&'G'''&'+'0'9'f;';']O'']'T^'\g'p'q't'w'y'D((#(*(Z5(8(C(8F(L(IS( b(lj(r()) )%)-)3)>4)<)K>)D)E)H)U^)9`)c)4p)y)***N **!#*h%* )***0*:*E*N*O*P*bT*W*X*Wf*"q*)t*{*{+ + + +i5+>+A+C+F+I+ui+j+p+s+{+|+,h ,,N,-,,",O(,+,2,B,G,H,P,A[,u],``,n,p,--t--:-L@- J-R-U->Y-c-r-.. . .;%.2.D.&E.rM.#X.W`.Jc.// /s/ />/x/<)/B)/V,/./;/Q/bV/{f/k/|/ 0u0x0307 0"0'0(0D*0.0<0>0B0]0`0 m0,u0z01171W!1'1*1g3161/:1<1I1M1N1'R1Jg1z1~12 2'2'22222U2U2U2X2_2x2z22 33#3'343;3+G35W3g3g3eo3Fr3444?4\ 414:4$<4@4D4L4T4LW4W4Z4]4]4e4gj4m45o5u555-25H5T5^5Wo5|5666e6( 6:64M6M6U6X6c]6w6_|67j 7 7e 777k#7?7Q76j7r7 {71{7j8'88!84848NA8H8M8Q8y]8_8f8n8s8st8u8w89W9"9#90)91919j29>9?9|F9dK9wR9^Z9dc9c9>e9z94::g :Y : : :v: :!:*0:3:\J:Q: `:a:g:l:w:~:;Y;;;';/;:;;;C;bE;_F;J;L;P;m;s;l<$<: <{<<<(<!<"<d*<n,<,</</<F4<C<D<J<Q<U<tX<]<b<[e<s<0{<I~<==="=4=<=F?=V?=O=\W=Z=b=e=$k=Nm=w=w=M>>>>$>4>> >.>J^>x>{>R?? ?( ??%?3?6?~;?=?H?&W?\?\?Bj?m?3n?2t?u?@@w@@;"@[5@E@M@RT@sU@8h@(l@o@Iv@z@A AAEAecAhAkAK}ALB BZBlBB Bg#B:*B1B:B;B;BKBPBRB\BNcBdB~BWC9 CKC?CC'C&,CFCKCQCSCjUCVCWCE?EBEJE[E^ECdEoEqE~EFK F FFF1FF[F8FJF&,F,FK1F5F7F@F|AFGBFGFMFVFZFbFBbFqFqFd|F|FdGGG Gs-G20G0G);G(HG'NGNGEVG|XGXGn_GwaGlGlG`wGM|GGHHDHTHHBHH HS H> HH#H-H/Hp1H7HRRR._RNvRyRUWVWWWYW\WN_W_WzWq|WW>XXX{!X*X9,Xh0X0X;X@XWXgZXsXzYYYYT#YK*Y/1Y6Y>Y,CYDYJYMYqOYQYrUY[YeYKnY_oYyY"|Y3Z;ZZ>'Zu:ZBZTZTZgYZ_cZ7qZJ [ [Z[[,[[6"[I%[0[9[.;[;[y>[?A[J[L[N[Q[R[a[b[Dm[r[ \>\?\?\L\8W\m\m\Nx\]]]i]]$]*(])])]+],]I2]p9]D]F]\]J`]`]g]^ ^ ^^^^$^[5^*9^J^[^^^"e^_f^f^Ln^vw^F___O _3__!_&_)_)_$._P:_B_D_sE_G_W_Va_a_bh_q_;t_]}_G_``r ` ```````7`?`K`ee"e(e*e+eR-e5eK8e=eHe dedefe_ge jeoe\qe{ei}e8~e`~e~ef f ff 'f1fIhf#iflfrfrf ~ffggggg;)g2g[l?l$GlJlkKlSlodlflUnl~lmm mm*m`*m2mZ?mAmCmImJmWmZWm mmn[n nnJn,n`nn;nfp\Ap,GpXHpHpKp0Mpsepip^npwnp2qp-vp9qq q q1 qp#q;q=q>qIqKqLqOq,RqXqgeqgqkqmq?oq}q}qN~q{rrruyyyz zhzKz|z%z2z9KzSzczgezXfzmzszuzzuzp{{{{{{{{{{8{B{F{P{aZ{b{{{{{~|w|Y|(|+|.K|7L|~S|\|\|b|Zr| s|}}}}U}+}\}a}jx}~ ~| ~B*~/~ 2~38~VI~L~Z~h~Vj~]j~rs~MW*-l7<=<@KBgw{.  ' ;=IQKV[^dhoEss-a$+S-{3 4|6>@qDK$lF "#1;DIM@NQR`am+ppss|ix-.L178v?uAMRU^d:fj}mp*rv&y /.6t8::;IKfNNWp$, 4e9F Yr_befRvoxI+0J1n=\>IMJPOU9\ddprsStv~4D^8/9; \XdnvCwxxz!C +5=YAAOTiY)Zdx  %+68{DVJEM\f^=ahpt}~9$(;89a?YAdVfhju|kV*-9:;$=>JKVrz"1)3r4@CDwGPRVb}cincrwHzM6J>=L=RU[[`_fEhjwr>zs-14ISq\K]f}r#)*9ORVZhRiCjxA{ _n#),c/D!]^;g|;8f#$%3)*/023CxH`5iiqqw~~l!o39<\A0QT#U\UgU^Yhsg ]"_#'p+/0x1>CwRwSyX^_hisw}|{(x%)849>?ASUr]kXlw2} "E.38@NP[cIorzIkY(,4?M>QQR7[a e& . 16)LU[N] >#c$,/9=BYCDORZs^z1~EfY&I-@AGuNA7KMQ"W\AeoVoizy T"(Y4f;q;DDX[YYahppmPD'36<HThd&np- '/(H)1g2z7T;o< VVZ__A ~"q.59<ZC"KW\jiijlrHx .6G788;< FQGJKPQi jUx}es &$&[29<GPKMOV[P\[gx)|+%'V(+-P2=;=DINPSWlq8 /HTg &+.J2&:MAX"\bpx* | I.:5;BIN:PSW_[Dayafkr8yc#$5@CEpJ[nue{t4,79 :f@!DKLM*NTWbmmhv~D ?#E*x+5GNp[ejuvFxF} ~ sP0-,3"4GuI]S5[f\)h?jmnh\ `"6V[a5cc_h#jkrswyP `%*}.9<MS\\]bacRmAtQ H k&c(/0q58<A=nE{GSPTPRZ[ie#,%I`ejJln}wyp+r/,678_LKPVGYYbiq!u|Z,!r!'%9<MUVEkolu '7<FPOZT\-bpFy,~O#\-5=OFHY%[X[ahin p@t#/*1v5<AHNR!Tj8oq1u|Rjd%113|5J^Wh:pxnK MTZd~mp wwJ!  !"$.0+34PFIJ@T/ams'wR{Dt&(/12A4 92>DTWU[U\cnpuz %!+02Y] _``kl@v > }<yHRPnoGpkpzT~$ :&"u/31o6K;FJN|R`gjo?F^hyl*rt{{z+P:Bfsj .@ (9*:@+FRWX\^`e;h+lmyxys{  kU#-101:I>_l*svw]erI*M/W4c4-7:8>ENReV]s~R (4T7 :==0EGNY``brgsftBM "%'4QabRd yv!(m,p46C[p^`#.1_60=BGf[xeYfp{,J]##D4FQ`cclr3z_W:?UU\\dw|} l $ b9ANUVYsy{ k&+%.b.U<%?Vbb5 `X#z% 22; @A$HjH^Uedvyz2-01]CJxh xyg$&Q1;+ADqI_Tgyo r>}}  r,}--<D7L_LbLOYls|tt%w",:5===JDL\e(+"=HIW]dwYE [ %+.8FU"o?z1 !B7/ARw`jpqKO9=9@EOGTV[\bRjdlr)t a,1o2@4q:AEKNS?]z> SQ"&-g/8?S~_ # #<-2GhOxX\o}cI @!s"47?B[NU]/z]5\:?BJT[[_0 I "'0239;IQQedk&,,192 3JDOW7_jnt**"7E_`o{*}<q(,37;;<CLWTCabc]gm) +/;K?TUd[ikw.L35=EGK|NP"`BcdZi ##(;1= >CAUl]^fiqvu.*!"D(k5B:?CGYGLQrww(y: #8$^(_?fOgnmvzz| ? 5:cdk s3w |~'**+P]^jk},qu6(:?E~Jbd 9'c67JIQdX7_cffj~yd >&])+0DWL9P\XXhvrt!|& k}C#*03F]jSQ2>?;I?MY:cfh iv?.{:=MJTUVbesu5}!&E(*+2l3>@BLOMmnvw+,_.22u37IILQqaefuTuI{]%7FGqZ]ghu""x(*)/ikv <#(j0186:=Vq`qr%}$x""hHIQhdlyk &E'9<LPNIWXi\c&|d  F` %*B-f<<V6XY`fgkz }|GHP/PcS4TXehj-npw0{D,4;=C+[u~@ !#0)6;bfhy{6`:HbggrH e' CGK7LSXn`@aejt}} 0M'"j+7*Yk\\V^_$hp3w} (2W2Y9UmLr{Rg4$V068<UV\_WnvVx[~p?"8,07q;D_QUWL[\c[vU}+ $*C19;*?R[d$X')),-4WWj\cddepKxz}m#*>:CEIL8MSY _u_3bObmnoy)Vt(G)1=@AIV^Qadeef\lZp\quy{44O:#CNUWXd\emHu| !&5).6ZDOS^u~lO ~--1::<=EhM@[CnpE  |!'+ORsUYgi jYo6u>-5n!(: B mzM~~KKZ,1=>JCaddduxehUUUUUUUU@`}v@P@PPP@P@UnknownJim Graygray Gerd Heber Gz Times New Roman5Symbol3& z Arial3z Times?5 z Courier New71 Courier5& zaTahoma7Tms Rmn;Wingdings#18AbAb˔&!l!l!xx4d{{% 2QHX ?=E22C:\Documents and Settings\Gerd\Desktop\sv-lncs.dotsv-lncs0Copyright Springer-Verlag Heidelberg Berlin 2002grayJim GrayH          Oh+'0( <H h t  sv-lncsgray4Copyright Springer-Verlag Heidelberg Berlin 2002 sv-lncs.dot Jim Gray2Microsoft Office Word@@tBI@I W@I W!՜.+,D՜.+,` px   Springer Verlag GmbH & Co.KGXl{ sv-lncs Title (X`  _PID_HLINKS_NewReviewCycleA8 fVX9http://www.microsoft.com/sql/msde/downloads/download.asp^ k|5http://unisys.com/products/es7000__servers/index.htm^ KUhttp://research.microsoft.com/research/pubs/view.aspx?type=Technical%20Report&id=736^ |a?http://www-users.cs.umn.edu/~karypis/metis/parmetis/index.html^ ?'http://www.cfg.cornell.edu/^  =http://www.sc-conference.org/sc2004/schedule/pdfs/pap160.pdf^ 9a?http://www.stanford.edu/~junpeng/research/overview_Com_Str.pdf^ Ta=http://www.stanford.edu/~junpeng/research/journal_paper2.pdf^ zk+http://www.engr.ncsu.edu/SMiRT-16/1915.pdf^ >6http://www.opendx.org/^ A@http://www.microsoft.com/sql^ _,Jhttp://www.nafems.org/publications/downloads/benchmark/july_2003/data.pdf^ <~,http://www.cs.uvm.edu/tr/Papers/CS-02-7.pdf^ 2http://www.tc.cornell.edu/~heber/movies/FView.wmv^  a@http://research.microsoft.com/research/pubs/view.aspx?tr_id=860^ gmailto:heber@tc.cornell.edu^ gmailto:heber@tc.cornell.edu^   !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~      !"#$%&'()*+,-./123456789:;<=>?@ABCDEGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~Root Entry F i WData 0+1TableFWordDocument_SummaryInformation(DocumentSummaryInformation8CompObjq  FMicrosoft Office Word Document MSWordDocWord.Document.89q