Design SEG-Y
Journal de mission
Course à pied
Ski de randonnée
Alpinisme
Voile
Ecrits
Diaporamas
Programmation
Carnet des invités
Accueil > Programmation > Design d'un header SEG-Y
Design d'un en-tête au format texte pour fichier SEG-Y
But
Examiner comment le module SEGOU, option CGGSEGY3 écrit un fichier SEG-Y. Relire, par Geovecteur, le maximum d'information de ce même fichier. Informer le client du contenu de ce fichier SEG-Y.
Résumé
Est proposé un en-tête type pour fichier SEG-Y, à compléter selon l'habillage des mots d'étiquettes propre au flux de données concerné. Le code LIBRI FO, LIBRI BD et SEGOU relié est suggéré et il suffira d'insérer le bloc suivant dans le flux de données désiré.
C'est une proposition de base, à partir de laquelle, suivant modifications et discussion avec le client, on peut parvenir à un accord et un rangement conjointement convenu des données sismiques au format SEG-Y pour la satisfaction de tous.
* LIBRI FO 01 CGGSEGY 3,FOR3,LAB0,FWORD9,FWINC1,
HF(2,147)=1, HF(2,148)=1,
HTR03=CGG22(1,32),HTR9=1,
HTR97=CGG02(1,16),HTR96=CGG02(17,32),
* LIBRI BD 01 PREFIX=SY,B0099(RW),STG2,BLOCK,UNLIMITD,
* SEGOU == LBD01,LFO01,GAIN0,COMMENT,
Contractor, client; CGGVeritas,___________________________________
Country, survey, date; ______________________________________________
Geodesy information, as from the related SPS files describing the acquisition;
H12 Geodetic datum,-spheroid; ______________________________________________
H19 Projection zone; _____________________________________
H18 Projection type; UTM;
H20 Description of grid units; METRE;
______________________________________________________________________________
The table below describes the 240 bytes trace SEG-Y header contents.
Byt: Byte number, starting from 1 N : Number of bytes used for field value.
Wd : Original Geocluster word number (for internal CGGVeritas QC purpose)
Byt N Wd Information Byt N Wd Information Byt N Wd Information
1 4 .. Seq trace nb/line 81 4 60 R eastings (x) 153 4 31 _________________
5 4 .. Seq trace nb/reel 85 4 61 R northings (y) 157 4 32 Field tape number
9 4 22 Record number 89 4 56 ________________ 161 4 33 _________________
13 4 17 Channel number 93 4 55 ________________ 165 4 34 Field S line nb
17 4 39 ________________ 97 4 49 Cf note 5 below 169 4 35 Field S point nb
21 4 4 Grid x-line nb 101 2 48 Cf note 2 below 173 4 36 Field R line nb
25 2 .. (NA) 103 2 42 Cf note 3 below 177 4 37 Field R point nb
27 2 8 Cf note 1 below 105 4 43 Cmp northings (y)181 4 18 Field R label
29 2 11 Trace id Code 109 2 .. (NA) 185 4 21 Field S point
31 2 8 Cf note 1 below 111 2 .. (NA) 189 4 19 Grid i-line nb
33 2 48 Cf note 2 below 113 2 7 (NA) 193 4 5 _________________
35 2 .. (NA) 115 2 10 Nb of samples 197 4 45 _________________
37 4 20 S to R offset 117 2 9 Sampling interv. 201 4 46 _________________
41 4 38 ________________ 119 2 42 Cf note 3 below 205 4 44 Cmp eastings (x)
45 4 53 ________________ 121 4 23 ________________ 209 4 3 if Aux:9, Data:1
49 4 41 Bin eastings (x) 125 4 24 ________________ 213 4 15 _________________
53 4 52 ________________ 129 4 25 ________________ 217 4 50 _________________
57 4 57 ________________ 133 4 26 ________________ 221 4 51 _________________
61 4 40 ________________ 137 4 27 ________________ 225 4 64 Field error flags
65 4 47 Cf note 4 below 141 4 28 ________________ 229 4 2 Field S label
69 4 54 ________________ 145 4 29 ________________ 233 4 58 _________________
73 4 62 S eastings (x) 149 4 30 ________________ 237 4 59 _________________
------------------------------------------------------------------------------
Note 1: Bytes 27-28, 31-32 : Stacking fold (as Byt 27-28*512+Byt 31-32)
Note 2: Bytes 103-104, 119-120 : Source point index
Note 3: Bytes 119-120, 103-104 : Bin northings (y)
Note 4: Source codes : _______________________________________________________
Note 5: Receiver codes : _____________________________________________________
ENDCOM
Il est recommandé, pour les champs de l'en-tête teintés en;
- Rouge: de ne pas toucher ces champs, dont le contenu est "hautement recommandé" par la norme.
- Orangé: d'éditer seulement si le fichier concerne une section au lieu de tirs unitaires.
- Vert: d'éditer en rapport avec le contenu des mots dans le contexte propre de l'entrée dans le module.
Le contenu de ces derniers champs variant beaucoup selon le contexte (choix d'habillage propre au projet ou étape dans la séquence), seules quelques courantes et classiques valeurs sont ici suggérées. Il est de la responsabilité de l'utilisateur, en dernier lieu, d'informer correctement du contenu de ces valeurs.
Suivent maintenant des explications sur le cheminement effectué pour arriver à cette proposition.
1 - Ecriture d'un prototype SEG-Y
Le job prototype suivant nous fabrique 3 traces artificielles en mettant à jour leurs mots d'étiquettes de façon telle que MOTx==1000+x;
**==============================================================================
** File : dagen_segou.txt
** Comments:
** #lina
**============||======||======|=================================================
* LIBRI FO 01 CGGSEGY 3,FOR3,LAB0,FWORD9,TWORD2,FWINC1,
* LIBRI BD 01 CREW(TUN3216),PREFIX=SY,B99(RW),STG2,BLOCK,
UNLIMITD,
**============||======||======|=================================================
* DLOOP 1
* DAGEN SN ++ RL4000,SI1,F50,A32767,NT1,TAP0,
**-We just update each word as : MOTx=1000+x (except for 6,9,10)----------------
* MODET == ++ *MOT02=1002,*MOT03=1003,*MOT04=1004,*MOT05=1005,
*MOT07=1007,*MOT08=1008,*MOT11=1011,*MOT12=1012,
*MOT13=1013,*MOT14=1014,*MOT15=1015,*MOT16=1016,
*MOT17=1017,*MOT18=1018,*MOT19=1019,*MOT20=1020,
*MOT21=1021,*MOT22=1022,*MOT23=1023,*MOT24=1024,
*MOT25=1025,*MOT26=1026,*MOT27=1027,*MOT28=1028,
*MOT29=1029,*MOT30=1030,*MOT31=1031,*MOT32=1032,
*MOT33=1033,*MOT34=1034,*MOT35=1035,*MOT36=1036,
*MOT37=1037,*MOT38=1038,*MOT39=1039,*MOT40=1040,
*MOT41=1041,*MOT42=1042,*MOT43=1043,*MOT44=1044,
*MOT45=1045,*MOT46=1046,*MOT47=1047,*MOT48=1048,
*MOT49=1049,*MOT50=1050,*MOT51=1051,*MOT52=1052,
*MOT53=1053,*MOT54=1054,*MOT55=1055,*MOT56=1056,
*MOT57=1057,*MOT58=1058,*MOT59=1059,*MOT60=1060,
*MOT61=1061,*MOT62=1062,*MOT63=1063,*MOT64=1064,
* LISTE SS == STEP1,
* SEGOU == LBD01,LFO01,GAIN0,
* ENDLP
**============||======||======|=================================================
* PROCS X(YB1)
Après exécution, je peux examiner le contenu des mots tel que montré par le "LISTE SS" en décortiquant le .list ainsi;
xw82pt1% awk '/^ *WORD/' dagen_segou.07084.list | head -7 | sed 's/.*WORD//'
1 3999 1002 1003 1004 1005 0 1007 1008 1000 4000
11 1011 1012 1013 0.10E+04 0 *** 127 0 1017 1018 1019 1020
21 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030
31 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040
41 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050
51 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060
61 1061 1062 1063 1064
Le lecteur familier avec le format de ces "LISTE" comprend donc qu'à l'exception de certains mots réservés tels que 1, 6, 9, 10, les valeurs attendues, soit MOTx==1000+x sont donc bien mises à jour. Je sauvegarde cette information de cette façon;
xw82pt1% awk '/^ *WORD/' dagen_segou.07084.list | head -7 | cut -c17-200 | fold -w 11 | cat -n > out
soit en un fichier "out" montrant le contenu des mots en une seule colonne, ce qui, nous le verrons bientôt, sera pratique pour comparer lors de la relecture du SEG-Y créé. Ainsi, les huit premières lignes de "out" se présentent telles que;
xw82pt1% head -8 out
1 3999
2 1002
3 1003
4 1004
5 1005
6 0
7 1007
8 1008
2 - Relecture du prototype SEG-Y
Je relis le fichier produit en étape 1 par le job suivant;
**============================================================================== ** File : segy_segin.txt ** Comments: ** #lina **============||======||======|================================================= * LIBRI SI 01 M 99,PREFIX=SY,F1,STG2, * LIBRI FI 01 SEGY,FOR3, **============||======||======|================================================= * DLOOP 1 * SEGIN ++ RL4000,SI1,LFI01,LSI01, * LISTE == STEP1, * ENDLP **============||======||======|================================================= * PROCS X(YB1)
De la même façon, que précédement, je puis examiner le contenu des mots relus et "LISTE"és et aussi sauvegarder ceci en un fichier d'une seule colonne, que j'appelle maintenant "in";
xw82pt1% awk '/^ *WORD/' segy_segin.07086.list | head -7 | cut -c17-200 | fold -w 11 | cat -n > in
ce qui me permet de comparer efficacement "in" et "out" et de conclure quand à la relecture de mes valeurs de mots d'étiquettes;
xw82pt1% diff in out
1c1
< 1 0
---
> 1 3999
6,7c6,7
< 6 4000
< 7 0
---
> 6 0
> 7 1007
11,14c11,14
< 11 0
< 12 0
< 13 0
< 14 -0.10E+01
---
> 11 1011
> 12 1012
> 13 1013
> 14 0.10E+04
16c16
< 16 127 7
---
> 16 127 0
Je remarque, en lisant la première colonne, que les mots 1, 6, 7, 11, 12, 13, 14 et 16 ne sont pas reconduits, au contraire des autres. Peut-être est-il possible de faire, mais à priori, ces mots sont remis à jour lors de la relecture SEGIN. Les autres ayant étés relus, on peut conclure que l'information de ces mots a bel et bien été écrite en notre fichier SEG-Y.
A ce point, la question est de savoir où, dans le fichier, ces mots ont-ils été écrits?
3 - Examen de l'en-tête de trace SEG-Y
Rappelons le format SEG-Y;
La partie nous intéressant, en bleu, sont les 240 octets des en-têtes de trace. J'extrais cette partie intéressante de cette façon;
xw82pt1% dd bs=3600 skip=1 count=1 if=PSY0099TUN3216.DAT of=data
1+0 records in
1+0 records out
Ce qui, pour qui ne se rapelle plus de "dd", découpe fictivement le fichier d'entrée "if", soit notre SEG-Y nommé PSY0099TUN3216.DAT, en "blocs" de taille arbitraire, ici de 3600 octets, pour en "skipper" 1 et n'en recopier que le second en "of", ici appelé "data". Autremendit, du fichier SEG-Y original, "dd" me donne un petit fichier de 3600 octets tel,;
dont la partie rouge ne m'intéresse pas vraiment ici et dont on peut maintenant examiner le header de trace, soit la partie bleue, en lançant;
xw82pt1% od -Ad -N 240 -x -w32 data
J'épargne de la sortie de cette précédente commande, quelque peu pénible à lire car les bytes sont swappés deux-à-deux (à cause de l'"endianness" de l'ordinateur que j'utilise actuellement). La commande suivante;
xw82pt1% od -Ad -N 240 -x -w32 data |\
cut -c8-200 |\
fold -w5 |\
awk '{printf (" %s %s\n", substr($1,3,2), substr($1,1,2))}'|\
tr -d '\012' |\
fold -w 60 |\
awk 'BEGIN{\
printf (" ");\
for(i=1;i<21;i++)\
printf ("%3d", i);\
i=1;\
}{ \
printf ("\n%04d %s", i, $0);\
i+=20;\
}'
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
0001 00 00 00 01 00 00 00 01 00 00 03 ea 00 00 03 f9 00 00 04 0f
0021 00 00 03 ec 00 00 00 01 00 00 01 f0 00 00 00 01 ff ff fc 04
0041 00 00 04 0e 00 00 04 1d 00 00 04 11 00 00 04 1c 00 00 04 21
0061 00 00 04 10 00 00 04 17 00 00 04 1e 00 00 04 26 00 00 04 27
0081 00 00 04 24 00 00 04 25 00 00 04 20 00 00 04 1f 00 00 04 19
0101 04 18 04 12 00 00 04 13 00 7f 00 00 03 ef 0f a0 03 e8 00 00
0121 00 00 03 ff 00 00 04 00 00 00 04 01 00 00 04 02 00 00 04 03
0141 00 00 04 04 00 00 04 05 00 00 04 06 00 00 04 07 00 00 04 08
0161 00 00 04 09 00 00 04 0a 00 00 04 0b 00 00 04 0c 00 00 04 0d
0181 00 00 03 fa 00 00 03 fd 00 00 03 fb 00 00 03 ed 00 00 04 15
0201 00 00 04 16 00 00 04 14 00 00 03 eb 00 00 03 f7 00 00 04 1a
0221 00 00 04 1b 00 00 04 28 00 00 03 fe 00 00 04 22 00 00 04 23
certes plus complexe, a le mérite de tout remettre en place. Elle permet de montrer le résultat de façon bien colonnée, de permuter les bytes pairs et impairs et d'imprimer avec un addressage démarrant à 1 au lieu de 0, la norme utilisant plutôt cet addressage, sans doute plus conforme aux goûts des géophysiciens qu'à ceux des informaticiens.
Evidemment, les amoureux d'interfaces graphiques, non en reste, peuvent toujours utiliser un programme tel que (sur Red Hat 7.3) KhexEdit;
Cependant, la commande "od" offre en outre l'avantage de pouvoir être codée en MASPRO et de reformatter ainsi directement et automatiquement après fin du job et rend le tout beaucoup plus rapide.
Quoiqu'il en soit, peu importe le moyen, le but final est d'arriver à nos fins. Ainsi, je reconnais, marqué en bleu dans la table précédente, dans les bytes 9 à 12, un "3ea" hexadécimal, soit 1002 décimal. A priori, je retrouve donc ici mon mot 2.
Un examen sommaire révèle une suite bien simple. Les 60 octets 121 à 180 s'incrémentent de un en un. En effet, de 03ff à 040d, j'ai la suite décimale 1023 à 1037. A priori se retrouvent en cette plage mes mots 23 à 37, élégamment et simplement ordonnés. Simple et logique.
4 - Examen pour des valeurs extrêmes
Je relance mon job de l'étape 1 deux fois, en faisant sucessivement;
- MOTx=2147483500+x
- MOTx=-2147483500-x
afin de m'approcher des valeurs limites d'un entier signé, codé sur 32 bits. Petit truc intéressant, à signaler; les deux MODET nécessaires peuvent être codés en faisant un copier-coller des sorties respectives de;
awk 'BEGIN{for(i=2;i<65;i++)if(i!=6&&i!=9&&i!=10)printf("*MOT%02d=%d,",i,2147483500+i)}' | fold -w 36
awk 'BEGIN{for(i=2;i<65;i++)if(i!=6&&i!=9&&i!=10)printf("*MOT%02d=%d,",i,-2147483500-i)}' | fold -w 38
ce qui impressionnera peut-être "les amoureux d'interfaces graphiques" qui ont sans doute raison par ailleurs de ne guère priser ces commandes baroques, par ailleurs souvent très utiles .
Je reprends donc l'examen de mon étiquette de trace, en épargnant cette fois mon lecteur des tables hexadécimales correspondantes, quelque peu lourdes à lire. Toujours est-il que j'arrive à reconnaître l'emplacement de chaque mot. Pour les mots 8, 42 et 48, un examen plus approfondi est nécessaire.
4.1 - Examen des mots 8, 42 et 48.
En l'occurence, fait étrange, ces mots sont codés sur des octets disjoints. On trouve ainsi les :
Le mot 8 est le plus étrangement codé. En effet, l'examen révèle, pour différentes valeurs du mot 8, la variation des bytes 27,28,31,32 telle mais la formule cependant simple;
Bytes du SEG-Y
Mot 8 GVT 27 28 31 32 ; Produit décimal; Mot8 tel qu'en SEG-Y
2 : 00 00 00 02 ; 0 * 512 + 2 = 2
4 : 00 00 00 04 ; 0 * 512 + 4 = 4
8 : 00 00 00 08 ; 0 * 512 + 8 = 8
16 : 00 00 00 10 ; 0 * 512 + 16 = 16
32 : 00 00 00 20 ; 0 * 512 + 32 = 32
64 : 00 00 00 40 ; 0 * 512 + 64 = 64
128 : 00 00 00 80 ; 0 * 512 + 128 = 128
256 : 00 00 01 00 ; 0 * 512 + 256 = 256
512 : 00 01 00 00 ; 1 * 512 + 512 = 512
1024 : 00 02 00 00 ; 2 * 512 + 0 = 1024
2048 : 00 04 00 00 ; 4 * 512 + 0 = 2048
4096 : 00 08 00 00 ; 8 * 512 + 0 = 4096
8192 : 00 10 00 00 ; 16 * 512 + 0 = 8192
16384 : 00 20 00 00 ; 32 * 512 + 0 = 16384
32768 : 00 40 00 00 ; 64 * 512 + 0 = 32768
65636 : 00 80 00 64 ;128 * 512 + 100 = 65636
131072 : 01 00 00 00 ;256 * 512 + 0 = 131072
261032 : 01 fd 01 a8 ;509 * 512 + 424 = 261032
262143 : 01 ff 01 ff ;511 * 512 + 511 = 262143
262144 : 00 00 00 00 ; overflow... =
524288 : 00 00 00 00 ; overflow... =
1048576 : 00 00 00 00 ; overflow... =
2097152 : 00 00 00 00 ; overflow... =
mot8 = bytes(27-28) * 512 + bytes(31-32)
Le décoding est donc confirmé. Et la couverture ne peut prendre que des valeurs dans l'intervalle fermé [0, 262143].
Fait intéressant, advenant une couverture de 512, peu probable mais tout à fait possible dans une zone de transition où des tirs de remplacement furent effectués, la méconnaissance de cette disposition en bytes 27-28 du mot 8 peut faire croire à une couverture devenu subitement nulle, ce qui peut sembler alors très étrange pour le non-averti. Même si une couverture supérieure à 512 est rare, soyons tout de même avertis de cette curiosité bien particulière.
4.2 - Examen du mot 11.
Pour différentes valeurs de mot 11, on a;
Valeur 11 Bytes 29-30;
0 : 00 02
1 : 00 00
2 : 00 00
3 : 00 00
4 : 00 00
5 : 00 00
6 : 00 00
7 : 00 01
16 : 00 00
124 : 00 00
2048 : 00 00
La seule conclusion possible ici est que seules 3 valeurs sont tolérées dans les bytes 29-30; soit 1 et 2, pour des mots 11 valant respectivement 7 ou 0 et 0 pour les autres valeurs. Il semble donc que ce mot, géré par le module, soit hors de notre contrôle réel. De toutes façons, nous pouvons sans grand risque poser l'hypothèse que le mot 11 ne puisse valoir que 0 ou 7 et nous dispenser de pouvoir transmettre effectivement toute valeur différente de ces deux chiffres, Géovecteur n'admettant théoriquement que 0 ou 7 (15 pour une trace historique et ne devant pas se retrouver en un SEG-Y) pour le mot 11.
On verra plus loin que ceci est conforme à la norme, 2 valant pour une trace morte et 1 pour du signal sismique.
5 - Localisation des mots Géovecteur dans l'en-tête de trace SEG-Y
Nous pouvons dès lors déduire une table suivante détaillant de façon plus étoffée le comportement du module.
Nous délimitons sucessivement en vert puis en rouge les champs respectifs dans la table hexadécimale;
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 0001 00 00 00 01 00 00 00 01 00 00 03 ea 00 00 03 f9 00 00 04 0f 0021 00 00 03 ec 00 00 00 01 00 00 01 f0 00 00 00 01 ff ff fc 04 0041 00 00 04 0e 00 00 04 1d 00 00 04 11 00 00 04 1c 00 00 04 21 0061 00 00 04 10 00 00 04 17 00 00 04 1e 00 00 04 26 00 00 04 27 0081 00 00 04 24 00 00 04 25 00 00 04 20 00 00 04 1f 00 00 04 19 0101 04 18 04 12 00 00 04 13 00 7f 00 00 03 ef 0f a0 03 e8 00 00 0121 00 00 03 ff 00 00 04 00 00 00 04 01 00 00 04 02 00 00 04 03 0141 00 00 04 04 00 00 04 05 00 00 04 06 00 00 04 07 00 00 04 08 0161 00 00 04 09 00 00 04 0a 00 00 04 0b 00 00 04 0c 00 00 04 0d 0181 00 00 03 fa 00 00 03 fd 00 00 03 fb 00 00 03 ed 00 00 04 15 0201 00 00 04 16 00 00 04 14 00 00 03 eb 00 00 03 f7 00 00 04 1a 0221 00 00 04 1b 00 00 04 28 00 00 03 fe 00 00 04 22 00 00 04 23
D'où;
Byt: No de byte du header de trace SEG-Y (numéroté de 1) N : Nombre de bytes Wd : Numéro de mot Géovecteur Hex: Valeur hexadécimale trouvée en cet emplacement Dec: Valeur décimale Byt N Wd Hex Dec Byt N Wd Hex Dec Byt N Wd Hex Dec 1 4 .. 00000001 1 81 4 60 00000424 1060 153 4 31 00000407 1031 5 4 .. 00000001 1 85 4 61 00000425 1061 157 4 32 00000408 1032 9 4 2 000003ea 1002 89 4 56 00000420 1056 161 4 33 00000409 1033 13 4 17 000003f9 1017 93 4 55 0000041f 1055 165 4 34 0000040a 1034 17 4 39 0000040f 1039 97 4 49 00000419 1049 169 4 35 0000040b 1035 21 4 4 000003ec 1004 101 2 48 0418 1048 173 4 36 0000040c 1036 25 2 .. 0000 0 103 2 42 0412 1042 177 4 37 0000040d 1037 27 2 .8 0001 512 105 4 43 00000413 1043 181 4 18 000003fa 1018 29 2 11 0000 0 109 2 .. 007f 127 185 4 21 000003fd 1021 31 2 .8 01f0 496 111 2 .. 0000 0 189 4 19 000003fb 1019 33 2 48 0000 0 113 2 7 03ef 1007 193 4 5 000003ed 1005 35 2 .. 0001 1 115 2 .. 0fa0 4000 197 4 45 00000415 1045 37 4 20 fffffc04-1020 117 2 .. 03e8 1000 201 4 46 00000416 1046 41 4 38 0000040e 1049 119 2 42 0000 0 205 4 44 00000414 1044 45 4 53 0000041d 1053 121 4 23 000003ff 1023 209 4 3 000003eb 1003 49 4 41 00000411 1041 125 4 24 00000400 1024 213 4 15 000003f7 1015 53 4 52 0000041c 1052 129 4 25 00000401 1025 217 4 50 0000041a 1050 57 4 57 00000421 1057 133 4 26 00000402 1026 221 4 51 0000041b 1051 61 4 40 00000410 1040 137 4 27 00000403 1027 225 4 64 00000428 1064 65 4 47 00000417 1047 141 4 28 00000404 1028 229 4 22 000003fe 1022 69 4 54 0000041e 1054 145 4 29 00002405 1029 233 4 58 00000422 1058 73 4 62 00000426 1062 149 4 30 00000406 1030 237 4 59 00000423 1059 77 4 63 00000427 1063
5.1 - Habillage mot 11.
La norme "recommande" fortement un habillage correct des bytes 29 à 32, lequel doit valoir 1 pour du signal sismique. Nous réalisons que cet habillage est très bien géré par le module, lequel, comme vu plus tôt, habille ces bytes avec 2 ou 1 selon une valeur respective du mot 11 de 0 ou 7. Ceci est conforme à la norme.
5.2 - Permutation mots 22 et 2 nécessaire.
Par contre, la norme SEG-Y précise un champ de bytes 9 à 12 dont il est "fortement recommandé" qu'il soit habillé avec le numéro de record. Or, le module écrit en cet endroit le mot 2 et non pas le numéro de record, lequel est habituellement stocké dans le mot 22.
Pour cette raison, il est ici suggéré de permuter les contenus de ces mots, ce qui oblige de ce fait l'ajout de trois lignes HTR dans la libri FO afin d'opérer la permutation. Il est à remarquer que MODET aurait pu être utilisé mais est déconseillé. Les lignes MODET étant plus souvent manipulées par les utilisateurs, au contraire d'une ligne HTR, cette solution de code HTR semble plus sécuritaire. La librairie devient alors;
* LIBRI FO 01 CGGSEGY 3,FOR3,LAB0,FWORD9,FWINC1,
HTR03=CGG22(1,32),
HTR97=CGG2(1,16),
HTR96=CGG2(17,32),
Par conséquent, nous devons également permuter ces mots 22 et 2 à nouveau lors de la relecture.
Ainsi, un job de relecture de ce SEG-Y peut-il finalement se lire;
**==============================================================================
** File : segy_segin.txt
** Comments:
** #lina
**============||======||======|=================================================
* LIBRI SI 01 PREFIX=SY,M 99,F1,STG2,
* LIBRI FI 01 SEGY,FOR3,
CGG22(1,32)=HTR03,
CGG2(1,16)=HTR97,
CGG2(17,32)=HTR96,
**============||======||======|=================================================
* DLOOP 1
* SEGIN ++ RL4000,SI1,LFI01,LSI01,
* LISTE SS == STEP1,
* ENDLP
**============||======||======|=================================================
* PROCS X(YB1)
... d'où, finalement, l'en-tête proposé en début de cette page.
6 - La définition du header de trace SEG-Y versus l'écriture Géovecteur
Il est à noter, et c'est la raison pour laquelle une description pertinente est nécessaire, que le format CGGSEGY3 s'écarte sensiblement de la définition du SEG-Y, décrite dans le paragraphe suivant;
Plusieurs champs du SEG-Y occupent deux octets alors que les mots Géovecteurs en occupent quatre.
Pour cette raison, il est espéré que l'entête ASCII de base proposé en début de cette page puisse faire en sorte de rendre cette information explicite et améliorer le contrôle qualité. En effet, il;
- décrit complètement l'écriture du SEG-Y
- minimise la possibilité de permutations de champ puisqu'elle ne nécessite aucun "MODET" mais une seule et simple "libri FO" minimaliste en entrée comme en sortie.
- permet une relecture des données par le module SEGIN
Ce dernier point mérite qu'on s'y attarde pour deux raisons;
- un bon contrôle qualité sous-entend la relecture et la vérification des données avant leur délivrance au client.
- la sauvegarde, après géométrie, des données au seul format SEG-Y plutôt que SEG-Y et CGG permettrait de diminuer de moitié l'espace disque nécessaire en ne stockant ces données sous un seul plutôt que deux formats.
Le client étant roi, il reste tout à fait possible d'entendre celui-ci exprimer une demande particulière, ou un rangement particulier du SEG-Y, rendant de ce fait les présentes recommendations obsolètes. Je ne doute pas cependant de la valeur de ces recommendations car elles peuvent servir d'une très solide base de départ à partir de laquelle on pourra obtenir à moindre coût à la fois satisfaction du client et qualité.
Advenant un reformattage plus complexe, on se réfèrera le cas échéant aux personnes ressources concernées, alors en mesure de prêter main-forte dans l'écriture d'une libri FO d'écriture, ainsi que d'une libri FI de relecture. A ce sujet, des outils de contrôles ont récemment été produits et aideront à la tâche.
L'en-tête de trace étant examiné, il reste à regarder l'en-tête binaire de fichier.
9 - Header binaire de fichier 400 bytes
Nous examinons maintenant la partie verte de l'image ci-haut mentionnée;
En ce header binaire de 400 bytes, la norme signale "hautement recommandés" voire "obligatoires" les champs suivants;
Byte Nb Explication 13 2 Nombre de traces par ensemble 15 2 Nombre de traces auxiliaires par ensemble 17 2 Echantillonnage en microsecondes 21 2 Nombre d'échantillons 25 2 (Format binaire des échantillons) 27 2 Couverture par ensemble 29 2 Type de collection 55 2 Unites topographiques (mètres:1, pieds:2) 301 2 Numéro de révision SEG-Y 303 2 Flag de signalement de longueur constante de trace 305 2 Signalement de l'en-tête texte.
- Bytes 13-14 : Nombre de traces par ensemble. La norme est ici ambigüe, le nombre de traces pouvant varier d'un ensemble à l'autre. C'est le cas habituel de tirs unitaires où les dispositifs varient en taille. On peut néanmoins écrire le nombre de trace du dispositif nominal. Et, disons, 0 pour des données stackées. Le module écrit identiquement 0.
- Bytes 15-16 : Nombre de traces auxiliaires par ensemble. Les canaux auxiliaires étant presque toujours discriminés du flux de données après la géométrie, il est ici suggéré d'écrire 0, ce qu'écrit bien le module.
- Bytes 17-18 : Echantillonnage en microsecondes. L'examen du header pour un échantillonnage de 1, 2 et 4 millisecondes révèlant respectivement 0x03e8, 0x07d0 et 0x0fa0, soit 1000, 2000 et 4000, la gestion de ces bytes est donc correctement effectuée par le module.
- Bytes 21-22 : Nombre d'échantillons par trace. Une trace de 4000 ms, respectivement échantillonnée à 1, 2 et 4s donne ici 0x0fa0, 0x07d0 et 0x03e8, soit 4000, 2000 et 1000 échantillons. Un essai de longueur de 3999 ms avec un pas de 3 ms révèle en outre 0x0535, soit 1333. La gestion de ces bytes est donc correctement effectuée par le module.
- Bytes 25-26 : Format binaire. FOR1, FOR3, FOR8058, soit entier 16 bits, 32 bits IBM et 32 bits IEEE sont respectivement testés et donnent respectivement 0x0003, 0x0001 et 0x0005, ce qui correspond à la convention de la norme. La gestion de ces bytes est donc correctement effectuée par le module.
- Bytes 27-28 : La couverture "espérée" par ensemble. La norme me semble ici ambigüe. Dans le doute, et puisque de toutes façons la couverture réelle est correctement gérée par le mot8 et bien écrite dans le header de trace, il est aussi suggéré de faire ici confiance au module.
- Bytes 29-30 : Type de collection. La norme signalant 1 pour des tirs unitaires ou 4 pour des sections, la personne minutieuse écrira, selon ces cas respectifs; HF(2,12)=1 ou HF(2,12)=4. Cependant, le module écrivant par défaut 0, signalant par conséquent "unknown" et puisque nous prenons choix de spécifier de façon explicite dans le header texte la présence de tirs unitaires ou de données stackées, il est ici suggéré de bel et bien laisser encore une fois le module gérer ces bytes de lui-même.
- Bytes 55-56 : Unités utilisées. Tout indique que le module écrive identiquement ici 0x0001, signalant de ce fait des données au format métrique. Advenant des coordonnées en pieds, il serait avisé de coder HF(2,25)=2. Néanmoins, il est ici suggérer d'indiquer les unités dans le header texte. Or, la norme signale que les unités décrites dans l'en-tête texte doivent primer.
- Bytes 301-302 : Norme utilisée. Le module semble identiquement coder 0x0000, ce qui correspond à la norme SEG-Y de 1975. Le présent document se réfèrant à celle de mai 2002, il est suggéré de coder par conséquent HF(2,147)=1.
- Bytes 303-304 : Flag de longueur de trace constante. 1 signalant un nombre d'échantillons constant par trace, et 0 signalant, encore une fois, la conformité à la norme de 1975, il est suggéré de coder 1, et, par conséquent HF(2,148)=1,
- Bytes 305-306 : Nombre d'en-tête texte présents. Une valeur unitaire est recommandée. Comme le module écrit 0 par défaut, il est suggéré de coder HF(2,149)=1.
Il est à remarquer que la documentation Géovecteur sur la libri FO présente 197 comme dernier élément possible à coder. Or l'élément 28 semble impossible à modifier et les bytes 61 à 63 semblent réservés; de l'élément 27 en bytes 59-60, on passe à l'élément 29 en bytes 65-66, de telle sorte que le dernier élément possible n'est pas le 197 annoncé, mais bien 196. La règle générale est qu'on observe, pour un élément N supérieur ou égal à 29, un adressage dans les bytes 2N+7 et 2N+8.
Par conséquent, pour fins de simplifications et de risques d'erreur, on arrive à la libri FO proposée comme base en début de ce document, relativement simple et donc peu sujette à erreurs.
9 - Ecriture en format 16 bits, 8 bits
Les données stackées présentant une dynamique d'amplitude beaucoup moins grande que les tirs unitaires, il est intéressant de sauvegarder celles-ci au format 16 bits. La perte d'information, minimale, ne représente rien quand au gain précisément double de bande passante. Et pourquoi ne pas sauvegarder au format 8 bits et alors quadrupler la taille de fichier possible à poster? Lorsque ces données doivent circuler via internet, pareilles options sont à considérer avec intérêt.
Malheureusement, pour une écriture aussi compacte que 8 bits, il faut considérer un autre outil que SEGOU, celui-ci ne permettant au mieux qu'un format 16 bits entier.
10 - Exemple de job
Voici un exemple de job, avec des données fictives, utilisant le code de base proposé;
**==============================================================================
** File : segy.txt
** G. Martineau
** Comments:
** #lina
**============||======||======|=================================================
* LIBRI TR 01 CREW(TUN3216),PREFIX=GE,C12,F1,STG,
**============||======||======|=================================================
* DLOOP 1
* INPTR ++ LTR01,RL5000,SI2,Y=MOT2,K1,
* LIBRI FO 01 CGGSEGY 3,FOR3,LAB0,FWORD9,FWINC1,
HF(2,147)=1, HF(2,148)=1,
HTR03=CGG22(1,32),HTR9=1,
HTR97=CGG02(1,16),HTR96=CGG02(17,32),
* LIBRI BD 01 PREFIX=SY,B0099(RW),STG2,BLOCK,UNLIMITD,
* SEGOU == LBD01,LFO01,GAIN0,COMMENT,
Contractor, client; CGGVeritas,client fictif______________________
Country, survey, date; Boukistan,Lac de la peche traquille 3DTZ,2007_
Geodesy information, as from the related SPS files describing the acquisition;
H12 Geodetic datum,-spheroid; CARTHAGE CLARKE 1880 6378249.200 293.4660213
H19 Projection zone; UTM FUSEAU 32 N 9 E;______________
H18 Projection type; UTM;
H20 Description of grid units; METRE;
Data is unstacked shots records, sorted as recorded.
The table below describes the 240 bytes bytes trace SEG-Y header contents.
Byt: Byte number, starting from 1 N : Number of bytes used for field value.
Wd : Original Geocluster word number (for internal CGGVeritas QC purpose)
Byt N Wd Information Byt N Wd Information Byt N Wd Information
1 4 .. Seq trace nb/line 81 4 60 R eastings (x) 153 4 31 _________________
5 4 .. Seq trace nb/reel 85 4 61 R northings (y) 157 4 32 Field tape number
9 4 22 Record number 89 4 56 Date, as yJJJ___ 161 4 33 _________________
13 4 17 Channel number 93 4 55 Hour, as hhmmss_ 165 4 34 Field S line nb
17 4 39 ________________ 97 4 49 ________________ 169 4 35 Field S point nb
21 4 4 Grid x-line nb 101 2 48 Cf note 2 below 173 4 36 Field R line nb
25 2 .. (NA) 103 2 42 Cf note 3 below 177 4 37 Field R point nb
27 2 8 Cf note 1 below 105 4 43 Cmp northings (y)181 4 18 Field R label
29 2 11 Trace id Code 109 2 .. (NA) 185 4 21 Field S point
31 2 8 Cf note 1 below 111 2 .. (NA) 189 4 19 Grid i-line nb
33 2 48 Cf note 2 below 113 2 7 (NA) 193 4 5 _________________
35 2 .. (NA) 115 2 10 Nb of samples 197 4 45 _________________
37 4 20 S to R offset 117 2 9 Sampling interv. 201 4 46 _________________
41 4 38 ________________ 119 2 42 Cf note 3 below 205 4 44 Cmp eastings (x)
45 4 53 R serial number_ 121 4 23 Tide (as cm)____ 209 4 3 if Aux:9, Data:1
49 4 41 Bin eastings (x) 125 4 24 Wdepth R (as cm) 213 4 15 _________________
53 4 52 ________________ 129 4 25 Wdepth S (as cm) 217 4 50 _________________
57 4 57 ________________ 133 4 26 Gun depth (cm)__ 221 4 51 _________________
61 4 40 GPS hour________ 137 4 27 Channel set_____ 225 4 64 Field error flags
65 4 47 cf note 4 below_ 141 4 28 ________________ 229 4 2 Field S label
69 4 54 ________________ 145 4 29 ________________ 233 4 58 _________________
73 4 62 S eastings (x) 149 4 30 Receiver imped__ 237 4 59 _________________
------------------------------------------------------------------------------
Note 1: Bytes 27-28, 31-32 : Stacking fold (as Byt 27-28*512+Byt 31-32):1
Note 2: Bytes 103-104, 119-120 : Source point index
Note 3: Bytes 119-120, 103-104 : Bin northings (y)
Note 4: Source code: 20 : A1 this boat, 21 : A2 :that boat A3 vibro...
Note 5: Receiver code: G1 : SM4U, H1 : Hydrophones
ENDCOM
* ENDLP
**============||======||======|=================================================
* PROCS X(YB1)
En dernière remarque, en guise de conclusion, signalons un comportement étrange. J'exécute ce simple job;
**============||======||======|================================================= * LIBRI FO 01 CGGSEGY 3,FOR3,LAB0,FWORD9,FWINC1, * LIBRI BD 01 CREW(TUN3216),PREFIX=SY,B98(RW),STG2,BLOCK, **============||======||======|================================================= * DLOOP 1 * DAGEN SN ++ RL250,SI2,F50,A32767,NT4,TAP0, * SEGOU == LBD01,LFO01,GAIN0, * ENDLP **============||======||======|================================================ * PROCS X(YB1)
J'observe ensuite la présence de mon fichier de sortie; La taille, de 6560 octets est bien celle attendue, soit 3600 + 4 * (240+500).
-rw-r--r-- 1 massy geovect 6560 Nov 13 17:36 PSY0098TUN3216.DAT
Que je relis avec ce job;
**============||======||======|================================================= * LIBRI SI 01 M98,PREFIX=SY,F1,STG2, * LIBRI FI 01 SEGY,FOR3, **============||======||======|================================================= * DLOOP 1 * SEGIN ++ RL250,SI2,LFI01,LSI01, * WUNET == FILE=local:tiens_donc.cst * ENDLP **============||======||======|================================================= * PROCS X(YB1)
Je lance une nouvelle génération de SEG-Y, avec cette fois 30 Hertz et 2 traces au lieu de 4;
**============||======||======|================================================= * LIBRI FO 01 CGGSEGY 3,FOR3,LAB0,FWORD9,FWINC1, * LIBRI BD 01 CREW(TUN3216),PREFIX=SY,B98(RW),STG2,BLOCK, **============||======||======|================================================= * DLOOP 1 * DAGEN SN ++ RL250,SI2,F30,A32767,NT2,TAP0, * SEGOU == LBD01,LFO01,GAIN0, * ENDLP **============||======||======|================================================ * PROCS X(YB1)
Taille du nouveau fichier ? Voici;
-rw-r--r-- 1 massy geovect 6560 Nov 13 17:39 PSY0098TUN3216.DAT
Si la date de fichier est bonne, sa taille aurait dû être non pas de 6560, mais bien de 5080 octets, soit 3600 + 2 * (240+500). Qu'est-il arrivé? Je relance une nouvelle lecture pour WUNET et ouvre exam.
L'examen visuel des deux fichiers avec exam montre que mon second fichier contient bien les deux nouvelles traces à 30 Hz, mais que les traces de la précédente exécution, de 50 Hz, y sont aussi;
En guise de conclusion, on dira qu'il est extrêmement important, sur disque, de supprimer tout fichier de sortie déjà présent, résultant d'une éventuelle éxécution précédente, lequel serait mal "écrasé".
Et, pour terminer, cette remarque d'un client, entendue en mon bureau en 2001 en Tunisie;
- "Seg-Y is a standard format and everybody agrees... that nobody can read it".
11 - Liens proposés
Pour plus d'information;
Annexe - Table : la définition du header de trace SEG-Y versus l'écriture Géovecteur
| Bytes | Valeur | Valeur ou mot CGGSEGY 3 | Explication référence SEG-Y (en langue originale) |
|---|---|---|---|
| 1- 4 | 00000001 | * Trace sequence number within line. | |
| 5- 8 | 00000001 | Trace sequence number within reel. | |
| 9- 12 | 000003ea | Mot 02 | * Original field record number. |
| 13- 16 | 000003f9 | Mot 17 | * Trace sequence number within original field record. |
| 17- 20 | 0000040f | Mot 39 | Energy source point number. |
| 21- 24 | 000003ec | Mot 04 | CDP ensemble number. |
| 25- 26 | 00000001 | Trace sequence number within CDP ensemble. | |
| 27- 28 | 00000001 | Mot 8h | |
| 29- 30 | 0000 | *Trace identification code: 1 = seismic data 2 = dead 3 = dummy 4 = time break 5 = uphole 6 = sweep 7 = timing 8 = water break 9+ = optional use | |
| 31- 32 | 01f0 | Mot 8l | Number of vertically summed traces yielding this trace. |
| 33- 34 | 0000 | 0 | Number of horizontally stacked traced yielding this trace. |
| 35- 36 | 0001 | 1 | Data use (1 = production, 2 = test). |
| 37- 40 | fffffc04 | Mot 20 | Distance from source point to receiver group. |
| 41- 44 | 0000040e | Mot 38 | Receiver group elevation. |
| 45- 48 | 0000041d | Mot 53 | Surface elevation at source. |
| 49- 52 | 00000411 | Mot 41 | Source depth below surface. |
| 53- 56 | 0000041c | Mot 52 | Datum elevation at receiver group. |
| 57- 60 | 00000421 | Mot 57 | Datum elevation at source. |
| 61- 64 | 00000410 | Mot 40 | Water depth at source. |
| 65- 68 | 00000417 | Mot 47 | Water depth at receiver group. |
| 69- 70 | 0000 | Mot 54h | Scalar for elevations and depths (+ = multiplier, - = divisor). |
| 71- 72 | 041e | Mot 54l | Scalar for coordinates (+ = multiplier, - = divisor). |
| 73- 76 | 00000426 | Mot 62 | X source coordinate. |
| 77- 80 | 00000427 | Mot 63 | Y source coordinate. |
| 81- 84 | 00000424 | Mot 60 | X receiver group coordinate. |
| 85- 88 | 00000425 | Mot 61 | Y receiver group coordinate. |
| 89- 90 | 0000 | Mot 56l | Coordinate units (1 = length in meters or feet, 2 = arc seconds). |
| 91- 92 | 0420 | Mot 56h | Weathering velocity. |
| 93- 94 | 0000 | Mot 55l | Subweathering velocity. |
| 95- 96 | 041f | Mot 55h | Uphole time at source. |
| 97- 98 | 0000 | Mot 49l | Uphole time at receiver group. |
| 99-100 | 0419 | Mot 49h | Source static correction. |
| 101-102 | 0418 | Mot 48l | Receiver group static correction. |
| 103-104 | 0412 | Mot 42l | Total static applied. |
| 105-106 | 0000 | Mot 43h | Lag time between end of header and time break in milliseconds. |
| 107-108 | 0413 | Mot 43l | Lag time between time break and shot in milliseconds. |
| 109-110 | 007f | Lag time beteen shot and recording start in milliseconds. | |
| 111-112 | 0000 | Start of mute time. | |
| 113-114 | 03ef | Mot 07l | End of mute time. |
| 115-116 | 0fa0 | 4000 | * Number of samples in this trace. |
| 117-118 | 03e8 | 1000 | * Sample interval of this trace in microseconds. |
| 119-120 | 0000 | 0 | Field instrument gain type code: 1 = fixed 2 = binary 3 = floating point 4+ = optional use |
| 121-122 | 0000 | Mot 23l | Instrument gain constant. |
| 123-124 | 03ff | Mot 23h | Intrument early gain in decibels. |
| 125-126 | 0000 | Mot 24h | Correlated (1 = no, 2 = yes). |
| 127-128 | 0403 | Mot 24l | Sweep frequency at start. |
| 129-130 | 0000 | Mot 25h | Sweep fequency at end. |
| 131-132 | 0401 | Mot 25l | / Sweep length in milliseconds. |
| 133-134 | 0000 | Mot 26h | Sweep type code: 1 = linear 2 = parabolic 3 = exponential 4 = other |
| 135-136 | 0402 | Mot 26l | Sweep taper trace length at start in milliseconds. |
| 137-138 | 0000 | Mot 27h | Sweep taper trace length at end in milliseconds. |
| 139-140 | 0403 | Mot 27l | Taper type code: 1 = linear 2 = cosine squared 3 = other |
| 141-142 | 0000 | Mot 28h | Alias filter frequency. |
| 143-144 | 0404 | Mot 28l | Alias filter slope. |
| 145-146 | 0000 | Mot 29h | Notch filter frequency. |
| 147-148 | 0405 | Mot 29l | Notch filter slope. |
| 149-150 | 0000 | Mot 30h | Low cut frequency. |
| 151-152 | 0406 | Mot 30l | High cut frequency. |
| 153-154 | 0000 | Mot 31h | Low cut slope. |
| 155-156 | 0407 | Mot 31l | High cut slope. |
| 157-158 | 0000 | Mot 32h | Year data recorded. |
| 159-160 | 0408 | Mot 32l | Day of year. |
| 161-162 | 0000 | Mot 33h | Hour of day (24-hour clock). |
| 163-164 | 0409 | Mot 33l | Minute of hour. |
| 165-166 | 0000 | Mot 34h | Second of minute. |
| 167-168 | 040a | Mot 34l | Time basis (1 = local, 2 = GMT, 3 = other). |
| 169-170 | 0000 | Mot 35h | Trace weighting factor for fixed-point format data. |
| 171-172 | 040b | Mot 35l | Geophone group number of roll switch position one. |
| 173-174 | 0000 | Mot 36h | Geophone group number of first trace of original field record. |
| 175-176 | 040c | Mot 36l | Geophone group number of last trace of original field record. |
| 177-178 | 0000 | Mot 37h | Gap size (total number of groups dropped). |
| 179-180 | 040d | Mot 37l | Overtravel associated with taper (1 = down/behind, 2 = up/ahead). |
| 181-184 | 000003fa | Mot 18 | 181 to 240: Unassigned (for optional information). |
| 185-188 | 000003fd | Mot 21 | |
| 189-192 | 000003fb | Mot 19 | |
| 197-200 | 000003ed | Mot 05 | |
| 205-208 | 00000415 | Mot 45 | |
| 209-212 | 00000416 | Mot 46 | |
| 217-220 | 00000414 | Mot 44 | |
| 221-224 | 0000041b | Mot 51 | |
| 225-228 | 00000428 | Mot 64 | |
| 229-232 | 000003fe | Mot 22 | |
| 233-236 | 00000422 | Mot 58 | |
| 237-240 | 00000423 | Mot 59 |