[GF] how big

[Keith Woollard]

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