From dlembang at georex.com Thu Apr 9 02:44:23 2009 From: dlembang at georex.com (dlembang at georex.com) Date: Thu, 09 Apr 2009 09:44:23 +0200 Subject: [GF] To post to this list gf@stevens.com Message-ID: <20090409094423.396oesozs4gc0ccc@webmail.georex.com> ---------------------------------------------------------------- This message was sent using Kallios Webmail and IMP Internet Messaging Program. From woollard at geocom.com.au Wed Apr 22 20:32:46 2009 From: woollard at geocom.com.au (Keith Woollard) Date: Thu, 23 Apr 2009 09:32:46 +0800 Subject: [GF] how big Message-ID: <49EFC53E.7090004@geocom.com.au> Good morning all, Don't know how many people are on this forum, but thought I might test it out. Trying to load a 3d to GF(IESX) 4.4. 290gb input segy loading as 16 bit. It crashes after making 62 output files with an error about the .bat - I am guessing this is a hard limit, does anyone know a workaround other than the obvious 2 - load as 8 bit or break into two halves. Thanks in advance -- Keith Woollard Senior Consultant GeoCom Services Australia Pty Ltd (A.B.N. 63 068 362 498) Ph 61 (08)9243 3544 fx 61 (0)8 9246 9410 Email woollard at geocom.com.au Web www.geocom.com.au From dave at stevens.com Wed Apr 22 21:27:39 2009 From: dave at stevens.com (J. D. Stevens) Date: Wed, 22 Apr 2009 21:27:39 -0500 Subject: [GF] how big In-Reply-To: <49EFC53E.7090004@geocom.com.au> References: <49EFC53E.7090004@geocom.com.au> Message-ID: <49EFD21B.8040000@stevens.com> Keith, Thanks for starting off with an excellent question for the list. There are currently 25 subscribers to gf at stevens.com. The SMT list, 3dpak at stevens.com, currently has 988 subscribers. 3dpak at stevens.com started in 1999 with about 17 subscribers. I just checked some systems to which I have access and found the highest vvol count to be 62, which corresponds to the limit you experienced. I can check with the person who loaded the data to see if she experienced a hard limit at that point. She is a subscriber and may be willing to address the issue based on her experience. My experience has been that 8 bit data works nicely with the GeoFrame scaling algorithms. As I understand it, each trace is limited to 8 bits of dynamic range, but the range of the survey is much wider because of the scaling coefficient carried for each trace. My initial loading experience, more than 20 years ago, was with Landmark interpretation systems. At that time, loading at 8 bits meant that the dynamic range of the whole survey was only 8 bits. That is a problem. It required the data to be loaded at a minimum of 16 bits/sample in order to get decent amplitude resolution. It took a while for me to understand that a GeoQuest 8 bit volume had much wider dynamic range because they handled scaling per trace rather than per survey. I concluded that 8 bits was appropriate for almost all interpretation purposes on a GeoQuest system. Dave Keith Woollard wrote: > Good morning all, > > Don't know how many people are on this forum, but thought I might test > it out. > > Trying to load a 3d to GF(IESX) 4.4. > > 290gb input segy loading as 16 bit. It crashes after making 62 output > files with an error about the .bat - I am guessing this is a hard limit, > does anyone know a workaround other than the obvious 2 - load as 8 bit > or break into two halves. > > Thanks in advance > -- Dave Stevens Dave at Stevens.COM STEVENS.COM, Inc. 713-419-0313 Bellville, TX, USA http://www.stevens.com From woollard at geocom.com.au Wed Apr 22 22:39:27 2009 From: woollard at geocom.com.au (Keith Woollard) Date: Thu, 23 Apr 2009 11:39:27 +0800 Subject: [GF] how big In-Reply-To: <49EFD21B.8040000@stevens.com> References: <49EFC53E.7090004@geocom.com.au> <49EFD21B.8040000@stevens.com> Message-ID: <49EFE2EF.601@geocom.com.au> Further investigation, and some feedback from Schlumberger indicate that the 62 number is a hard limit, but the 2gb per file can be increased via the storage settings, but only in GF44. I am re-running the load now with 4gb vvol's. Personally I would always stick under 8gb so that you never run into the Solaris Vs Linux 8gb tar difference. And on to 8 bit amplitudes. IESX works exactly the same way as Kingdom (although it should probably be said the other way around). The old way Landmark used to do it was the same as Charisma and Paradigm. Landmark for the last 10 years the best amplitude storage for 3d, but rubbish for 2d. GeoQuest have been very effective in convincing their users that their 8 bit format is sufficient. Almost every user I have spoken to thinks that 8 bit in IESX is ideal. Their help says "IESX uses a unique algorithm to preserve the dynamic range of the input data regardless of the storage format" - This is rubbish. The GeoQuest/Kingdom algorithm is very bad at dealing with data with amplitudes that decay with time, or with data that has spikes. In fact any true-ish amplitude data is only really stored with 6 or 7 bits of resolution as it tries to honour the one sample per trace that is typically 2 or three times as large as the second largest. Unless you have well modulated data, I would always suggest loading as 16 bit. I'll get off my soap box now Keith J. D. Stevens wrote: > Keith, > > Thanks for starting off with an excellent question for the list. There > are currently 25 subscribers to gf at stevens.com. The SMT list, > 3dpak at stevens.com, currently has 988 subscribers. 3dpak at stevens.com > started in 1999 with about 17 subscribers. > > I just checked some systems to which I have access and found the > highest vvol count to be 62, which corresponds to the limit you > experienced. I can check with the person who loaded the data to see if > she experienced a hard limit at that point. She is a subscriber and > may be willing to address the issue based on her experience. > > My experience has been that 8 bit data works nicely with the GeoFrame > scaling algorithms. As I understand it, each trace is limited to 8 > bits of dynamic range, but the range of the survey is much wider > because of the scaling coefficient carried for each trace. > > My initial loading experience, more than 20 years ago, was with > Landmark interpretation systems. At that time, loading at 8 bits meant > that the dynamic range of the whole survey was only 8 bits. That is a > problem. It required the data to be loaded at a minimum of 16 > bits/sample in order to get decent amplitude resolution. It took a > while for me to understand that a GeoQuest 8 bit volume had much wider > dynamic range because they handled scaling per trace rather than per > survey. I concluded that 8 bits was appropriate for almost all > interpretation purposes on a GeoQuest system. > > Dave > > Keith Woollard wrote: > >> Good morning all, >> >> Don't know how many people are on this forum, but thought I might >> test it out. >> >> Trying to load a 3d to GF(IESX) 4.4. >> 290gb input segy loading as 16 bit. It crashes after making 62 output >> files with an error about the .bat - I am guessing this is a hard >> limit, does anyone know a workaround other than the obvious 2 - load >> as 8 bit or break into two halves. >> >> Thanks in advance >> > -- Keith Woollard Senior Consultant GeoCom Services Australia Pty Ltd (A.B.N. 63 068 362 498) Ph 61 (08)9243 3544 fx 61 (0)8 9246 9410 Email woollard at geocom.com.au Web www.geocom.com.au