453 Posts in 222 Topics by 67 members

Python in GLOBE Claritas

Forum » Python in GLOBE Claritas » Getting file trace ID from RUNPYTHON

If this is your first visit, you will need to register before you can post. However, you can browse all messages below.

Moderators: Andy Juniper , Guy Maslen , Keleigh Jones

Page: 1 Go to End
Author Topic: Getting file trace ID from RUNPYTHON 2259 Views

Getting file trace ID from RUNPYTHON Link to this post

Hi All,

Is there an easy way to get the absolute, integer trace numbers for the traces passed to runpython, corresponding to those in the original SEG-Y (or other) input file? I.e., a list of the trace IDs from the start of the file, regardless of header values. In principle, LINE or REEL should hold these values, but in practice can differ. I'm trying to import traces into pseudotraces using a runpython flow that exactly correspond with the traces in the original dataset, but without doing header lookups on the second dataset.

class ExtSEGY (object):
def __init__ (self):
self.sf = None

def __call__ (self, seismic):
if (self.sf is None):
filename = seismic.userArg
self.sf = SEGYFile(filename, **sfargs)

ftr = seismic.trHeadersRec['REEL']
bounds = (ftr[0]-1,ftr[-1])
seismic.trHeadersRec['EXTRA'][:,:] = self.sf[bounds[0]:bounds[1]][:]

readalike = ExtSEGY()

The SEGYFile class provides an interface to read SEGY data into Python efficiently, but you could just as easily think of it as a numpy array with dimensions (ntr,ns). The "readalike" function is called by RUNPYTHON. The "EXTRA" pseudotrace is created as a copy of the original data using PSEUDOMATH before the RUNPYTHON entry. This sort of works, except that the REEL header in some of my datasets seems not to increase monotonically in all cases, so I'd like something a bit more reliable.

Thanks!

Brendan Smithyman

Re: Getting file trace ID from RUNPYTHON Link to this post

Hi Brendan,

It's my understanding that LINE is renumbered sequentially when reading, but I'll have another look at READSEGY and DISCREAD to make sure. It sounds like it isn't. I wonder if dead traces are an issue here?

As an alternative, you could use the RENUMBER module to renumber LINE or REEL (as the secondary key, omit the primary key) so you're getting the values you expect. I think this is probably the easiest solution.

Other options would be to maintain a variable for the 'last trace index seen' and use a NumPy function like "np.arange(traceIndex, ntracesInGather)" to create an array that you can use for LINE or REEL.

Currently the 'seismic' object passed to Python from Claritas is a new object for each call to Python. You can't use this to save state between calls. The other option is to use a global variable or a file on disk. I'd like to change this in the future but it's a limitation for now.

Hope this helps,
Chris

Re: Getting file trace ID from RUNPYTHON Link to this post

Thanks Chris,

Having read through your ideas, I went back to the code and tried it again using the LINE header. Everything seems to be working now, so it's possible it was unrelated to the Claritas side of things.

Storing an internal counter on the Python side is a good idea, but it won't work for interactive plotting when choosing SHOTIDs (or other headers) with READSEGY or DISCREAD. But actually, maintaining objects between calls is why I'm using a class in the fragment I posted (SEGYFile memory-maps the file and reads text and reel headers, so I didn't want to have to recreate it every time).

Regardless, it seems to be working nicely now. A quick way to compare real and synthetic waveforms for QC purposes, getting around the limitations on multiple READSEGY or DISCREAD processors in one flow.

I appreciate the help!

    2259 Views
Go to Top