3D Model

[prisae]

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.)

[Moouuzi]

Meshing the layers worked out without any issues with my tools. See attached screenshot and vtk in the zip directory. I have not included the layer named "top of resevoir" so far, as this one intersects the others. Good thing, with currently 60k nodes only, there is much potential for refinement, improving quality or p2 polynomials.

I have not viewed the resitivity data so far, questions:

1. Looks like resisitivites are available as segy files - can someone convert them to easy-python-readable 3D gridded data or xyz data? gridded data would be probably best for the nearest neighbor Interpolation we require to assign the resistivites to our tetrahedra.

2. Are all of these structural constraints reasonable for conductivities or sometimes just seismic boundaries? I would keep the model as simple as possible and prefer higher discretization in other areas, for instance, at the sea-bottom.

3. somehow include the reservoir explicitly, but that's the last step.

marlim_FE_mesh_layers.zip

[prisae]

Cool!

Re resistivities: Just look at my notebook. It leads the segy-file and puts them into an ndarray... I load them afterwards into discretize, so you have a simple tensor mesh of it.

I am currently working on the 1D model, will put an updated version up soon.

[prisae]

All you need is

import segyio
import discretize    # for the meshing
import numpy as np
import matplotlib.pyplot as plt

res_h = segyio.tools.cube('../DATA/Horizontal_resistivity.sgy')[:, :, ::-1]
res_v = segyio.tools.cube('../DATA/Vertical_Resistivity.sgy')[:, :, ::-1]

nx, ny, nz = res_h.shape
dx, dy, dz = 75, 25, 5

x0 = 1e100
y0 = 1e100
with segyio.open('../DATA/Horizontal_resistivity.sgy') as f:
    for i in range(nx*ny):
        if f.header[i][segyio.TraceField.CDP_X] < x0:
            x0 = f.header[i][segyio.TraceField.CDP_X]
        if f.header[i][segyio.TraceField.CDP_Y] < y0:
            y0 = f.header[i][segyio.TraceField.CDP_Y]
x0, y0 = x0/10, y0/10

mesh = discretize.TensorMesh([np.ones(nx)*dx, np.ones(ny)*dy, np.ones(nz)*dz], x0=[x0, y0, 'N'])

mesh.plot_3d_slicer(np.log10(res_h))

to get

So you have resistivities as a ndarray.

[Moouuzi]

Resistivity (horizontal as example) mapping:

Qualitative results for x-directed line Tx (E on one slice, H on the other)

Sorry about the delay, it took me some time to do some other important things… Today, I got the 3D Interpolation of the Marlim resitivity model on my tetrahedral mesh runnning, see attached screenshots. here, we have a mesh with about 150k nodes, which can be comuted with second order polynomials in 40 minutes computation time with 1.2 TB RAM. First order would require max. 5 minutes I think. We could also think about a mesh with smaller elements for a more accurate conductivity mapping, but in this case the computation needs to be done with p1. We need to do some experiments now to estimate the effects of the conductivity mapping, hopefully, it is not too imporatant due to the averaged condcutivities in this huge volume.

@ Dieter, do you already have computed some results for the Marlim model to start a first comparison? Are there any information about Tx/Rx or is that our choice?

[prisae]

That looks great! No, I haven't delved into src/rec yet, I first wanted to know if the model works for everyone.

The publication has the survey layout, quite an extensive grid. We could probably agree on a subset of it. Their responses are also published, so we can compare to those.

5 and 40 minutes sounds very reasonable. How many CPU does it require?

I'll hope I'll get to it as soon as possible. I have to get out two other things plus a seminar next week. Fingers crossed.

[Moouuzi]

see first p1 and p2 modeling results in the new "custem_input" branch. Files for reproducing my computations are locaed in the "custEM_layered_blocky" directory. The interpolated results are located in the data/custEM_results/ directory for all 3 lines, the file description should be self-explaining.

The file format is nx3 arrays, 'real' for coord and 'complex' for E or H. If another structure is more convenient for you, just tell me.

I'm very interested if I set up all parameteres correctly and also in the boundary effects of the limited horizontal extent, hope they are not to strong. Currently, both models require ~90s computation time with 32 cores.

[Moouuzi]

