2 .4 Model of Fault
2.6 Finite-Element Mesh Creation
We do not attempt to write software to generate the unstructured finite-element meshes with tetra- hedral finite-elements. It is not easy to discretize a domain into tetrahedra, and the complexity of
I l~C'----]lr-.J\
~d2~
(a) (b) (c)
Figure 2.6: Interpolation schemes for the various topologies of the data sets. (a) Linear interpolation.
(b) Area interpolation. ( c) Volume interpolation.
the problem increa::ies significantly when we constrain the node opacing to match changes in matcrio,l properties, include the fault plane as part of the domain geometry, and force the tetrahedra to be as regular as possible. Consequently, we use the IDEAS software from the Structural Dynamics Research Corporation to generate the finite-element mesh.
The first step involves inputing the geometry into the IDEAS solid modeler. In addition to the basic domain geometry, we also include the fault plane on which we align the element faces as described in section 2.4.1 and other surfaces on which we want to force alignment of the element faces. For example, we usually include the surface that slices through the centerline of the fault so that we may output information on this surface. For faster mesh generation we subdivide the domain into smaller chunks, allowing the mesh generator to work on only one chunk of the domain at a time. We define the finite-element model from the geometry by selecting the four-node tetrahedral finite clement a.nd specifying the node spacing at appropriate locations in the domain.
We generate the mesh one sub-domain at a time and use the auto-checking feature of IDEAS to insure the quality of the elements in the mesh. Poor-quality elements include those with distorted shapes, which lead to larger numerical errors, and elements with non-optimal node spacing, which lead to interpolation errors when the spacing is too large and to reduced time steps when the node spacing is unnecessarily small. We export the mesh in universal file format, which is a plain text file that is easily read by the simulation software.
We also use IDEAS to extract information regarding which nodes and element faces lie on given lines and surfaces. For example, we want to identify all of the nodes on the fault plane, because we use them to implement slip of the fault. Similarly, we often want to output di8placemeuL Lime histories on the ground surface or along strategically placed lines. For planar surfaces, only one face of an element lies on the surface, and a list of the element's three nodes on the surface uniquely determines the element face on the surface. However, for multiple faces on a surface, all four nodes of an element lie on the surface and anywhere between two and four faces may lie on the surface.
We must use an additional criterion to separate the extraneous faces from the ones that we want.
We require the fault to be a planar surface, so that only one face of an element may lie on the fault surface, and we do not need an additional criterion. The surfaces on which we choose to output information may or may not be planar. Because outputting information on these extra surfaces does not affect the solution and because the penalty for outputting this additional information is negligible, we allow the extraneous surfaces to remain. The absorbing boundaries usually have planar surfaces that meet with elements on the intersection having multiple faces on the absorbing boundary, with the extraneous faces arbitrarily oriented relative to the boundary. These extra faces could hamper the effectiveness of the absorbing boundary. We eliminate them by constraining the lateral sides of the domain and bottom (absorbing boundaries) to coincide with one of the coordinate axes. When we formulate the absorbing boundary we ignore any faces that do not coincide with one of the coonliuate CLXe::;. We u::;e IDEAS tu create the group5 of node5 that coincide with the de5ired geometric entity and export them as part of the universal file.
of megabytes to gigabytes of memory and billions of floating point operations. State of the art work.stations still lack the rn.emory storage and processing power to effectively handle such problems. Luckily, parallel computing provides a suitable environment for solving such problems by distributing both the storage and computation among many processors. We do not seek the optimum parallel software implementation, but do strive for efficient parallel computation.
Several methods and libraries exist to aid in writing parallel computing software. We chose to use the Message Passing Interface (MPI) which is not a library in itself, but a standard interface which libraries may follow. Some manufacturers develop their own implementation of the MPI in order to optimize the code for the architecture of the supercomputer, such as Intel's MPI on the Intel Paragon. In other cases, a third party implementation, such as MPICH from Argonne National Laboratory, is used. The MPI standard defines numerous functions to pass information among processors and facilitate initializing parallel execution.