[cig-commits] r16909 - seismo/3D/SPECFEM3D_SESAME/trunk

dkomati1 at geodynamics.org dkomati1 at geodynamics.org
Sun Jun 6 14:26:18 PDT 2010


Author: dkomati1
Date: 2010-06-06 14:26:17 -0700 (Sun, 06 Jun 2010)
New Revision: 16909

Removed:
   seismo/3D/SPECFEM3D_SESAME/trunk/TODO_list_external_mesh
Modified:
   seismo/3D/SPECFEM3D_SESAME/trunk/todo_list_please_dont_remove.txt
Log:
added NETCDF to the todo list


Deleted: seismo/3D/SPECFEM3D_SESAME/trunk/TODO_list_external_mesh
===================================================================
--- seismo/3D/SPECFEM3D_SESAME/trunk/TODO_list_external_mesh	2010-06-06 19:40:00 UTC (rev 16908)
+++ seismo/3D/SPECFEM3D_SESAME/trunk/TODO_list_external_mesh	2010-06-06 21:26:17 UTC (rev 16909)
@@ -1,29 +0,0 @@
-
-DESIGN : 
-
- - The subdivision of the mesh should be done inside meshfem3D (there is actually no point in doing it prior to pre_meshfem). The subdivision itself is already implemented, but we also have to subdivide the communications and any other similar data that concerns elements (absorbing boundaries, PML,...).
-
- - Nearly all constants declared in constants.h concerning external meshes (look for string 'nlegoff') should be read/computed from a kind of Par_file. The same goes for the declaration of materials, done with a function in meshfem3D.f90 (and also right now in specfem3D.f90 in case of associating materials after pre_meshfem but we should get rid of it). There are also some variables declared as parameters used in create_movie_AVS_DX.f90.
-
- - Materials should be associated to elements before pre_meshfem, but it is not always possible (that was the case for Celine Blitz's asteroid mesh with regolith because of limitations in the CUBIT software with huge meshes). An example of how we can isolate elements in contact with the envelope and associate them with another material is commented in specfem3D.f90 (look for string 'NL NL REGOLITH') tough it should in fact be inside meshfem3D, not specfem3D. Identifying the envelope is based on the NGLL points, so there is no problem with tranfering it to meshfem3D.
-
- - Calculations on elements in specfem3D for regular meshes should be merged inside compute_forces (the basic calculation is okay, but not attenuation, absorbing boundaries, ...) as there is no reason to differenciate those. 
-
-MISC : 
-
- - The following default options in flags.guess -qlanglvl=2003pure (for xlf) and -std=f2003 (for gfortran) causes some problems with intrinsics. There might be a better way than to simply remove these options.
-
- - Reading the file DATA/STATIONS_FILTERED with pgf90 returned an error, because it considered that the lines were truncated, thus failed to read some data even when DATA/STATIONS_FILTERED was also generated by pgf90. Go figures. There might be a better workaround than simply removing writing of blanks ' ' (see rev).
-
-Add-ONS :
-
- - Receivers distance to source along the surface computed for an asteroid can be done by computing the shortest path in a graph. No problem in serial, doing so in parallel might be tricky.
-
- - Partitioning should be done in meshfem3D, using a parallel partitioner such as ParMETIS and/or SCOTCH (PT-SCOTCH). Reading the (distributed or not) mesh, building the graph, distributing, and partitioning is not a problem, but redistributing the graph/mesh according to the partitioning obtained might well be.
-
- - Adding absorbing boundaries, attenuation, PML, moment sources, ... for external meshes.
-
- - Differentiate between elements in contact with the envelope, and those that are in contact with a fracture : source, receivers, ... anything based on the envelope detection will have to take into account those fractures. Really tricky without prior information on the mesh.
-
- - Settle the issue of normal recording for the receivers. The normal is unique, but the plane can be described using two vectors at random (while conserving an orthonormal reference), so we have no reason to choose a pair of vectors compared to the others.i
-

Modified: seismo/3D/SPECFEM3D_SESAME/trunk/todo_list_please_dont_remove.txt
===================================================================
--- seismo/3D/SPECFEM3D_SESAME/trunk/todo_list_please_dont_remove.txt	2010-06-06 19:40:00 UTC (rev 16908)
+++ seismo/3D/SPECFEM3D_SESAME/trunk/todo_list_please_dont_remove.txt	2010-06-06 21:26:17 UTC (rev 16909)
@@ -2,6 +2,9 @@
 To-do list for SPECFEM3D_SESAME, by Dimitri Komatitsch
 ------------------------------------------------------
 
+- For binary files (for instance Carl Tape's m16 model) we should use NETCDF to store them and read them back;
+that is the only clean way of ensuring portability between different systems; and NETCDF is free and open source therefore there is no reason not to do it. 
+
 - there is something in SPECFEM3D that we noticed a few years ago
 regarding attenuation but never fixed: on page 813 of our 1999 paper
 I used a trick suggested by Robertsson et al. (1994) 
@@ -28,6 +31,8 @@
 
 - we could add support for different polynomial degrees in different elements (p-adaptivity)
 
+- we could add support for Discontinuous Galerkin, and/or for SEM on tetrahedra and pyramids
+
 - Regarding memory size (getting an estimate of memory consumption in SESAME),
 somebody should just cut and paste my SPECFEM3D_GLOBE routine
 "SPECFEM3D_GLOBE/version41_beta/src/memory_eval.f90", which



More information about the CIG-COMMITS mailing list