|
|||||||
|
|||||||
|
|
|
|
|
|
|
|
 |
 |
 |
 |
|
Applications >> Seismic Model
What are the EpiSeismic::PostStack3d volume accessors? What is the difference between the accessors? The EpiSeismic::PostStack3d volume accessors are very important because they provide the functionality to read and update the seismic trace data, sometimes referred to as bulk data. There are two categories of volume accessors. Use the BinGrid accessors (BinGridPointSet, BinGridLineSet, BinGridPlanar, BinGridSubVolume) if you want to manipulate the seismic data using seismic bin/grid annotations (i.e. Inline/Crossline values). Use the IJK accessors (PointSet, LineSet, Planar, SubVolume) if you want to manipulate the seismic data using the volume's IJK coordinates.
How do I decide which EpiSeismicPostStack3d volume accessor to use? Be careful when choosing which accessor to use. Using the BinGridPointSet or PointSet accessors can be very slow if retrieving large amounts of data because of the data transfer between the server and the client. It is best to use an accessor that best fits the need of the client application to maximize the data transfer. For example, if you are writing a seismic section viewer and you will present the data with the seismic bin/grid annotations, use the BinGridPlanar accessor when retrieving the Inline or Crossline planes. Use the BinGridSubVolume or SubVolume accessors for retrieving seismic data as cubes. Use the BinGridLineSet or LineSet accessors when retrieving random lines or diagonal traverses. There are several OpenSpirit seismic examples that show the different usages of these accessors.
What is the fastest way possible to access seismic data? Retrieving the seismic data in its native data type and storage order will result in the fastest access possible. Refer to the getStorageOrder and getSampleDataType methods on the PostStack3d interface for more details. For example, if the seismic data is BYTE and stored with Inline orientation, then retrieving it in this manner will be much faster than retrieving it as FLOAT or by Crossline orientation. Marshalling FLOAT data from the server to the client is slower by a factor of four than marshalling BYTE data. It is best to retrieve the seismic data in its native data type and do the conversions in the client application when retrieving large amounts of data, unless the data is stored in a higher precision (FLOAT) and you are requesting a lower precision (BYTE), in which case less data is transferred.
Retrieving individual samples, lines, or planes is not a problem; however, trying to retrieve a large subvolume (e.g. greater than one gigabyte) will substantially slow down the performance. The volume's data type (i.e. byte, short, long, float) has a big impact. A 10x10x10 byte subvolume is 1000 bytes, a 10x10x10 float subvolume is 4000 bytes. The server allocates the memory, retrieves the data, and marshalls the data to the client application . The CORBA ORB also allocates memory (sometimes twice the size of the data buffer) to marshal the data. For small subvolumes this isn't a problem, but for large subvolumes you can run out of memory and the application will fail, especially if the client and server processes are running on the same machine. When this condition is possible it is best for the client application to request the data in smaller "chunks" (e.g. as individual planes) and cache the data on the client side. This will keep the memory requests at a more manageable level and ensure that the application works, regardless of how large the subvolume request is. The MAX_DATA_SIZE parameter can also be adjusted for the data servers using the OpenSpirit Configuration Tool. This parameter sets the high-water mark for the number of bytes that can be allocated by the data server.
Does the seismic server cache my bulk trace data update? The seismic bulk trace data is not cached in the seismic server, updates are immediately written to the data store.
|
|
|
|||||||||||||||||||||||||
