Models

[prisae]

Which numerical models should we show?

I suggest:

1. layered model, comparing it to semi-analytical solution, e.g., empymod; the canonical model; we don't have to explain a lot for this, simple to show they all calculate the same and also the same as semi-analytical solutions.
2. complex marine case, e.g., the SEG/EAGE salt model (https://nbviewer.jupyter.org/github/empymod/emg3d-examples/blob/master/2a_SEG-EAGE_3D-Salt-Model.ipynb)
3. complex land case with a non-block model.

(2) will probably favour regular meshes, as the model is in a regular mesh. To equalize that, (3) should be a complex model, where the regular meshes will have to do some interpolation.

I don't think in this paper we have to show the latest and greatest of modelling; but rather things which ALL modellers can do, and mention if some modellers can do more in one direction or in another etc.

For the above reason I would also limit it to the frequency-domain at the moment, but mention which codes have time-domain built in as well etc.

Raphael:

Before we start, we should agree about the reference model setups, i.e., the CSEM environment (marine, land etc.), transmitter types (HED, real 3D sources , etc.), layers, anisotropy, frequencies, anomalies... If the idea is that all codes calculate all models, there are probably restrictions about the model design. This is in principle no problem, but I think our reference models should distinguish from something like HED Tx in blocky geometries. I’m rather flexible with custEM, so I’m open to any suggestions. Moreover, in my opinion it would be great to have at least one model related to a currently challenging scenario in the field of exploration geophysics.

[Moouuzi]

1. I'd skip the layered-earth model, we have all validated our codes against analytic solutions in the previous papers. This saves probably one page, which would beneficial regarding the issue about the scope of this paper.

2. Meshing the salt model will be lot's of fun, but I'll figure something out. What about the others?

3. @ Octavio - can you handle land-based / airborne setups easily?

[ocastilloreyes]

1. I would also skip the first simple case.

2. Yes, it would be very interesting to solve this problem and compare the results. Go for it!

3. @Moouuzi Yes, they can be easily handled. I have already done some experiments on it.

[lheagy]

1. :+1: on skipping a layered earth. I do however think it might be useful to have a simple 3D block in a half-space model. I know it is over-done in many ways, but having a simple (but still 3D) comparison, where we might be able to show a few lines of code as to how to set each simulation is set up, and also all have this as an example in our docs could be beneficial to the community. This also provides an example we can use to explain the mechanics of the codes and solution approaches.
2. This sounds like a nice level of complexity for comparing the codes
3. I am wondering if we actually need a third-model... We might be able to go a long ways by showing a couple different surveys over the simple model in (1) (e.g. grounded / inductive source and both e / b data). I know there are lots of interesting questions to potentially be asked about averaging / dealing with different scales and such, but I think these topics have broad enough scope that to do them justice will take a lot of space... 4 different codes running 2 different models is already quite a bit

[prisae]

The reason I thought about another model is discretization. A model like the SEG/EAGE one mentioned above, which comes in rectangular blocks, is obviously easy to model for finite differences codes. However, to also show the full power of finite element codes it would probably be good to have a complex model, where FE codes can nicely mesh the model, but the FD codes have to do some averaging to get the job done. Say some dipping horizons or similar.

[ocastilloreyes]

@prisae I agree with your last comment. So, yes I vote to include a model like SEG/EAGE.

[Moouuzi]

I agree to Lindays that 3 models will take a lot of or rather too much space. Considering all the comments, what's about:

1. Lindsays suggestion: 3D block in halfspace (land/airborne setup)
2. Dieters suggestion of the salt model (marine setup). It seems to me that there is a blocky discretization available which Dieter alredays used. Aside from the fact that it is probably very complicated, would it be possible to build an unblocky model from the surfaces information?

Anyway, I tried to get an overview of this salt model, but I haven't figured out so far which one of the data in the zip directory are relevant. I assume the files contain something like a regular grid with an ordered list of markers and conductivities? As the last time I worked with segy files is 5 years ago, I could need some help to get a first overview about the model.

@ Dieter. Probably, you can export the grid/ conductivities to numpy arrays or maybe you have already a vtk available?

[prisae]

I did some work together with Bane from PyVista, see here for an interactive display of the SEG/EAGE model: https://nbviewer.jupyter.org/github/pyvista/show-room/blob/master/seg-eage-3d-salt-model.ipynb

[ocastilloreyes]

Thank you Dieter. I will check the data.

[prisae]

Input from Kerry Key:

One thing that the community could really use is more test models for various scenarios, and having them be easily accessible. A few years ago Alan Jones and others led a 3D modeling workshop in Dublin for MT and they created a suite of simple 3D block models to be used for code comparisons. Even though they were quite simple 3D models, it was a good exercise to see how the various codes worked. And of course how each code work changes over time as improvements and new features are added, so one of the lasting things from the paper could be the establishment of some really good test models and some baseline responses for them. The idea being these could be community test models that are used as a baseline for future code comparisons for say the next decade or more. I would encourage thinking about including relatively simple models that play to the strengths and weakness of the various codes (e.g., blocky models good for fast structured grid codes and slanted structure or topography that is better handled for unstructured meshes, etc). the Simple models are good for assuring that the codes and meshing discretization are pretty accurate. Super complicated industry style models would be interesting too, and will bring up discretization, accuracy and efficiency issues.

[prisae]

I really suffered recently from the accuracy of 3D modelling. And the problem is, that we can only check them by comparing it to 1D/2D/3D modellers. By 2D/3D modellers we can just guess which one is better, by 1D modeller we know which one is better. So maybe it would be good to shift the focus a bit on benchmarking. Because lets be honest, there are dozens of 3D EM/CSEM modeller out there, almost every research group has one, judging from publications. So we should focus on open/python, and reproducibility.

1. Model

   As such I vote again for including a 1D model, but not just. A 1D model as a background for a block model. So you can compare only the background, or the whole model. We don't have to put the 1D result in the paper, enough if we provide it online. I created such a model, by taking the "Dublin Test Model 1" from the MT benchmark paper (Miensopust et al.), adjusting the distances to move it from an MT problem to a CSEM problem.

=> The model is in the notebooks directory, have a look.

2. Complicated block model

   Maybe we can replace the SEG/EAGE salt model by this recently open-sourced Marlim R3D CSEM model, what do you think?

   • https://library.seg.org/doi/full/10.1190/geo2018-0452.1 So we could already compare it to an industry code as well.

3. Complicated non-block model

   Here we'll need ideas from custEM/PETGEM, I am sure you have a nice model with dipping layers, topography (land CSEM?) that Lindsey and I have to squeeze into blocks.

Just a few ideas.

[ocastilloreyes]

In general, I believe that the approach and order of models are adequate. My comments are:

1. I agree to include the Dublin Test model. In this way, we validate all codes for a simple case. I have reviewed the model and it seems a good option.

2. Yes, this model is interesting and we shouldn't have much trouble reproducing it. Comparing our codes with industrial applications will enrich the paper.

3. This is a complicated issue (same as the model). We currently have a small number of models and it seems to me that none would meet the proposed requirements. However, we could define a synthetic case although for this we would not have reference to compare the results, which could be a weakness if we do not justify it correctly. I will talk with some colleagues and maybe we can propose some realistic model for which we have a solution (we cross our fingers).

More ideas?

[Moouuzi]

1. first model is fine!

2. Maybe Octavio has other solutions for meshing such models, but I don't know if the MARLIM model is better suited than the EAGE salt model for our tetrahedral codes. I haven't found any information about the mesh/conductivity distribution, boundaries of layers etc. for own mesh generation following the links. Anyway - same issue as for the salt model - generating a realistic tetrahedral mesh comparable to "gridded" meshes is barely feasible.

Realizing good tetrahedral meshes for such complex scenarios with several 3D intersections requires, at least for me, too much time as I'm not familiar with professional CAD and meshing software so far. The only "simple" option I see is discretizing the domain in tetrahedra of comparable size and nearest neighbor interpolation. At greater depths, this kind of averages the conductivities, even though close to the surface such an approach is not always applicable as some of our modelings showed.

I'd be glad if we decide for either one or the other model soon. We/I could only start with the tough exercise of mesh design if consistent information about the geometry is available to all of us. Runnnig the simulations afterwards is probably the easy excercise for all of us.

3. I'm still not convinced if we need a third model, but if you like I propose a model related to the Kiruna ore mine (2nd largest world-wide), mainly characterized by a steep dipping, excellent conductor. It is also one of the rare cases where considering susceptibility produces a slight difference in the results. I could ask our contact from LKAB if they are fine with that (conceptual model related to the real world) and if they can provide us some geological information which is not shut away. So far, the communication was excellent. The setup could be land-based, airborne or semi-airborne, I'd favor the latter :-).

