bridge FAQ

The Basics

1.1 How do I run bridge?

1.2 Why is the command line syntax so NON-USP?

1.3 How do I get man page information?

Scanning SEGY Headers

2.0 How can I scan my SEGY trace header entries?

2.1 How can I scan my SEGY EBCDIC/ASCII header entries?

2.2 Where can I get a SEG-Y Format description?

2.3 Can bridge deal with SEG-Y Classic Rev 1. formats?

SEGY EBCDIC/ASCII Header Editting

3.0 How can I update my SEGY EBCDIC/ASCII header entries?

SEGY and Magnetic Tape Devices

4.0 How do I handle SEGY tape input?

4.1 How do I handle SEGY tape output?

4.2 How do I read a multi-tape SEGY dataset?

4.3 How do I create a multi-tape SEGY dataset?

4.4 How do I read multiple SEGY datasets from a single tape?

4.5 Can I read multi-tape datasets from more that 1 tape drive?

4.6 Can bridge_r2 handle 3480 cartridges?

SEGY and 3rd Party Software

5.0 What do I have to do to create a dataset readable by Landmark?

5.1 What do I have to do to create a dataset readable by ProMax?

5.2 What do I have to do to create a dataset readable by GeoQuest?

Header Mapping

6.0 How do I do trace header mapping between SEGY and USP?

6.1 How do I do line header mapping between SEGY and USP?

6.2 How do I access bytes 181 - 240 in the SEGY trace header?

6.3 How do I put data into bytes 181 - 240 in the SEGY trace header?

6.4 How can I map into TVPTnn and TVPVnn entries in the USP trace header?

Header Arithmetic

7.0 Can I do header arithmetic?

7.1 Can I do header arithmetic on USP data?

Trace Padding

8.0 How do I do USP trace padding when reading SEGY data?

8.1 Can I get USP trace padding based on TrcNum and have RecNum be assigned sequential?

8.2 Can I write a SEGY dataset without dead traces?

Handling SEGY Format Variations

9.0 How can I handle non-standard SEGY trace header formats?

9.1 How can I handle auxillary traces, for instance dropping them on the way in from SEGY to USP?

9.2 My SEGY reel header lies about the number of samples per trace. How can I reassign that value so that I can read the data from tape at all?

9.3 How can I create SEGY data in IEEE floating point format instead of the standard IBM Floating point?

1.1 HOW DO I RUN BRIDGE?

   bridge in_data=[]  in_format=[]  out=[]  out_data=[]  out_format=[]  par=[] 

where:

in_data= : is the input dataset [use stdin: for piped input]
in_format= : is the format of the input data
out= : is the name of the dds output dataset [or dictionary if outputting non-dds data]
out_data= : is the output dataset [use stdout: for piped output]
out_format= : is the format of the output data
par= : is any associated parameter file that you may have set up

bridge is a DDS routine and offers extensive functionality [albeit with considerable complexity]. The very fact that header mapping can be supplied on the command line means that the [-N] UNIX-like command line syntax is out for that would make mapping headers such as disco's SHOT-X impossible. Also since header arithmetic is a reality in bridge you would loose the subtraction operator.

The bridge man page is available using

uman bridge

You can also find this information at the DDS website entry for bridge.

by adding the following to a bridge command line
dds_debug= read diff

you will get dump of the line and first complete input trace header printed into the bridge printout file. For all subsequent traces only header entries that change will be dumped. This is a quick way to see how your SEG-Y dataset is indexed.

You can also use the DDS routine ddscan to examine your SEG-Y header structure. bridge makes it easier to see the spare area as the diff report dumps the spare area cast in each of the available unions [I2, I4, F4IBM, F4].

by attaching a file to out= , for instance
bridge in_data=/dev/rst0 in_format=segy out= dictionary out_data= /dev/null

start the job and let it run for a couple of minutes then kill it. The file named dictionary [name is arbitrary call it whatever you want] will contain [among other things] the printout of the 40, 80 column cards from the 3200 byte EBCDIC or ASCII header and basic information from the 400 byte reel header.

You could also utilize ddscan to view the header

You can issue the USP command:
hdrdesc | xcat -menu &

which will print out a complete listing of USP and SEGY header formats.

Here is a the original SEG-Y format.

Here is the Revision 1 format.

