krober10nd
commented
3 years ago First off, thank you for taking the time to go through this and write this thoughtful review.
I'll first tackle your discussion comments then I'll deal with your suggestions later.
What distinguishes SeismicMesh from these?
GMT and Terreno describes an approach to "automatically" building 2D horizontal triangular meshes for the coastal ocean and details the challenges with incorporating geophysical datasets into the process. You can think of it as a "recipe" that can assume some guarantees of model generation reproducibility. It's mentioned here because it discusses the theme of automatic mesh generation from geophysical datasets which a key point of the SeismicMesh program and was one of the initial attempts at this mesh generation problem but for a different application domain.
OceanMesh2D is my MATALB version of an automatic mesh generator for the coastal ocean based on DistMesh that inspired a lot of this work. However, it's very domain specific, has a lot of focus on incorporating coastal modeling datasets into the mesh generation procedure in the sense of pre- and post- processing, only works in 2D, and assumes you're building a mesh on a horizontal plane on the Earth (or the entire globe). It also is in MATLAB which is a problem unfortunately for some.
MeshIT is similar to my program as it's intended for seismic domains in some regard but is not a mesh generator, but more of a pre-processor to a 3D mesh generator. It adopts a different approach to constraining/incorporating geometry (e.g. rock horizons, faults) using STL files and relies on Gmsh/Tetgen on the back-end whereas I use SDFs and wrote my own mesh generator.
For a non expert, how does the geophysical datasets differ between these methods?
These other programs (OceanMesh2D and GMT Terreno) typically rely on vector datasets like poly-lines stored in a ESRI Shapefile format that represent coastal features/shorelines and digital elevation data that contain bathymetryic/topographic data which are available typically as GeoTifs. The latter (GMT and Terreno) require to have a well-formed coastal ocean model boundary with the point spacing agreeing to your mesh sizing function. OceanMesh instead takes care of the mesh simplification and thus requires un-simplified vector data. OceanMesh also builds the mesh sizing functions from the digital elevation data according to several heuristics, which is not unlike SeismicMesh.
MeshIT I believe requires horizons/surfaces that it pre-processes and then tries to constrain in the 3D mesh generation procedure. I'm not sure how it adapts to the wavelength of a velocity model or incorporates damping layers. I believe for reservoir modeling, the focus is more about capturing the features exactly (e.g., wells, faults) and not so much concerned with inverse problems/velocity model building as is my application of the meshes.
You mention in the Ongoing and future applications that you are developing a version of OceanMesh2D. Could you elaborate (here, and not in the paper) on what changes this would imply.
The idea I had with SeismicMesh was to get the mesh generation technology in part developed from OceanMesh to a level of quality and speed in Python that I could then separate out the mesh sizing function capabilities into separate packages depending on the application domain. So for the future, I plan to have SeismicMesh (or whatever it's called) as a submodule that is used to generate a simplex mesh and then I plan to maintain a Python version of oceanmesh that contains just pre- and post- processing routines to build mesh size functions from coastal modeling datasets and a seismic mesh sizing function module that does a similar thing for seismology. In this way, we obtain a separation of concerns between the mesh generation and the application specific geometry model and sizing. There are several benefits to using SDFs for coastal ocean modeling but I won't get into those here; but this is one reason why I steered clear of Gmsh and your typical Delaunay refinement methods.
jorgensd
Some comments from me ;) The first one is more of a general question than a suggestion to changing the text.
What distinguishes SeismicMesh from these? For a non expert, how does the geophysical datasets differ between these methods? You mention in the Ongoing and future applications that you are developing a version of OceanMesh2D. Could you elaborate (here, and not in the paper) on what changes this would imply.
Then to some comments/corrections:
My suggestion: The mesh density function can be used as input other mesh generators. However, the usage of a particular sizing function can have impact the mesh generation performance.
For example, Gmsh’s advancing front and Delaunay refinement methods construct the mesh incrementally and do not permit vectorization, which leads to reduced performance at scale in 2D/3D.
Does the original DistMesh algorithm take this into account, or is this a feature of your implementation of the algorithm?
Remove both from enables both
We present a comparison of the 2D/3D serial performance in terms of cell quality and mesh creation time. We compare SeismicMesh with Gmsh (Geuzaine & Remacle, 2009) and CGAL (Alliezet al., 2020;Rineau, 2020). The cell quality is defined as the product of the topological dimension of the mesh (2 or 3) and the circumcircle radius divided by the incircle radius. This metric is between 0 and 1, where 1 is a perfectly symmetrical simplex.
After this sentence I would start a new paragraph before For the analytical geometries .
I would suggest you split this sentence into multiple sentences.
Remove very from very higher
Split into multiple sentences.
Gmsh increasing its mesh generation time by a factor of $\sim 3$.
I think you can replace
for the four benchmark problemswithfor the four benchmarks.each inversion iteration, updates to an objective functional and produce modifications to the 0-level set.