sorry, wrong issue, please consider the last comment related to the layered-earth/block model topic and have a nice Weekend!

[prisae]

@Moouuzi have you already look into the acquisition layout of Marlim3D? Otherwise I'll do that tomorrow afternoon, and save it in a sane data-format for everyone.

I will also think of I good way how to store the data, and a naming scheme. We should probably leverage xarray for it.

[Moouuzi]

Hi Dieter,

I just had a short look on the publication and the data repository, but have not found any coordinate Rx or Tx files. That's what they write:

CSEM ACQUISITION GEOMETRY Full-azimuth CSEM data were simulated for a total of 500 receivers located on the irregular seafloor of the MR3D model. For each receiver, sources were located along 45 towlines having a spacing of 1000 m. Towlines were positioned along 25 east–west lines and 20 north–south lines for each receiver. Figure 1 shows the receiver positions and towlines superimposed on the bathymetry of the MR3D model. Each east–west towline has a length of 42 km, and each north–south towline has a length of 47 km. Both directions are extending 11 km away from the first and last receivers at each towline (our volume of interest). Source positions were spaced at 100 m along each towline for a total of 201 source positions along each towline. The source is a 278 m long horizontal electrical dipole, oriented parallel to the towline.

[prisae]

@Moouuzi Yes there are. All the data is in .nc (NetCDF) files. So you can load them, for instance, with xarray, and then the array itself contains the coordinates and much more information. Here an example from https://zenodo.org/record/1256787 xarray.load_dataset('../../mr3d_04Tx001a_04Rx004a_addednoise.nc')

<xarray.Dataset>
Dimensions:    (csamp: 1, d_masktrace: 6, d_noisetrace: 6, dtrace: 6, jtrace: 1, nogrid: 1, nsamp: 2652, nx: 1, ny: 1, nz: 1, strace: 6)
Dimensions without coordinates: csamp, d_masktrace, d_noisetrace, dtrace, jtrace, nogrid, nsamp, nx, ny, nz, strace
Data variables:
    grid       (nx, ny, nz, nogrid) float32 9.96921e+36
    srcpos     (nsamp, strace) float32 372275.0 7529812.0 ... 90.0 -1.3691331
    jsrc       (nsamp, jtrace) float32 1.0 0.0 1.0 0.0 1.0 ... 1.0 0.0 1.0 0.0
    emf        (nsamp, dtrace) float32 3.4944327e-14 ... 1.0489886e-12
    sigma_c    (csamp) float32 9.96921e+36
    emf_noise  (nsamp, d_noisetrace) float32 -6.555357e-16 ... 4.24844e-13
    emf_mask   (nsamp, d_masktrace) float32 1.0 0.0 0.0 0.0 ... 0.0 0.0 0.0 0.0
Attributes:
    version:                   0.0
    prochist:                  merging;/apps/EMGS/SBLwiz/1.26.27/bin/eldatnav...
    loghist:                   merging;eldatnavfix - Version: R-6-1-2;Elnavco...
    logid:                     unknown
    surveyid:                  MR3D
    jobid:                     MR02_1km_noise
    recid:                     04Rx004a
    lineid:                    04Tx001a
    domain:                    frequency
    coilid:                    unknown
    x_r:                       383275.0
    y_r:                       7529812.0
    z_r:                       269.9515
    psi:                       0.0
    phi:                       90.0
    theta:                     0.0
    psi_uncertainty:           0.0
    phi_uncertainty:           0.0
    theta_uncertainty:         0.0
    receiver_heading:          90.0
    sigma_f:                   0.0
    dataset_date:              23-03-2018 20:54:52
    dataset_author:            NetCDFgenerator 2.1
    dlength:                   275.0
    dlength_trp_fe:            0.0
    dlength_te_tp:             0.0
    geodetic_datum:            unknown
    projection_type:           unknown
    projection_zone:           unknown
    long_of_central_meridian:  unknown
    grid_origin:               unknown
    grid_coord_at_origin:      unknown
    scale_factor:              unknown
    scale_factor_long_lat:     unknown
    planned_vessel_speed:      unknown
    towline_relation:          
    clock_drift_ppb:           0.0
    format_type:               complex_demod
    t0_emgs:                   01-01-1970 00:00:00
    t0_unix:                   0.0
    nf:                        6
    freqs:                     [0.125 0.25  0.5   0.75  1.    1.25 ]
    dx1:                       0.0
    dx2:                       0.0
    dk1:                       0.0
    dk2:                       0.0
    dt:                        0.0
    approx_source_heading:     90.0

