220 likes | 450 Views
SEG-D Revision 3.0 Proposal. SEG Technical Standards Committee. 1967. SEG-A & SEG-B. 1972. SEG-C. 1979. SEG-D Rev 0. 1994. Rev 1. Rev 2. 1996. SEG-D, Rev 2.1 SEG Field Tape Standards. 2006. SEG Field Tape Standards History. Why now?.
E N D
SEG-D Revision 3.0 Proposal SEG Technical Standards Committee
1967 SEG-A & SEG-B 1972 SEG-C 1979 SEG-D Rev 0 1994 Rev 1 Rev 2 1996 SEG-D,Rev 2.1 SEG Field Tape Standards 2006 SEG Field Tape Standards History
Why now? The 2006 2.1 revision was specifically designed as a targeted upgrade to support very high capacity tapes. 3.0 was promised in the 2.1 standard to follow soon afterwards and deal with major overhaul and/or upgrades.
Why us? Jill Lewis (Troika International) — Earns living transferring & transcribing data Stewart A. Levin (Halliburton Energy Services) — ProMAX™ SEG-D Input support & upgrades Rune Hagelund (WesternGeco) — Umpteen years acquisition software experience Barry D. Barrs (ExxonMobil) — Navigation and positioning expertise
SEG-D issues driving 3.0 • An explosion in data being stored in vendor-specific headers driven by the need for smooth transfer between acqusition & QC/processing • Multicomponent surveys • Higher sampling rates/non-power-of-2 ratios • Beyond 24-bit sensor sensitivity • Continuous passive monitoring • Only non-record format is long byte stream— cumbersome for QC and transcription
SEG-D opportunities driving 3.0 • Nonseismic data? • Positioning standards coordination • Using web documents for dynamic information • Manufacturer list • Media types and parameters • API organization codes • Guidance recommendations and clarifications • Errata and translations • Format validation utilities
Overview of revision 3.0 proposal • All features discussed at SEG New Orleans have been implemented • With a few additions • SEGD Tape Label, General Header 1 and Demux Trace Header left as is (with a few exceptions) • Be an efficient format for transferring information between acquisition and QC/processing • SEGD is not a processing format • More space for user-defined header blocks
Overview of revision 3.0 proposal • Increased flexibility • Header blocks tagged to allow shot specific (attached to general header) or trace specific information • Flexible sample rates, header sizes, reclength etc. • Increased robustness • Tagged header blocks • Size of shot/data in General Header • Simplified encoding/decoding • No complex datatypes, using 4byte float, int etc • Explicit values (ex. #samples/trace) • No dependencies between header blocks • Additional functionality
New features in revision 3.0 proposal • Logical numbering of traces/source points extended to handle all operation types • Line number • Point number • Point index • Group index • Depth index • Reshoot index
New features in revision 3.0 proposal • Support for complex shooting schemes • Multiple source initiations per shot record • Multiple sources firing simultaneously • Support for complex source configurations • Traces and measurements for sources and parts of sources • Align SEG-D with SPS standard and/or SEG-Y revision 1 positioning support
New features in revision 3.0 proposal • Standardizing storage of common survey information • Vessel/crew identification • Survey area name • Client identification • Job identification • Line identification (Record set ID) • Size of record, data, and header explicit in General Header
New features in revision 3.0 proposal • Positions can be tagged to all traces/equipment • Multiple positions (in space and time) • Format TBD by pos group • Support for multi-component data • Node number, trace grouping, orientation header • New General Trailer format • Flexible, allows any data-block to be appended • Standardized edits can be appended to General Trailer • Allows easy addition of edits post-acquisition • 8068: IEEE 8 byte samples
Sample rate / timestamp • Sample rate steps of 1 microsecs • No longer a base scan rate • Dominant sample interval used for backwards compatibility • Timestamp – counting microsecs since 6 Jan 1980 (GPS epoch) • 8 byte integer • Negative timestamps allowed • 292471 years range
New features in revision 3.0 proposal • All measurements now properly tagged with accurate, absolute timestamp (if available) • Positions, traces, shot, etc. • All header sizes extended • More room for acquisition system defined blocks • Existing trace ext hdr blocks may be used.... • ...but remember to use correct block tag • Standardizing storage of SEGD • One header block spanning multiple tape blocks • A trace spanning multiple tape blocks • Fixed/variable block devices • Disk storage • Transfer across network
New features in revision 3.0 proposal • More sensor types/channel types explicitly supported • Wind, depth, reference signals, source measurements etc. • Sensor sensitivity value stored per channel • Convert to actual physical unit • Support non-voltage measurements
New features in revision 3.0 proposal • Table Of Contents file • Stored at end (or beginning) of tape • Lists all SEGD records on a tape • Enable fast access to data • May be stored on disk (to simplify data mgt)
New features in revision 3.0 proposal • Line number -> Record set number • To be usable for all types of operation • Only 3 General Header blocks required in rev 3.0 • Everything else optional
Header size extensions • Channel set header block 96 bytes • Header block sizes • General header - 65536 blocks (2 MB) • Channelset header – 65535 blocks (~6MB) • Skew blocks – 65535 blocks (~2MB) • Extended header – 16777215 blocks (~512MB) • External header - 16777215 blocks (~512MB) • Trace Header Extension – 255 blocks (8160 bytes) • General Trailer – 4294967295 blocks (~128GB)
Trace size • Traces can be 2147 seconds long • Negative start times allowed • Extended recording mode allows up to 140,735,340 seconds (1628 days) of data to be stored in one record
Filters • Extended filter definitions • Frequencies and slopes are IEEE floats (4 bytes) • Filter type • Filter delay
Questions, Concerns and Suggestions? • Volunteers always wanted • We’re taking names • Multicomponent standards • Downhole acquisition support • Metadata additions (temperature, wave height, …) • Opinions too • We’re taking notes