Yes, for the standard old classic SEG-Y, complete with the spare area beyond byte 180 use:

in_format= segy

for the new SEG-Y revision 1 format use:

in_format= segy1

The SEG-Y CLASSIC and REV 1 formats are both here.

You can define the entries in the segy_card3200 array either on the command line or in your attached parameters file.

There are 40 cards, 80 columns each (delimited by double quotes). They use the following dictionary definition:

  segy_card3200=
  "C 1 STUFF ON THE FIRST CARD"
  "C 2 SECOND CARD"
  ...
  "C40 THE LAST CARD"

The first 3 columns are usually "Cxx", where xx is the card number.

If you want an "=" in one of the cards, it must be "\" escaped, i.e.

   segy_card3200=
   "C 1   LOW CUT\= 20 Hz"
   "C 2 ..."

If you put this stuff on the command line, you must protect the double quotes from the shell using single quotes.
bridge segy_card= '"C 1 LOW CUT\= 20 Hz"'

It probably easier to place this stuff in a parameter files and use...
bridge in_data=my.segy in_format=segy par= parameter_file_name out_data=my_new.segy out_format=segy

To handle tape input use the following on your command line or in your parameter file
in_data=/dev/rst0 in_format=segy

In this example I am using rst0. In real life this could be any legal device driver you have at your disposal [i.e. nrst0, rst8 etc.]. Bridge expects to read first a 3200 byte ebcdic header containing 40 eighty column cards of user defined info, followed by a 400 byte binary header, followed by traces, each containing a 240 byte trace header followed by a time series.

put the following on your command line or in your parameter file
out=tmp: out_data=/dev/rst0 out_format=segy

The out= variable strips off the dds dictionary and the out_data= variable assigns output to a device. bridge will write legal SEGY format data to tape starting with a 3200 byte ebcdic header, followed by a 400 byte binary header and finally data traces in F4ibm format.

If you pipe out of bridge and use another device driver such as xcram or dd to output to tape your blocking will be screwed up and chances are you will not be able to read the tape with any other routine or workstation software that is expecting legal SEG-Y format.

Put the following on your command line
in_data= /dev/rst8 /dev/rst8= merge label '"RE0001 RE0002"'

If a parameter file is used instead of the command line, then eliminate the single quotes around the list of labels. You will know if you get it right for bridge will ask you to mount, in this case, RE0001 and pre-fetch RE0002. If you don't get the pre-fetch message then you have done it wrong. If you have done it wrong you will get the Mount prompt but NOT the pre-fetch message.

when you execute bridge it will ask that you load RE0001 to rst8. It will then read the tape until it encounters a double EOF (EOT) mark. It will then eject the tape and put up a request that you load tape RE0002. All you need to do is insert the RE0002 tape and close the drive door. bridge will sense the drive back online and continue execution. Of course in this example rst8 and the tape names are purely imaginary. In your real life example these will be what ever you are using. Note that the tape names are used only to prompt the user for tape mount and DO NOT need to be correct. You could use '"1 2"' instead and the program would work the same.

simply put on the command line or in your parameter file
out_data=/dev/rst0 out_format=segy

when the first tape is filled the user will be prompted to mount another scratch tape. This will continue until all data is written. Each tape will have an ebcdic and binary header and may be read individually later.

Place on the command line or in your parameter file the following
in_data= /dev/rst0 in_format=segy /dev/rst0= merge

This will read as many lines as there on the tape until a double EOF is encountered. A single EOF is expected between each line and each line is expected to have both an ebcdic and binary reel header. All lines must have the same number of samples/trace.

If you have a tape stacker at your disposal you can run
xcram10 -segy | bridge .......

and be able to read up to 10 tapes at a time. If not then the answer is NO.

Yes. The routine simply talks to the device driver /dev/rst0 or whatever. It doesn't matter what tape device is actually hanging off the end as long as it is activated by the standard UNIX drivers.

Nothing, the default header mapping in bridge should provide a SEGY datset readable by Landmark.

Nothing, just realize the header mapping that you have and make sure that the ProMax SEGY reader is looking in the right place for any special indexing you have.

Nothing, the default header mapping in bridge should provide a SEGY datset readable by GeoQuest.

The easiest way is to put all your mapping definitions into a parameter file that can be attached at run time by the par= command line argument.

