3D Model

You can find the 3D model in the notebook notebooks/MarlimR3D.ipynb.

Questions:

• We have to define our survey. The model is very extensive, and I think we should just have one line or so.
• The paper only presents the data as is; they do not compare the model with and without hydrocarbons in the reservoir. I wonder how big the difference would be.
• How feasible is this model for everyone? The original model has some 466 million cells, for the calculation they reduced it to 90 million cells, if we just do a line or two then we can reduce that much further I think.
• The model is VTI, OK for everyone?

Any inputs on this model @Moouuzi, @ocastilloreyes, @lheagy ?

That is how the horizontal resistivities look like:

Marlim R3D

Papers

• http://www.scielo.br/scielo.php?script=sci_arttext&pid=S2317-48892017000400633
• https://library.seg.org/doi/full/10.1190/geo2018-0452.1
• https://library.seg.org/doi/10.1190/segam2018-2997281.1

DATA

• https://zenodo.org/record/400233 # Model
• https://zenodo.org/record/1256787 # Data
• https://zenodo.org/record/1807135 # Data With Noise

Model and survey lines

... TODO Model and Survey...

3D block model

... TODO Results ...

(Related to #4.)

I started with the Geophysics-LaTeX format, as I had that at hand.

But thinking about it, I guess it would be better if we make a Sphinx-doc using .rst-files. This way, a lot would already be rendered simply on GitHub (except math, but there won't be too much of that in this article), and we could link it to rtfd.org to have it compiled properly each time. I think this would be nicer to collaborate on GitHub.

The biggest advantage would be, that at the end we could easily include it, or part of it, into our code documentations for each project (except MARE3DEM, I don't think you use Sphinx for documentation, right?).

The only downside is that at the end we'll have to copy-paste-transfer it to the journal format. But that is a one-time thing and should not take a lot of time.

What do you think? (@lheagy, @Moouuzi, @ocastilloreyes, @kerrykey)

I started the paper-repo in a private repo on my GitHub. However, in the spirit of open-source, and given that nobody can takes us away our codes anyway (no-one will steal our paper idea), we should probably do the whole thing in the open.

I thought about making a public repo

• https://github.com/empymod/3d-csem-open-source-landscape

However, if you prefer a neutral space we could also do it at

• https://github.com/opengeophysics/3d-csem-open-source-landscape

What do you think? (@lheagy, @Moouuzi, @ocastilloreyes, @kerrykey)

1D Model

You can find the 1D model in the notebook notebooks/BlockModel.ipynb.

Please have a look and give your feedback (@lheagy, @Moouuzi, @ocastilloreyes). If everybody is fine with it then we can fix this, so everyone can try to model it with their codes.

I used a rather coarse grid now for testing, so precision is not overwhelming right now (but with roughly 2 minutes reasonably fast to calculate). I might refine this for emg3d once we agree on the model.

Questions:

• How do you need the data? Is this notebook sufficient?
• Should we make it VTI? Can all the codes handle VTI resistivity?
• Currently x-directed dipole, 200 m long. Could make that an arbitrary rotated dipole - can all codes handle arbitrary rotated dipoles?

Model and survey lines

1D background, compared to empymod

3D block model

(Related to #4.)

Now I will try to get the Marlim R3D model working...

I think this paper can get easily too long, as we are potentially including five different codes. So I would personally limit it to

• code description; which should include;
  • Equation system it solves;
  • the used discretization possibilities;
  • domains (frequency, time);
  • details (anisotropy; el. perm. and mag. perm.);
  • other things (inversion; other methods);
  • speed and memory estimation;
  • plans for next features.
• forward modelling with numerical results (see #4)
• discussion about the landscape, where which model excels and why, etc.

So in this scenario, the inversion capabilities fall under Code Description. Input by mail from others:

Lindsey:

One thing that would be nice to speak about (though examples might be out of scope) would be the inversion side of things. This has enough scope that it could be a follow-up paper later on, but giving a few thoughts on how to move forward on inverting data might be a worthwhile addition. This might fit under a more generic heading along the lines of "Moving forward" or similar that would give a bit of space to also talk about future plans for each project.

Raphael:

I agree to Lindsey that discussing and working on 3D CSEM inversion is the next step. Nevertheless, I tend to Dieter’s primary idea to focus on modeling only for now. Maybe we could add a few comments on the potential of our modeling codes for inversion.

The current working title is

Status of the open-source landscape for 3D CSEM modeling

but we can probably come up with something better. Please put your ideas here.

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.

Where shall we submit?

• Geophysical Prospecting
• Geophysics
• Computers and Geosciences
• ?

I am thinking of GP at the moment, but I am very open to suggestions.

There exists probably at least a dozen or more open-source EM 3D modelling codes outside of geophysics, which could also be used to model CSEM data. This is obviously outside of the scope of this paper, but we should have a paragraph mentioning it, and citing a few.

Things to discuss:

• Author order (probably to be discussed at the end)
• How many authors per code?

I thought about one author per code, which would give five authors. But then some of the projects are bigger and might have more contributors, so we could think about max. 2 authors per code, which then would give max. 10 authors? Opinions?