Reading of background model created by CRAVA

[alfbr]

Time shift for SegY CRA-793

[alfbr]

All output results should use same time shift as input.

[hgolsen]

The estimated background model on segy format will follow the same shift as input segy (see file for an example). Have tested to run Crava with its own background model, and it was ok.

[alfbr]

Did we reach a conclusion here?

[hgolsen]

This should be ok. We have fixed a bug related to this issue. We have tested a case (from Flesche with 1900) where we first estimated BG and wrote it to file (segy) and then reran the case where we used the estimated BG files as input. This worked.

[alfbr]

@hflesche can you confirm?

[hflesche]

I have made a test where the input background models and the input seismic data both have start at 1900 ms (given in trace header byte 109-110, and also with 1900. Background files saved by Crava does not have a time offset in trace header, and neither do the inversion results or the saved seismic (synthetics/residuals). The saved files should all have the time offset stored in the trace headers.

[hflesche]

@alfbr, @hgolsen: Test results ready regarding the issue. Still open.

[hgolsen]

Ok, then I misunderstood the problem, sorry. Crava doesn't use the offset information in the traceheader of the cube (for reading or writing). When it reads the segy-cubes it uses the offset given in the modelfile. We will look into this now and try to add the information to all the written cubes. A warning to the users if the input segy offset in different from what is given in the modelfile would also be useful.

[hgolsen]

Regarding writing segy-cubes with offset in traceheader. If there are no segy-cubes (forward model / estimation mode) is it reasonable to take offset from the top of the topsurface of the interval the estimation is done in?

[hflesche]

The ideal in that case would be that the user sets a fixed time limit for start time, but lacking that the top of the top surface is a reasonable guess. Normally you would wish to have some padding in addition, e.g. half of the wavelength.

[hgolsen]

Ok, we can add a under (where you specify output as the output format) that will be used for written segy cubes. -If this keyword is not given, we will use start-time of input segy. -If both are omitted we can use top of topsurface.

[hgolsen]

This is now checked in. Written segy could will now be written with offset, and using is optional when reading segy cubes from file. We have also added the -keyword under , which can be used to write segy-files with offset when there are no segy-cubes available (e.g. forward modelling/estimation mode).

[alfbr]

Please clarify. Are new tags introduced, if so which? How does the optional part work, what is the default?

[hgolsen]

Sorry, I forgot the "\" before the tags, so they got lost. The new tag is the

It is as follows:

-- ---- yes <\storm> ---- yes <\storm> ---- 2000 <\segy-start-time> This segy-start-time-value is used for writing of segy-cubes. It has to start above the top surface, and it will add padding between the start time and the top of the surface. If this tag isn't given, the default is to take this segy-start-time from the input seismic data (either from the given in for input data, or if that keyword isn't given it is taken from the traceheader of the seismic segy cubes). The purpose of this new tag is mainly to add offset to written segy-cubes if you do not have seismic data (like forward modelling). Howerever, if you do not have seismic data, and do not give under will use offset from the top of the top surface.

[hflesche]

Attempted to run CravaSimplified.xml, both as it has been run earlier and with the time taken from the trace header. As I understand it, if the is not included in the xml-file and all inputs are consistent in the value in header position 109-110, than Crava will understand the seismic time offset. The latter case gives core dump. Please test and debug @hgolsen

[hgolsen]

Tried to run this case without (offset taken from the files). The seismic data read fine and I get the following logging:

 UTMx         UTMy        IL    XL   Offset   Samples   dt(ms)  Length(ms)

---

495956.00 6719999.00 2000 1608 1900 376 4.00 1500.00

Using offset 1900 taken from trace header.

Crava crashed when reading the background, but I get the following logging:

 UTMx         UTMy     CoScal        IL    XL   Offset   Samples   dt(ms)  Length(ms)

---

495956.00 6719999.00 1.0 2000 1608 0 376 4.00 1500.00

Using offset 0 taken from trace header.

Do you get the same? We can debug and see why Crava crashes. But the background I used with CravaSimplified (BG_AI_crop.sgy etc) has an offset of 0, while the segy has an offset of 1900.

[hflesche]

I have re-checked the background AI file, and it seems to be in line with the rest. The traces have a time offset of 1900 ms, and there are no deviating traces reported in the RokDoc segy import, see attachment. SEGY time offset.pptx

[hgolsen]

You are right. This was a bug, this is fixed and checked in now. Please try again the next time you update Crava.

[hgolsen]

@alfbr there are also two new tags implemented for this issue. It is under , both under and . It is used for manually setting the location if it differ from the standard format, similar to the other tags.

[alfbr]

But old tags still work (i.e., are the new tags non-intrusive, only exposing new functionality)?

[hgolsen]

Yes, that is correct.

[hflesche]

Re-ran test today to check that segy header gets assigned the time start value. Works according to expectations! More exotic variants will not be checked, so I reckon the issue can be closed.

[alfbr]

Fantastic, huge thanks for testing and fixing! Closing.