bridge par= parameter.file

SEG-Y to USP mapping is accomplished using the DDS mapping syntax:

map:segy:usp.mnemonic= segy_mnemonic

where the appropriate USP or SEG-Y mnemonic is substituted as needed. A complete list of mnemonics is available using the USP hdrdesc command.

Say we have a value in the SEG-Y entry FieldRecNum that I would like mapped into the USP trace header entry RecNum, then use:

map:segy:usp.RecNum= FieldRecNum

USP to SEG-Y mapping is done in an analogous fashion:

map:usp:segy.FieldRecNum= RecNum

The usual things you want to assign are NumTrc and NumRec. Especially the latter for there is no entry in the SEGY world for the number of records in a dataset. To fill out the USP line header entries for the above you must provide bridge with some SEGY information that is either not there or needs to be corrected. To do this place the following either in your parameter file or on the command line:

   segy_NumRec= 1234
   segy_NumTrc= 24

Of course the entries 1234 and 24 are imaginary for this example. In real life they will be whatever you require for your dataset.

They are accessable using the Spare.NN[] array structures in bridge, where NN can be any of I2, I4, F4, F4ibm.

If you know which bytes you are interested in accessing life is easy. If you do not then use 2.0 above to examine the trace header spare area and determine what you need to do. In this example let's say that we have data stored in bytes 181-2 and 185-8 that we wish to assign to the USP trace header entries RecNum and DpPtLt.

In the first instance we wish to read a two byte integer so the mapping expression would look like:

map:segy:usp.RecNum= Spare.I2[0]

which is the first entry in the Spare.I2[] union. These unions use C indexing. That is the first entry is zero as opposed to 1. I know that this is not straight forward for a user, but it is for a programmer, and in this case, since the DDS guys are writing and maintaining bridge, I am not going to complain. So there will be 30 possible entries for the Spare.I2[0-29] untion, 15 for the Spare.I4[0-14] union, 15 for the Spare.F4[0-14] union and 15 for Spare.F4ibm[0-14]

In the second instance we wish to read a four byte entry so the mapping would now be:

map:segy:usp.DpPtLt= Spare.I4[1]

which is the second entry in the spare area as decoded using 4 byte logic.

This is quite straight forward, you just use the structures defined in 6.2. For instance, say I wanted to drop indexing from the USP trace header entry RecNum into the spare area bytes 181-184, then

map:usp:segy.Spare.I4[0]= RecNum