As an alternative, do you know about other mining areas and models which are of global interest or do you prefer other scenarios?

[ocastilloreyes]

I agree with Raphael. First, we must define the geometry of the model to know if we are all capable of generating the input for our codes. For complex scenarios, I use the technique that Raphael mentions (nearest interpolation), but its effectiveness will depend on the challenge of the model.

Unfortunately, I have no knowledge about mining models

[prisae]

How do you guys (@Moouuzi , @ocastilloreyes) then usually create a model? What is your normal workflow?

[ocastilloreyes]

@prisae, in general terms, my workflow is as follows:

1. Definition of geometry and blocks (e.g. dimensions, conductivity for each block)
2. Meshing, including refining in regions of interest. This point can be difficult or not, depending on whether the model has topography, bathymetry or other complex geometric bodies. Some cases may require the use of CAD tools, but so far I have managed to avoid them using other strategies (simple but effective, at least for the cases I have solved)
3. Execution of PETGEM: assemble system, solve linear system and postprocess electromagnetic responses.

Thus, the input data that I need are:

1. Tetrahedral mesh
2. Conductivity model: a) list of markers and conductivities for each block or, b) scattered point cloud to project to the unstructured tetrahedral mesh (using nearest neighbor interpolation)
3. Source parameters: frequency, position. I currently support HED (punctual source dipole) directed at x, y, or z
4. List of receivers (receivers positions in the xyz plane)

