[OpendTect_Users] OpendTect 2D horizon picking problem

[Bert Bril]

Hi all,


Juan wrote:

> In my opinion, the problem that Guillaume has discovered and the issue
> with the trace numbering that you described is extremely interesting for
> me.
>
> This is the kind of problems that one (I at least) would like to read and
> that often, sooner or later, one is confronted with. A couple of years ago
> I faced a similar problem because the headers were incorrectly filled.
> After correcting the headers all problems disappeared.

I can say the following about this problem: Try using the development 
release 4.3. You will find it has a nice display of your header field 
values. In the graph you can easily see whether there are strange 
numbers, duplicates, and so forth. You can then choose a nice continuous 
number as identification (the 'Trace number' is what we call this 
identification number in OpendTect). Usually the CDP number is used, 
sometimes a SP number will be OK. Constraints are:

1) The number must continuously go up - or continuously down
2) The trace numbers can have a step different from 1, and that step 
doesn't even have to be constant. It is supposed to be proportional to 
the distance along the line, however.
3) Very damaging are trace numbers that duplicate, jump the wrong way or 
otherwise violate above rules. Then you'll get trouble.

In all cases, be sure about what header value you use as trace number. 
Examine a large number or all of the traces, to do that click on the 
field in the table. Investigate discontinuities. Every point that is 
drawn is a potential discontinuity. I've sketched a few typical patterns 
below.


What to do if you can't find a good trace number in the headers? Then 
make one! Also in 4.3 is the new 'Manipulate' button. You can create a 
new SEG-Y file from the old one with new, calculated header values. This 
works similar to the Mathematics attribute, just define some kind of 
formula using the other header values. A special case is 'INDEXNR' which 
is the sequence number of the trace in the file. A formula like:

INDEXNR * 2 + 99

will result in values 101 103 105 ...

The result is immediately displayed, so you can check whether the new 
value is as you would expect it.


Note that this new functionality will also be in the coming stable 4.4 
release (expected around the EAGE conference).



Typical patterns (put your e-mail viewer in a fixed-width font):

         o
        .
       .
      .
     .
    .
   .
  .
o

or

o
  .
   .
    o
       o
        .
         .
          .
           o

Good trace numbers for 2D lines. The 2nd one has one missing trace 
number, which is OK when that's exactly what's the case: a gap.

           o
          .
         .
     o  .
    .  o
   .
  .
o

A reversal. Not OK. Typically you are using the SP number in a line 
that's not re-sorted.

oo
  oo
   oo
    oo
     oo
      oo
       oo

Duplicate traces. Only the first one of each trace pair will be loaded, 
because OpendTect must make sure that every trace number is unique.

               o........o
       o.....o
o....o

or

o.....o
        o.....o
               o.....o

These patterns are typical for the inline number of a 3D survey.


      o     o     o
     .     .     .
    .     .     .
   .     .     .
  .     .     .
o     o     o

... and this one the crossline number of a 3D survey. Also, for 
pre-stack data this happens for offsets for each gather.


      o...o              o
o...o     o.o      o...o o..
              o....o

Typical for some kind of gain value. Not useful as trace number.




Bert

--
-- Bert Bril / OpendTect developer at dGB
-- mailto:Bert.Bril at opendtect.org , http://opendtect.org