Potentially overly strict seismic4d filter

equinor / fmu-sumo

Interaction with Sumo in the FMU context

https://fmu-sumo.readthedocs.io/en/latest/

Apache License 2.0

0 stars 6 forks source link

Potentially overly strict seismic4d filter #348

Open SteffenEq opened 1 month ago

SteffenEq commented 1 month ago

Hi,

Currently the seismic4d filter requires base and monitor keywords: https://github.com/equinor/fmu-sumo/blob/e935ad1c85ff7ebcdb9ed6c7f22737a8a4f27f89/src/fmu/sumo/explorer/Filters.py#L2-L7

However, some seismic surfaces are defined by only having time values, e.g.

  time:
    t0:
      value: "2019-10-01T00:00:00"
    t1:
      value: "2020-10-01T00:00:00"

which will cause sumo_explorer.cases.filter(field=<field_name>, has=Filters.seismic4d) to filter out these.

Is this intentional?
Is the seismic4d perhaps overly strict?
Is t0 always base and t1 always monitor?
Is t0 always before t1?
Is it a metadata issue that these surfaces have t0 and t1 defined but with missing base/monitor?

Thanks!

equinor-ruaj commented 1 month ago

@mferrera @tnatt Is the base and monitor labels enforced by dataio?

tnatt commented 1 month ago

I had a look, and no it is not enforced, it will only be added if the user includes it when exporting data. Like the example below

ExportData(timedata=[[20200101, "monitor"],  [20190101, "base"]])

This is also allowed, but will not set the label

ExportData(timedata=[[20200101], [20190101]])

And it is difficult to enforce it, as it will only be applicable to seismic 4d data I guess. And ATM I don't think we have a way of tagging seismic data as 4d-data.. we have this issue https://github.com/equinor/fmu-dataio/issues/673 Once the issue is solved, we could include a check that the labels are set for these objects.

equinor-ruaj commented 1 month ago

Our default filter should probably not expect base and monitor to be set then @perolavsvendsen ?

perolavsvendsen commented 3 weeks ago

Offline discussions 4 nov 2024:

Each individual survey is 3D. It only becomes "4D" when two or more 3D surveys are combined.
Not possible to know when running a survey if it at some point will be combined with other surveys.

Should theoretically be sufficient that we check for the existence of t1. Suggest we change to:

data.content.keyword: "seismic"
data.time.t0 exists and is not None
data.time.t1 exists and is not None