[OpendTect_Users] Users Digest, Vol 77, Issue 4 [2D horizon picking]
Julien Moreau
julien.moreau at helsinki.fi
Sun Feb 5 12:56:40 CET 2012
Dear Bert and OD users,
the problem described by Guillaume is also interesting me.
I wrote about it in the frame of a project with Arnaud and Eric a
couple of months ago.
For this particular problem, if I remember well it was due to the fact
I was picking the same horizon with draw-between-seeds on several
linesets (I had different acquisition campaigns).
After I reprocessed the data I reimported the lines in the same
lineset and so far it did not happen again.
However, there is a general memory consumption difference when using
draw between seeds. It is not managed in the 3D engine the same way as
the other horizons. If you have to have a very large 2D horizon you
will have to split it in part or to use the other picking options
(which are more sound).
So if I can also be in the loop, I would be happy to know more about it.
Best wishes,
Julien
Quoting users-request at opendtect.org:
> Send Users mailing list submissions to
> users at opendtect.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.opendtect.org/mailman/listinfo/users
> or, via email, send a message with subject or body 'help' to
> users-request at opendtect.org
>
> You can reach the person managing the list at
> users-owner at opendtect.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Users digest..."
>
>
> Today's Topics:
>
> 1. Re: Users Digest, Vol 77, Issue 3 (Gery .)
> 2. Madagascar program sfattr (Chris Irvine)
> 3. Re: OpendTect 2D horizon picking problem (Bert Bril)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 4 Feb 2012 15:29:12 +0000
> From: "Gery ." <gamejihou at hotmail.com>
> Subject: Re: [OpendTect_Users] Users Digest, Vol 77, Issue 3
> To: <users at opendtect.org>
> Message-ID: <DUB111-W974830941EA283892E4E29B0760 at phx.gbl>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
> Hello Bert et al,
>
> I'm interested in this topic, please I'd like to follow it, so put
> my email address gamejihou at hotmail.com in your cc. Thanks. Just an
> idea about this, even though I didn't get the pdf file Guillaume
> refers to, the problem could be the navigation, I received before
> some SEG-Y where the navigation wasn't edited (from a very untidy
> guy actually) and OD crashed a couple of times because it couldn't,
> I think, in somehow display the curves the navigation had, and this
> SEGY hadn't any problems in the trace numbering. Given I've dealt
> with several untidy guys during the last years :p, so perhaps I can
> help you a bit if I could take a look at the famous pdf. Oh, btw, OD
> rocks dude, don't forget it ;)
>
> Cheers,
>
> Gery
>
>
>
>> From: users-request at opendtect.org
>> Subject: Users Digest, Vol 77, Issue 3
>> To: users at opendtect.org
>> Date: Sat, 4 Feb 2012 12:00:02 +0100
>>
>> Send Users mailing list submissions to
>> users at opendtect.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> http://lists.opendtect.org/mailman/listinfo/users
>> or, via email, send a message with subject or body 'help' to
>> users-request at opendtect.org
>>
>> You can reach the person managing the list at
>> users-owner at opendtect.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Users digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: OpendTect 2D horizon picking problem (Bert Bril)
>> 2. Re: OpendTect 2D horizon picking problem (Juan Diaz-Naveas)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Fri, 03 Feb 2012 15:35:05 +0100
>> From: Bert Bril <bert at opendtect.org>
>> Subject: Re: [OpendTect_Users] OpendTect 2D horizon picking problem
>> To: users mailing list <users at opendtect.org>
>> Message-ID: <4F2BF099.4060909 at opendtect.org>
>> Content-Type: text/plain; charset=UTF-8; format=flowed
>>
>> Hi,
>>
>>
>> Guillaume wrote:
>>
>> > I'm working on a research project and i am using OpendTect. I
>> > attached this mail a .pdf illustrating my problem with 2D horizon
>> > picking. I just try to pick seeds and draw 2D horizon on my seismic
>> > line but i can't draw a complete horizon, OpendTect doesn't allow me
>> > to continue... I am working on the 4.3 OpendTect version (i first
>> > downloaded the 4.2 version but OpendTect 4.2 needed like 5 min to
>> > pick 1 seed before to crash).
>>
>> Let's first establish the real nature of the problem. I understand that
>> you tried to pick a horizon a couple of times, and that each time you
>> could not go further than a certain point. OpendTect seems to connect
>> the last successful pick with a point on the left side. I presume the
>> straight line is at the depth of your last pick. The point where this
>> happens is always the same. Right?
>>
>> My guess is that the problem is caused by a problem in the line data.
>> More specifically, I think it may be a problem with the trace numbering.
>>
>> If you imported from SEG-Y, then can you take a look again with the 4.3
>> version. In the examine window you can see direct plots of all the
>> header values for the traces in the file. Good numbering causes there to
>> be just one line with 2 points annotated: the start and stop.
>>
>> You can also check in Survey-Manage-2D Geometry. Or just in the 3D
>> viewer, by going over the line with your mouse. Do you see any
>> irregularity in the trace number of coordinate values?
>>
>>
>> Please tell me what you get, before we have to go deeper into the
>> details of the data. The data itself can have a problem, or there may be
>> something in there that triggers a bug. In both cases much more
>> information is required to find a solution.
>>
>> In all cases, I'm not sure how interesting the rest of the conversation
>> would be for the mailing list. Therefore, communication with
>> support at opendtect.org may be a lot better.
>>
>>
>>
>> Bert Bril
>>
>> --
>> -- Bert Bril / OpendTect developer at dGB
>> -- mailto:Bert.Bril at opendtect.org , http://opendtect.org
>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Fri, 3 Feb 2012 20:30:12 -0300 (CLST)
>> From: "Juan Diaz-Naveas" <jdiaz at ucv.cl>
>> Subject: Re: [OpendTect_Users] OpendTect 2D horizon picking problem
>> To: "Bert Bril" <bert at opendtect.org>
>> Cc: users mailing list <users at opendtect.org>
>> Message-ID: <3222.201.214.31.10.1328311812.squirrel at webmail.ucv.cl>
>> Content-Type: text/plain;charset=utf-8
>>
>> Dear Bert,
>>
>> 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 don't know about the rest of OD users, but this is my way of thinking.
>>
>> Very best wishes
>>
>> Juan Diaz-Naveas
>>
>>
>> Bert Bril escribi?:
>> > Hi,
>> >
>> >
>> > Guillaume wrote:
>> >
>> >> I'm working on a research project and i am using OpendTect. I
>> >> attached this mail a .pdf illustrating my problem with 2D horizon
>> >> picking. I just try to pick seeds and draw 2D horizon on my seismic
>> >> line but i can't draw a complete horizon, OpendTect doesn't allow me
>> >> to continue... I am working on the 4.3 OpendTect version (i first
>> >> downloaded the 4.2 version but OpendTect 4.2 needed like 5 min to
>> >> pick 1 seed before to crash).
>> >
>> > Let's first establish the real nature of the problem. I understand that
>> > you tried to pick a horizon a couple of times, and that each time you
>> > could not go further than a certain point. OpendTect seems to connect
>> > the last successful pick with a point on the left side. I presume the
>> > straight line is at the depth of your last pick. The point where this
>> > happens is always the same. Right?
>> >
>> > My guess is that the problem is caused by a problem in the line data.
>> > More specifically, I think it may be a problem with the trace numbering.
>> >
>> > If you imported from SEG-Y, then can you take a look again with the 4.3
>> > version. In the examine window you can see direct plots of all the
>> > header values for the traces in the file. Good numbering causes there to
>> > be just one line with 2 points annotated: the start and stop.
>> >
>> > You can also check in Survey-Manage-2D Geometry. Or just in the 3D
>> > viewer, by going over the line with your mouse. Do you see any
>> > irregularity in the trace number of coordinate values?
>> >
>> >
>> > Please tell me what you get, before we have to go deeper into the
>> > details of the data. The data itself can have a problem, or there may be
>> > something in there that triggers a bug. In both cases much more
>> > information is required to find a solution.
>> >
>> > In all cases, I'm not sure how interesting the rest of the conversation
>> > would be for the mailing list. Therefore, communication with
>> > support at opendtect.org may be a lot better.
>> >
>> >
>> >
>> > Bert Bril
>> >
>> > --
>> > -- Bert Bril / OpendTect developer at dGB
>> > -- mailto:Bert.Bril at opendtect.org , http://opendtect.org
>> >
>> >
>> > _______________________________________________
>> > Users mailing list
>> > Users at opendtect.org
>> > http://lists.opendtect.org/mailman/listinfo/users
>> >
>>
>>
>>
>>
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> Users mailing list
>> Users at opendtect.org
>> http://lists.opendtect.org/mailman/listinfo/users
>>
>>
>> End of Users Digest, Vol 77, Issue 3
>> ************************************
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.opendtect.org/pipermail/users/attachments/20120204/4ea7bb91/attachment.htm
>
> ------------------------------
>
> Message: 2
> Date: Sat, 4 Feb 2012 15:08:01 -0700
> From: "Chris Irvine" <cirvine1 at telus.net>
> Subject: [OpendTect_Users] Madagascar program sfattr
> To: <users at opendtect.org>
> Message-ID: <000001cce389$7922f2e0$6b68d8a0$@telus.net>
> Content-Type: text/plain; charset="us-ascii"
>
> Is it possible to see the results of sfattr in the log file when it is run
> from the Madagascar Interface? It is useful to know if there are spikes etc
> in the input dataset and if they are removed by later processing. Is there
> a Plot Command that is needed to quickly show these dataset statistics?
>
>
>
> Cheers
>
> Chris Irvine
>
>
>
> Consulting Geophysicist
>
> Calgary, Alberta, Canada
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.opendtect.org/pipermail/users/attachments/20120204/6b1b1a7d/attachment.htm
>
> ------------------------------
>
> Message: 3
> Date: Sun, 05 Feb 2012 01:15:22 +0100
> From: Bert Bril <Bert.Bril at opendtect.org>
> Subject: Re: [OpendTect_Users] OpendTect 2D horizon picking problem
> To: users mailing list <users at opendtect.org>
> Message-ID: <4F2DCA1A.4020201 at opendtect.org>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> 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
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Users mailing list
> Users at opendtect.org
> http://lists.opendtect.org/mailman/listinfo/users
>
>
> End of Users Digest, Vol 77, Issue 4
> ************************************
>
--
Dr Julien Moreau
Postdoctoral Researcher
Institute of Seismology
University of Helsinki
+358 (0)9191 51613
More information about the Users
mailing list