I don't have the time today, but tomorrow afternoon I will read them all and create some survey files, which just contain coordinates etc. I'll let you know!

[prisae]

I will also write a short script that you all can then use to load the measured data for comparison. Fingers crossed we can reproduce them. Otherwise I'll get in contact with the guys, if there seems to be some information missing.

[prisae]

Yes, they produced a LOT of data. I think we should restrict ourselves a bit... My suggestion: We choose the middle source-acquisition lines E-W and N-S (red lines in the figure), and two receivers on both lines (blue squares). And then apply reciprocity, so we model four source positions, and show the receiver line. So in total four sources, each source with a E-W and a N-S receiver line spanning the whole field. What do you think? So I'd prepare the coordinates for it.

[prisae]

Just realized an error in my thinking. To compare we obviously only have the actual receiver positions, even if we use reciprocity. So we could move the source locations a bit further out. Either way, I think it would still be OK, do you agree? Our red receiver lines will then just stop where the actual yellow receivers stop.

[prisae]

I started the branch https://github.com/prisae/3d-csem-open-source-landscape/tree/marlim-results for Marlim-related development. Again, I hope you have all write-access to that, otherwise let me know.

[Moouuzi]

I don't know if I understood you corretly. My thoughts:

1. place as many Tx as you like - if computed at once, with the stored factorization, multiple Tx solutions are rather instant with MUMPS.

2. I would prefer a 2D receiver array for this model! Field changes can be analyzed very well on a 2D grid, also with some statistical measures. I'd suggest something like a 10 x 10 km grid with 100 m point spacing as a first shot. Is it possible to realize this with regular grids?

3. of course, we could also use one of the included lines to compare our results on a profile.

[prisae]

Raphael. I am absolutely open to any suggestion. We can model all receiver (the regular grid) and choose a few sources. Feel free to suggest a layout we should use, and we'll comment on it and if everybody agrees then fine!

So help me here, because I am not familiar with MUMPS: You say that with MUMPS the price to calculate one source location or several source location is the same? How does that work? In my case each source position is a new calculation (that is why I mentioned reciprocity). Although I guess I could start with the solution of the previous source, which will be already close-ish, if sources are close. Never tried that, but will do.

[prisae]

Looking at the paper of the data (Correa and Menezes, 2019, Geophysics) I think it would make most sense to reproduce their figures 4 and 5. Figure 4 is a classic amplitude vs offset plot, figure 5 is a 2D plot as you suggested Raphael, so it fits everything and we can compare it to already published figures, which I think is a plus.

To start I suggest we only look at one frequency, say 1 Hz, until we know that everything works fine. Similar, we focus first on figure four, and if that works we can tackle figure 5. Here Figure 4a:

So in the branch https://github.com/prisae/3d-csem-open-source-landscape/tree/marlim-results there is the notebook MarlimR3D-Acquisition.ipynb => I load the data and try to reproduce the figure, but I still struggle at the moment to understand exactly how data is stored and how they produced the plot. If you have more experience with that please have a go!

I am actually inclined to write them and ask if they would have scripts that reproduce their figures? That might save as loooots of time, particularly for figure 5...

[prisae]

I just wrote the two authors, let's see if/what they answer.

[ocastilloreyes]

Hi, my thoughts:

• I also prefer to use a 2d grid to plot and analyze the measurements. This will give us more information to discuss the scope of each code.

• In my case, obtaining solutions for different source positions is not a problem. I can use MUMPs as suggested by Raphael or another solver that supports multiple right-hand sides.

• I agree to start with a simple test as suggested by Dieter. Correa and Menezes, (2019, Geophysics) paper is a good starting point. I will try to review the format you have posted on the branch (I hope to do something because I have little experience with the format), although I would prefer to write directly to the authors, I think it is more profitable...

[prisae]

Yeah, don't bother about the format, we wait first a day or two to see if the authors reply to my email.

