Sometimes you need to know how much space you need for a seismic volume. One of my machines only has 4GB of RAM, so if I don't want to run out of memory, I need to know how big a volume will be. Or your IT department might want help figuring out how much disk to buy next year.

Fortunately, since all seismic data is digital these days, it's easy to figure out how much space we will need. We simply count the samples in the volume, then account for the bit-depth. So, for example, if a 3D volume has 400 inlines and 300 traces per line, then it has 120 000 traces in total. If each trace is 6 seconds long, and the sample interval is 2 ms, then each trace has 6000/2 = 3000 samples (3001 actually, but let's not worry too much about that), so that's about 360 million samples. for a 32-bit volume, each sample requires 32/8 = 4 bytes, so we're at... a big number.  To convert to kilobytes, divide by 2¹⁰, or 1024, then do it again for MB and again for GB.

It's worth noting that some seismic interpretation tools have proprietary compressed formats available for seismic data, Landmark's 'brick' format for example. This optionally applies a JPEG-like compression to reduce the file size, as well as making some sections display faster because of the way the compressed file is organized. The amount of compression depends on the frequency content of the data, and the compression is lossy, however, meaning that some of the original data is irretrievably lost in the process. If you do use such a file for visualization and interpretation, you may want to use a full bit-depth, full-fidelity file for attribute analysis. 

Do you have any tricks for managing large datasets? We'd love to hear them!