Overview of Goals and Objectives
Goals and objectives, general methodology for the Working Group for the Development of Community Finite Element Models for Fault Systems and Tectonics Studies
OVERVIEW OF GOALS AND OBJECTIVES
In order to test the accuracy and speed of various elastic and viscoelastic finite element calculations using different codes on different platforms, we have developed the following benchmark comparisons. Information resulting from the benchmark comparisons will be used for the following purposes.
- Confirming proper numerical implementation of the physics including rheological laws, fault constitutive laws, crack tip processes, etc.
- Testing the accuracy of the numerical implementations as a function of meshing scheme, number of nodes, element type, time-stepping scheme, code, etc.
- Testing the computational efficiency of different codes, solvers, and modeling techniques as a function of meshing scheme, number of nodes, element type, time-stepping scheme, code, etc.
- Comparing and evaluating available finite element codes.
Based on the comparisons, we would like to be able to 1) identify and correct any errors in numerical implementation which currently exist in any of the considered codes, 2) quantify differences in numerical solutions as a function of meshing scheme, number of nodes, element type, time-stepping scheme, code, etc., and 3) quantify and, if possible, minimize model induced uncertainties resulting from discretization, model boundaries, unexpected transients in time-dependent materials, etc.
GENERAL METHODOLOGY
All benchmark descriptions assume a right-handed Cartesian coordinate system with the x-direction running east, the y-direction running north, and the z-direction running up. If a boundary condition is applied at a depth, d, this will correspond to z = -d. The surface is always assumed to be at z = 0. Use whatever coordinate system is most convenient for your program but please convert the results to the one defined here.
In order to compare solutions in the most straightforward way, the benchmark solutions will be described at nodal locations instead of integration points. Thus, initial coarse meshes should all use the same nodal points, to the extent that they are permitted by the various codes. For example, consider a uniform mesh spacing of 1 km in each direction, such that dx = dy = dz = 1 km. For linear, brick-shaped elements (a.k.a. hexes) the volume of each element would be 1 km3. For the quadratic serendipity elements used by GAEA, each element would be 2 km x 2 km x 2 km (volume = 8 km3), and the nodes corresponding to the face and element centers in each element would be Òmissing,Ó so that the distance between nodes is either 1 or 2 km depending on position within the element. There would be 5 tetrahedral elements for each brick element, 4 with a volume of 1/6 km3 and the fifth with a volume of 1/3 km3.
Benchmark meshes will be described at the coarsest level to be run. Linear hexahedral elements will be assumed. If memory, time, and patience allow, also run models at 1/2, 1/4, 1/8, etc. the original coarse node spacing. This will make it possible to see how accuracy and speed scale with mesh spacing. If your code permits a variety of element types, also run models using various types of elements (linear vs. quadrilateral; hexahedral vs. tetrahedral, full vs. reduced integration). This will make it possible to see how accuracy and speed change with element type. Finally, variable mesh spacing degrades accuracy, but, for economy, we would like to employ a variable mesh (e.g., to resolve stress variations at the fault tips, etc.). If time permits investigate the trade-offs involved in using variable resolution meshes.
With regard to output, there are a number of parameters which should be noted for each model. For the purposes of determining accuracy, please record displacements and stresses (all 6 independent components) at the specified locations and times. For the purposes of evaluating performance, please try to keep track of memory usage (including the size of stiffness matrix and mean bandwidth, if possible), compiler type, compiler options, CPU speed, CPU execution time, wall clock execution time, etc. More details regarding the submission of your results for inclusion in the summary analysis can be found at the end of this document. To ease the burden on those who are compiling the data, your results will not be accepted unless they are in the specified format.
When available, analytical solutions for the various benchmarks will be found on the web at http://geoweb.mit.edu/fe. Whenever possible, please check to make sure your results are essentially correct before submitting them for the summary analysis.