[prisae]

I remember MARE2DEM has some automatic meshing - is there something similar in 3D?

I agree, I got quite desperate lately with the meshing part (on tensor meshes). The 3D results depends so much on it. So much that I have come to believe that most published 3D CSEM result has probably more likely a relative error of 3-10%, rather than 1% or lower, what you would aim for...

But I think this should also be a focus. There are so many 3D CSEM codes in the world - look at all the publications, many many research group have some sort of 3D CSEM code at hand, because just the solver in the end is not too difficult. How you then actually create a model and discretize it, that is a much more difficult task, and the reason why we need benchmarks...

[ocastilloreyes]

I agree, too. In my case, the meshing strategy depends on the frequency, the conductivity values, and the polynomial basis order to be used (in mi FEM code, I support polynomial-variants: 1,2,3,4,5, or 6). And yes, with my modeling results I have verified that the quality of the mesh positively / negatively impacts the electric field results.

I think that we would have to define the basic inputs for each code and from that, try to build a "mini" benchmark that is compatible with each tool. Although I am afraid that this is not possible ... other ideas?

[Moouuzi]

What's the final decision about models? Are we done with

1. 1D/ 3D blocks in layered earth
2. Figure 4 of Marlim

or do we want to model something else (Figure 5 of Marlim, something non-marine:-)). I think, for the paper, these examples with proper Code and model descriptions are already enough Content and consumed already enough time.

[prisae]

For my point of view it is enough, at least for now. Comparing results is not the only point of the paper, IMHO.

• We compare easily installable modellers (all in Python)
• We elaborate on the similarities and differences, and on the advantages of each one, e.g., in which cases which one is better etc, give some advice.
• And we compare some results, providing online all scripts to reproduce it (really EVERYTHING, not like with Marlim3D or many other 'open/reproducible' cases... for this I will have to ask Paulo if we can publish the extended calculation model, or if they will put it on zenodo themselves):
  • 1D model
  • Blocky model with above 1D background (I think this is very valuable for a first step comparisons of any 3D code, and I think it is an important contribution, similar to the MT paper).
  • Very complex 3D model.

My opinion: For now it is enough: I shall draft a paper, and pass it around one by one (fingers crossed by end of February). After that we will see the length of it, and can still decide whether or not we need another example. But I guess it is already going to be lengthy as it is.

Does anyone has a strong, differing opinion (@Moouuzi @ocastilloreyes @lheagy)?

Thanks @Moouuzi for all the help with the FE models.

[prisae]

(At some point [after the paper is written], we shall streamline all dataformats, suspecting to put it into NetCDF4(HD5) format, probably in EMGS style file format, given they are CSEM-like data; I'll look into that, unless someone of you has already experience with that.)

[ocastilloreyes]

I think that the content is enough to meet the main objective of the paper, especially if we can highlight the points mentioned by @prisae.

Next week I will be in a workshop and project meeting in Mexico. Still, I will try to catch up with the models, especially with Marlim3D ( which scared me :-) )

Good holiday Luis