Ability to use arbitrary dt, nt, t with GeometryOOC

[kerim371]

Hi,

Sometimes I have a geometry SEGY file that describes the source and receiver positions and I wan't to compute forward wavemodeling for example. In that it is not necessary that I wan't to use the same trace length and sample rate as given in SEGY.

Out of core geometry sets dt, nt, t parmeters from SEGY. Of course I can modify them after the GeometryOOC is created but it seems JUDI won't work if I change nt for example (I get dimension mismatch error).

Modifying trace length and sampling rate directly in SEGY file may be not so convenient.

Does it make sense to provide such API?
I expect for forward modeling it is not as complicated as for inversion purposes as inversion requires loading field data that should be trimmed or expanded depending on geometry's nt parameter. In the same time proving such API only for forward modeling will only bring confusion in understang the logic of JUDI.

[mloubout]

Sorry not sure I follow. So you are using the segy only for the position but you want different times?

[kerim371]

Exactly.
Source/Rec positions from SEGY
dt, nt, t user defined.

[mloubout]

That should be fairly easy to add as optional inputs. But isn't it a bit overkill? Because now you have a dataset with data that you won't use? Or do you want to resample the data in the segy to these new time parameters?

[kerim371]

Optional inputs to geometry? I tried to set dt, nt, t right after geometry OOC is created but that didn't worked as it seems JUDI gets dt, t, nt from SeisCon when loading OOC geometry to IC (see link and probably there are other OOC geometry functions that read t, dt, nt from SeisCon rather than copying it from input OOC geometry)

No, in contrary I'm trying to avoid modifying SEGY file when doing forward modeling.
If we talking about forward modeling then I don't think there will be unused data (as I know we don' t need traces from this SEGY file, only geometry and timings). I presume I can do this with IC geometry but OOC doesn't seem to work yet.

But when dealing with inversion then it is probably easier to truncate (if interesting region is somewhere above) or resample SEGY.

[mloubout]

I mant it shouldn't be too hard to add it to JUDI sorry, yes it is not supported for now.

The SEGY format is design to contain data, 99% of the content of the file is the actual data so carrying around this SEGY dataset just to read the geometry is quite overkill. So if you are only interested in pure modelling I would use GeometryIC.

I don't mind if dt, nt, t are added as optional inputs but then all the safety check should be added to judiVector so that it is not possible to associate the data of this SEGY to the incompatible/modified geometry.

[kerim371]

I will try to make a PR