Better error message on encountering volumes with null traces

[stevejpurves]

I regularly encounter files 'in the wild' with null/missing traces. When I try to load these in segyio i get an error (as expected) and the stack trace looks like this:

~\Anaconda3\lib\site-packages\segyio\open.py in open(filename, mode, iline, xline, strict, ignore_geometry)
    177         return f
    178 
--> 179     return infer_geometry(f, metrics, iline, xline, strict)

~\Anaconda3\lib\site-packages\segyio\open.py in infer_geometry(f, metrics, iline, xline, strict)
     30 
     31         if numpy.unique(f.ilines).size != f.ilines.size:
---> 32             raise ValueError( "Inlines inconsistent - expect all inlines to be unique")
     33 
     34         if numpy.unique(f.xlines).size != f.xlines.size:

ValueError: Inlines inconsistent - expect all inlines to be unique

Is that the expected error for this failure case?

Which is confusing. I believe the cause is missing traces not duplicated inline numbers, and I can take the cube load it into OpenDTect for example (with no errors regarding inline numbering problems) and re-export is with null traces added. That complete volume loads correctly into segyio.

So could a more explicit check be made for the null trace case and a clearer error message be presented to the user?

[jokva]

It can, and I think it's a good idea. Most of these errors that segyio throw are intended for application developers (which should consider what to do and investigate why this happens), and haven't received too much attention. It turns out segyio is used quite a lot almost as an application itself, so we can do a better job, at least for precision-of-errors.

[Khalilsqu]

I am having the same problem with some segy files, some areas within the cube are empty and I keep getting the same error messsage, ValueError: Inlines inconsistent - expect all inlines to be unique. The files can be read by commercial software or even obspy.

[jokva]

So that error message means exactly what it says - segyio has detected that you don't really have a cube suitable for consistent line access because there are two (or more) traces that say they identify the same line/intersection.

Usually that just means that your file is not regularly laid out, but just "a bunch of traces identified by the header". Segyio can usually open it - try passing strict = False to open - that means segyio accepts this to not be a cube, but just a trace collection instead.

That means f.iline, f.xline etc. won't work, but you can at least read your data and figure out the structure.

If there are proper null traces in there, i.e. not all traces have the same number of samples, segyio won't work at all I'm afraid.

[jokva]

@Khalilsqu It looks like your message might've been dropped.

It's usually possible to read files with large amounts of traces (in the volume) missing, but you need to tell segyio that it's ok to not build the volume metadata. If you pass ignore_geometry = True to segyio.open it should open. Obviously, f.iline won't work, but you can still figure out everything you need.

[Khalilsqu]

@jokva Thanks alot, I managed to make it work. appreciate all your efforts.

[jokva]

You're most welcome.

[bconsolvo]

Could you elaborate on how you resolved this issue? I am having difficulties with the same error, and I am able to open up my SEGY in other software packages. @jokva

[jokva]

Usually it means that the heuristic we use say it looks like a cube, but then it turns out the product of in- and crossline did not add up to the number of traces. Are you certain no traces are missing, or that it's not a rectangle proper (from above)?

[auncsm]

@jokva If using ignore geometry or strict= false when reading the data, how can I sort the data into iline xline and write back into a new segy ?

I used: with segyio.open(filename,ignore_geometry=True) as f: ls=[] for trace in f.trace: l=np.copy(trace) ls.append(l) ls = np.array(ls)

I was able to manipulate my ls array for computations but then how do I write everything back into a segy with the same geometry as the original segy? And how can I visualize both volumes? or make sense of lines xlines?

[sebastianvitterso]

Hi! I'm wondering why there's even a check for this.

I'm using segyio.cube(segy_file) and just work on the numpy cube, but we recently came across a file with null-traces. Now, we've had NaN-values in traces without any problem before, so I'm wondering why it's not possible to just cast these null-traces to NaN, and keep going.

Is this an option, or could it be in a future release?