would do the trick. You may utilize any of Spare.I2[], Spare.I4[], Spare.F4[] and Spare.F4ibm[] on the left side of the mapping expression. Be careful if you are using the map expression on the command line rather than in the parameter file as the [ is a special character in UNIX and will need to be put in quotes. Here is an example:

bridge in_data= datain in_format=usp out=tmp: out_data=segyout out_format=segy 'map:usp:segy.SpareI2[0]=RecNum'

As of revision level 3 of bridge this is no longer a problem. Simply treat the TVPTnn and TVPVnn entries as you would any other USP trace header mnemonic. For instance:

map:segy:usp.TVPT10= FieldRecNum

Yes, you can use algebraic expressions in your header mapping for instance:
map:segy:usp.RecNum= FieldRecNum * FieldTrcNum - 100

Sure, you can use bridge to do anything you want to the header structure of the dataset. The following example reads and writes USP format data and reassigns the line header sample interval and maps the LinInd entry minus the starting value [100 in this example] into the RecNum header slot. The output is pointed to stdout: so that it can be piped on down the flow
bridge in_data= uspin in_format= usp usp_SmpInt= 2 'map:usp:usp.RecNum= LinInd - 100' out_data=stdout: out_format=usp |\

With revision level 2 this was the default. That is not the case with revision level 3. You now must jump through a few hoops to get this done. Here is the scoop from Jerry Ehlers himself:

If you want to pad on the "x" axis, specify that the "x" axis is dense by adding the dense.x or dense.2 attribute on the format:

out_format=segy dense.x

Pick a trace header that should go from 1 to size.x by 1 and if it other than TrcNum, set it to be the x-axis sort header by:

sort.x= TrcNum (which is the default)

This is not necessary for TrcNum since that's the default. Example, if you want to pad in traces/records for both TrcNum and RecNum then simply specify

out_format=usp dense.2 dense.3

and dead traces and records will be padded based on filling in missing TrcNum and RecNum values.

So for USP guys/gals, you would need to map something into RecNum and TrcNum that was sequential. With the statements that Jerry indicates above, anytime the sequence was broken a dead trace or record would be padded in. Of course padded traces do not have trace indexing so you may still have some work to do after this step, but at least you can do the padding on the fly on the way in.

Yes. The following should accomplish that:

   sort.x= TrcNum
   out_format= dense.2
   write:out.RecNum= 1 + ordinal(3)
   edit:out=force.3

So here the padding is turned on for the x-axis and sequential numbering is turned on for the y-axis. The t-axis is left unreferenced and the input data is assumed to have an axis definition of axis= t x y which is the default.

This one is problematic at the moment with revision level 3. One is supposed to be able to add:

edit:in= drop_dead

and have dead traces dropped on input. In practice this doesn't seem to be working. Here is a kludge that will work:

bridge in_data= uspdataset in_format=usp edit:out= drop_dead out_data_data= stdout: |\
bridge in_data=stdin: in_format=usp out=tmp: out_data= segydataset out_format= segy par= mappingfile

Here the first bridge drops dead traces and the second writes SEG-Y data. Of course you could short circuit the first bridge by utilizing:

pad -N uspdataset -R |\
bridge in_data=stdin: in_format=usp out=tmp: out_data= segydataset out_format= segy par= mappingfile

Here is an example where the contractor supplied so called SEG-Y data with the source and group (x,y) coordinates in the correct SEG-Y trace header locations except in IBM floating point rather than integer format as specified in the SEGY format description. You may still read this information using bridge with the following solution.

1) find the file that describes the SEGY format to bridge. It is currently located at /home/trcgp/dds/src/lib/dds3/segy.fmt.dds

2) copy segy.fmt.dds into your current working directory the new filename must remain segy.fmt.dds

3) change the lines that describe the format of SrcX, SrcY, GrpX, GrpY from...


fmt:*:segy.SrcX= segy_int "73:76, Source coordinate X"
fmt:*:segy.SrcY= segy_int "77:80, Source coordinate Y"
fmt:*:segy.GrpX= segy_int "81:84, Group coordinate X"
fmt:*:segy.GrpY= segy_int "85:88, Group coordinate Y"

to...

fmt:*:segy.SrcX= float4ibm "73:76, Source coordinate X"
fmt:*:segy.SrcY= float4ibm "77:80, Source coordinate Y"
fmt:*:segy.GrpX= float4ibm "81:84, Group coordinate X"
fmt:*:segy.GrpY= float4ibm "85:88, Group coordinate Y"

NOTE: If you want to change the name of the variable you need to make the change in two places in the segy format definition file. Firstly on the line defining the format and secondly in the section at the head of the trace header format section where the structure is listed.

4) Set the DDS_PATH3 environmental variable to point at this directory:

setenv DDS_PATH3 .

5) Execute bridge. The customized SEG-Y format will now override the one used to compile bridge.

If I know I have some "dead" traces (data type = 2) that I wish to drop, I can use:

in_format=segy edit:in= drop_dead

To drop any SEGY trace not having a trace ID of 1 use:

in_format=segy edit:in= drop_dead edit:in= drop_aux

To keep all dead and auxillary traces and drop all seismic traces:

in_format= segy edit:in= drop_live

To keep only the auxillary traces:

in_format=segy edit:in= drop_live edit:in=drop_dead

Since bridge defines the blocksize to use while reading as a function of the number of samples in a trace this is a serious issue. If the binary reel header is not true you will have to add the following to either your mapping file or command line to recover from this:

size.t=< n>

where n is the real number of samples per trace. You can find n by doing a

dd if=/dev/rst0 bs=100000 of=test

let it run for a bit then do

od -x < test | more

and count the number of bytes in the trace. You can spot the trace time series by looking for the 256 byte trace header and counting the number of bytes until the next one. Remember a sample is 4 bytes on a Sun/SGI machine and 8 bytes on the cray.

This one is easy, simply specify the output format to be:

out_format= segy float 4 ieee

The same syntax works for input if you think someone has given you non-standard SEGY floating point data.