[prisae]

I haven't heard back from the guys. I wrote now Leo Uieda (the guy from fatiando) - for the off-chance that he as a Brazilians knows these Brazilians. If not, we'll have to figure it out ourselves...

[prisae]

Good news! I heard back from Paulo. There was a problem with the attachment, so he will send it again. Also, I rephrased my question, asking more for the how did the calculate what they plot more than how did they plot. I'll let you know as soon as I hear more.

Hello Dieter

Sorry for taking so long to respond. This Xmas period is always busy for us.

We appreciate your kind words about our work. We are happy that both model and data will help others' research. Marlim is an ongoing project that is still active. Currently, we are working on the MT dataset. We expect to release it at Zenodo by Q1/Q2 2020 and present it to the community in the next SEG meeting. The MT modeling demand additional requirements as the knowledge of the basement and Moho surfaces in a greater areal extent than the published cube.

About the CSEM model and dataset. Yes, you're welcome to use both at will. If you need any help, please feel free to contact us anytime.

Regarding your queries about the figures: To generate such quality figures, we indeed applied a semi-automatic or a semi-handcrafted methodology.

Figure 4 - We used commercial software - Graphexpert Professional (https://www.curveexpert.net/products/graphexpert-professional/). It is cheap, US$ 59.00 for a perpetual license. You can test it for free. What we have done was: To each field component, we exported ASCII files for each frequency (offset, and field amplitude). We then imported these into Graphexpert, plotting all frequency curves in the same graphic. We saved the project in the *.gxp format. Please see attached the Ex inline field file, and if that works for you, we can send the other components.

Figure 5 All maps in the paper (Fig 1, 2, and 5) we made using the open-source geographic information system Quantum GIS (https://www.qgis.org). What we did was to have georeferenced all features, i.e., Rx positions, Tx lines, the outline of marlim, and contour maps in GeoTIFF format. The contour maps were generated at different programs, Fig 1 and 2 were exported from opendTect and Figure 5, the normalization map was exported from SBLWIZ, the commercial solution we used to forward-modeling MR3D. Attached you will find two Qgis projects: location_map normalization_maps. Unzip and open the .qgs files through Qgis (3.10). Assuredly, it will complain about the path of the objects. You will have to point to the correct path. The zip file contains all needed features, both vector (shapefiles .shp) and raster (GeoTiff).

If you have any issues with Graphexpert or Qgis, we are here to collaborate with you.

Thank you for using our work. Best Regards Paulo and Jorlivan

[prisae]

Here are the files from Paulo, the link is valid until 26/12: https://wetransfer.com/downloads/b84b9ec8031c717d088bf2e7c1d0a45f20191219015548/40c1f0efe0d11febb25b77873190889320191219015548/d64368

Unfortunately I don't know much more than before. His second email:

Hello Dieter

OK, now I've understood your doubt.

Sblwiz outputs the fields normalized by the Tx dipole.

About the normalization map in Fig. 5. Please find the full explanation in section Frequency ratio normalization and Figs 6-7 (Pages SH4-SH5) of our paper herein attached. The maps of figure 5 were generated within Sblwiz; we have to check out what component of RR was used.

Best Paulo

The joy of using commercial software, I guess (Sblwiz outputs the fields normalized by the Tx dipole.). I will try next week or the first week in January to reproduce their Figure 4, for a start. Any inputs welcome ;-)

[Moouuzi]

After the last comments, I think we should discuss if we want to reproduce their results or just design our own marine CSEM Survey layout. The first option seems to require more and more effort and is not necessarily required for the overall goal of our paper in my opinion. What do you think?

[prisae]

Yes and now. I think it would be good to reproduce Figure 4 (normalized amplitude vs offset), to show that it is the same. But Figure 5 (2D plots) might not be worth the trouble, and you can suggest stuff here.

I will have a look at Figure 4 next week or the first week in January.

Here the latest info regarding Figure 5:

Hello Dieter

We used the intowing component (negative offsets) to produce Fig. 5. That component illuminates the background geology at MR3D.

Best regards Paulo

[prisae]

OK, after lots of try-and-error I was able to reproduce Figure 4 of the paper.

Here the clean data version:

The version in the paper is one with added noise, I have this one also in the notebook.

So I do think we should first reproduce this receiver location. You can get the source (inline and broadside) and receiver locations like this (relative from the notebooks-directory:

coords = np.load('../data/marlimFig4Coord.npz')
src_in, src_br, rec = coords['src_in'], coords['src_br'], coords['rec']

The notebook to reproduce it all is here: https://github.com/prisae/3d-csem-open-source-landscape/blob/marlim-results/notebooks/MarlimR3D-Acquisition.ipynb

[prisae]

How is it going with the MarlimR3D modelling (@Moouuzi , @ocastilloreyes)?

[Moouuzi]

haven't worked on this yet, "Endspurt" for submitting my Thesis. Anyway, I know we need some further progress if we want to finish until end of the year :-), so I will provide some results within this week. Including your Tx/Rx information should not take too much time. Let's hope it will match the plotted data well.

[prisae]

No problem, thesis has always priority!

I am off next week on holiday, and the week after busy with consortium meeting. But I hope to get a draft of the text in February, given we know that both models work fine and we can do the whole thing.

[Moouuzi]

Im not so familiar with marine CSEM surveys ... @prisae:

1. Is it necessary to model the real 278 m dipole Tx or is it reasonable to approximate it via dipoles/bipoles of a certain length? Do you know how they implemented the sources?

2. Looks like in contrast to semi-airborne, Rx are fixed and Tx is moving. Is it possbile to apply reciprocity (I think, with extended sources it does not work, but maybe it is possible using HED sources instead of the real ones), or is every Tx required to be modeled?

3. If I understood correctly, the data shown in their paper is modeled (with or without noise), not measured. (which I thought before). In that case, it will be even more interesting if we can reproduce the results in a certain misfit range.

4. They write: "the electromagnetic fields of the noise-free data were calculated with 0.1 s time steps, at a maximum number of 200,000 time steps, and convergence accuracy of 10^−4. We normalized the electric fields by the dipole moment. " What do they mean with these times? Does the last sentence imply that they use HED Tx and normalize by current and length?

[prisae]

1. I assume you will see the difference up to about 1-1.5 km offset (~ 5 times source length, as a very crude rule of thumb). But just start with whatever is easiest. We can adjust these 'details' later, once we know we are in the same ballpark.
2. Yes, Rx are lowered on a regular grid to the seafloor, and the vessel with the source navigates over it. But I will use reciprocity as well, that is no problem. From http://www.emgs.com/multimedia/155/The-marine-EM-method.jpg (PGS used to do the streamer system when I was still with them. However, PGS ceased any EM activity, so EMGS is, basically with very few exceptions, the only commercial competitor in oil and gas at the moment.)
3. Correct, it is modelled with Schlumberger software, if I am not mistaken. And that is exactly why it is an interesting case, so we can compare it to an 'industry' modeller.
4. I think their modeller is in the time-domain, and then transformed to frequency domain. So these parameters are just modelling parameters. Yes, the last point means that the amplitude was divided by 278. So if you model a 1m dipole instead then it should be the same (using a 1A source, otherwise dividing by the amps too).

[Moouuzi]

Thx Dieter!, I have an idea of how to start … let's see what the outcome will be.

[Moouuzi]

@ prisae: Are you sure src_in and src_br coordinates are correct. If I use them as they are and refine them (see sketch at ocean bottom), both src lines are parallel to each other. I thought, they should build a cross (maybe with the intersection over the Rx or in some offset) or am I mistaken?

[prisae]

Yes, and no.

• Your receiver should be exactly ON the source-inline, not in the middle between the two lines. See Figure 2 in the Geophysics 2019 paper:
• The receiver is 50 meter BELOW the source lines, not above. Remember that in oil and gas you use generally positive down z, it is a conservative industry, that will never change...
• So one is the inline, the one exactly in line. The other one is broadside. You might not think so. But it is 1 km off, which is quite a lot, so it is broadside.

[prisae]

Ah, now I see where the confusion comes from. Remember, we are in the sea, the source is towed behind a vessel. So the source is ALWAYS Ex. So if you have the receiver in x-direction, but your towline would be cross to it, as you expected it, your amplitudes would be close to zero (x-rec to y-src). Then if you take the other receiver it would be inline again, and not crossline. In CSEM you always measure source and receiver aligned, not perpendicular. It is where most of the energy is.

[prisae]

Maybe that simple sketch helps a bit

[prisae]

Of course, that is the ideal case when source and receiver are aligned like this. In reality you don't know the receiver orientation per se, as the receivers are dropped to the floor without real control of how it will land on the sea bottom. There are various methods to get the receiver orientation out of the data, from which you create then inline and broadside data by linear combinations of the two signals.

[ocastilloreyes]

@prisae Sorry but I had to finish some project closing reports. I will try to devote some time to you later this week. I'll tell you how it goes ...

[prisae]

No problem at all! As I said, next two weeks I have almost no time at all. First holidays, then consortium meeting. But I do hope do get a draft written in February, to send around to you guys.

[Moouuzi]

Thanks for the clear explanations Dieter! I will run some Marlim tests over night the next days...

[prisae]

Cool!

[Moouuzi]

What a modeling mess ... anyway, there seems to be some hope (black are custEM p1 test results on a quite coarse mesh, all +400 inline and broadside Tx calculated as 20 m dipole sources, requires ~10 min per frequency with 32 corse):

results.pdf

Even though I managed to resolve some bugs and find a reasonable setup for custEM, there are many things unclear. Most important, it would be excellent if we can get some more details about their modelings, so far I have in mind:

1. Did they realy modeled in time-domain and if yes, why?

2. More details about their domain size and lateral continuation of layers outside of the extent of the interface-topography files, or boundary conditions. Actually, the provided lateral extent (~12 km in each direction) of resistivites and layer information is way to small for having reasonable results at the great offset such as 10 km.

3. Have they used reciprocity or calculated single models for all the +400 Tx?

4. "62 core processors of our local Intel Xeon E5-2690 v2 @ 3.00 GHz cluster (3968 GB memory per node) with a runtime of approximately 9 h for each experiment." - does anyone understand what they mean with "each experiment"? I think that will be approximately the calculation time with 64 cores for one frequency with p2 on the mesh I designed for p2 but tested with p1 (results above), I will know tomorrow…

5. Information About the Rx positions relative to the water subsurface in the mesh - just below or just above the seafloor means a difference, in particular for the Ez component. (At the earth/air interface this is a VERY critical point). That might explain the greater misfits for Ez in the shown figure.

I will run some further tests in the next days. Anyway, I'm quite happy that we are already "in the same ballpark" :-)

[prisae]

Well, that is encouraging! So we definitely get that to work. If both our results diverge by some constant factor we will definitely have to go back to them and ask about details.

To your comments:

Receiver positions

It is marine, so on the seafloor, above the interface (in the water, not in the subsurface). However, I don't understand your question. The exact receiver position is contained in the data (if you look at my example notebooks, I extract the source and receiver positions from the data).

Regarding modelling etc.

There is some more info in the paper (Correa and Menezes, 2019, Geophysis).

Some excerpts:

We conducted the 3D forward modeling using a parallelized commercial fast finite-difference time-domain (FDTD) CSEM modeling algorithm (Maaø, 2007). The same code was adopted in the SEAM project (Stefani et al., 2010)... The air layer was included in our simulations via a non-local boundary condition at the water-air interface (Wang and Hohmann, 1993; Mittet, 2010).

and

The electromagnetic fields of the noise-free data were calculated with 0.1 s time steps, at a maximum number of 200,000 time steps, and convergence accuracy of 10^-4 .

There are so many ways to model 3D EM results. One of them is time-stepping, so FDTD is just a way of modelling, and you get a wide range of frequencies with one model (https://en.wikipedia.org/wiki/Finite-difference_time-domain_method). Have a look at this list if you want to get dizzy about the possibilities: https://en.wikipedia.org/wiki/Computational_electromagnetics

Also, there are probably hundreds if not thousands modellers out there. Even a lot open-source. The thing is that EM is used in many fields, on many scales, not just in geophysics. And I am sure many of these others modellers could equally well be used for geophysics, if you'd dig in.

Model extent

So they say that volume of 56 × 51 × 6 km; if they have another way to deal with the airwave then I assume that dimension is probably wide enough to model without extension. Also as they specify the dimension, and the cell widths, I assume that was exactly their model.

Runtime

Given it is time-domain I assume the 9 h refer to

• 1 receiver, all sources (using reciprocity);
• all frequencies;

but that is definitely something we could ask.

[prisae]

I just wrote Paulo with some further questions.

One addition to the above: From the data files you can tell that they used reciprocity, because the data files have names 'Tx001a'-'Tx025a' for the EW data set, and 'Tx001a'-'Tx020a' for the NS data set; so the sources have the names of the receivers, and the receivers have names of the sources.

[prisae]

Yes, I discussed it with Evert, and the boundaries are probably OK for FDTD and with the non-local boundary condition for air. So the 56x51x6 km model is really all they required to model (no air layer, no thicker boundary).

[Moouuzi]

Regarding approach

I was just asking about their FDTD solution because I didn't get so far that it could be faster/more accurate to calcualte in TD, if "only 6 freq." are required. On the other hand, i think my time-stepping approach related to (Um, 2010) requires the same time for a couple of decades as 20 of my frequency-domain solutions. Maybe they were interested in even more freq., making the TD approach beneficial. Probably, where are also some differences between FD and FE.

---

Regarding dimensions

56 × 51 km sounds reasonable, but:

My xyz-file information of the interfaces is:

"DEM original extent (x min, x max, y min, y max): 376230.89999894 401754.99999765 7504190.0 7531940.0" That means 25.525 x 27.75 km (almost exactly half of their size, do we need to upsacle something?)

regarding the resitivities of the sgy file (I use a right-handed system, so x/y are flipped with respect to the mesh):

nx = 371 75 = 27.825 ny = 1022 25 = 25.5 nz = 1229 * 5 = 6.2

That fit's well to the xyz-field extent, but just covers the central part of the area. Thus, my model is quite small in lateral direction. I'm appending a boundary mesh with a constant resistitivty value, since I have absolutely no information to extent the layers.

Am I missing anything? Do they only provided Information about the central part or do we maybe need to upscale everything with a factor of 2?

---

Regarding further modelings

My p2 computation took about 4 hours, smoother curves, but similar systematic misfits. All in all, I will probably require ~1 day computation time for 6 freq. with the no-reciprocity approach, but also all other receiver positions can be calcualted at once. Anyway, I will also try the reciprocity approach to see if there are differences.

[prisae]

Yes, I was equally surprised that they used a time-domain code. But then maybe that is all what they have access to, who knows. Or there might be other benefits. But I think for comparison reasons even better. If all yield the same results, then it is a strong case for all codes!

OK, now I see your doubts regarding the model, that is indeed strange... I'll have a look again.

Awesome regarding your p2 computations!

[Moouuzi]

just to avoid another potential bug:

I'm reading the conductivity information as provided by Dieters code lines above: To access the correct coordinates, I'm using

"mesh.vectorCCx (... y,z) ". Is this correct or do the resistivity values do not belong to cell-centered coordinate? It results in

x range [376243.4, 401768.4,] (dem range: 376231, 401755) y range [7504227.5, 7531977.5] (dem range: 7504190.0, 7531940.0) z range is clear

That is consistent to the dimensions of the xyz-filem, independent of the covered lateral extent

[prisae]

Yes, I did treat them as cell centred values too.

You are absolutely right, there is a discrepancy. I will ask Paulo about that as well. :+1:

[prisae]

Here some first answers from Paulo

We used Sblwiz from EMGS

Two problems arise when dealing with FD codes - how to represent batimetry and the mesh. This is particularly present in Marlim,where we have a strong batimetric effect and thin bodies. The SEG-Y model has 75 x 25 x 5 m, so we had to re-scale the model to a mesh that not exceeded the Sblwiz capacity. This was done in Petrel, as well the extrapolation out of the core of the model, I don't know exactly how Petrel do that, may be a kind of average (Jorlivan is the Petrel master, we will ask more details to the support team).

One possibility is to send our mesh to you, we will ask here if that is possible.

It seems that 56x51x6 km is the whole domain. but we will check carefully in the Sblwiz documentation.

We have done 2 runs (experiments), one for NS survey, and the other for the EW survey. All Rx, Tx and frequencies using reciprocity.