Forslag til forbedring av datainnsamling
med multikanals streamer.
Planlegging av linjer.
Det er en stor fordel at linjene blir godt planlagt på forhånd hvis en online prosessring skal virke korrekt. Med det mener jeg at start og stopp punkt bør være klart definert på forhånd, bade i geografiske og UTM koordinater. Vi kan så definere et skuddpunktkart før linjen starter. Vi plotter altså opp et teoretisk skuddpunkts kart der vi ønsker at skuddet skal komme, samt definerer en retning slik at vi kan både ha eventnummer i stigende rekkefølge og i minkende. Dette kartet kan se noe slik ut.
Teoretisk skuddpunkts kart
Grunnene til dette er mange.
- Ryddig og raskt navigasjons prosessering.
- Enkelt å finne frem til CDP lokasjoner. Noe som er viktig for å lage et mest mulig korrekt hastighets felt, front mute, dekon paramtre, etc.
- Vi vet hvor vi er, når vi kun har en såkalt nominell geometri ved online prosessering.
Det er også ønskelig at vi operer med et eventnummer pr. cdp lokasjon, dvs at med 25m gruppeintervall (altså 12.5m cdp intervall) og 50m skudd avstand, bør eventnummer økes/minkes med 4. På den måten får vi en konsistent nominell geometri. Om dette skal fungere perfekt bør Eiva dataene bli skrevet direkte i SEGY traseheaderen. Se forøvrig punkt 3.
Demultiplexing på direkten.
Vi kan spare 2 ukers kjedelig arbeid ved å gjøre demultiplexingen under data innsamlingen, enten bør vi skrive SEGY data fil for fil til tape og smelte disse sammen til et tape image etter at linja er skutt. Eller vi kan skrive hele tape imaget online, men da må vi ha et program som sjekker fila som kommer fra DFS'en at den inneholder alle de samples den skal ha. Siste metoden er vel mindre robust, men du verden så praktisk.
Jeg jobber for tiden med en skisse for dette, hvilken metode vi skal gå for vet jeg ikke. Det er jo mulig å lage et program som gjøre begge deler så får erfaring vise hva vi bør gå for.
Merge eventnummer i SEGY fil.
I dag må de som sitter å observerer følge nøye med på eventnummer og FFID i loggen slik at vi vet når vi mister skudd. Detter arbeidet er veldig kjedelig, og en kan lett miste konsentrasjonen slik at man overser tap av et skudd. Mister vi denne informasjonen vil geomtrien bli feil. Det skjer på hver eneste linje at Eiva systemet trigger uten at vi får skuddet lagret. Det er i og for seg ingen krise at vi mister noen skudd i løpet av en linje bare vi vet hvilket skudd som uteble. Derfor hadde det vært vedlig smart at eventnummeret ble skrevet i traseheaderen på SEGY dataene, da slipper en å stirre på den evindelig loggen også (les. bli sjøsjuk). Jeg foreslår at eventnummeret blir fanget opp av sync. enheten, og at denne sender FFID og eventnummer til pc'en som skal demultiplekse og skrive SEGY tapen. Detter krever en viss modifikasjon av sync. enheten, men det bør kunne gjøres uten alt for mye arbeid.
Forbedring av Eiva event trigger filter.
Dette er noe som ligger utenfor vårt arbeidsområde, men vi bør forfatte en mail til Eiva i Danmark å fortelle om problemene våre. Problemet oppstår i nordlige områder der vi mister differentsiell korreksjon, eivaen trigger noen ganger vedlig kort tid etter forrige skudd. Helt ned til 3 sekunders intervall er observert (litt lite når recording tiden er 12 sekunder). Det skal være et filter som forhindrer at dette skal skje, hvordan det filteret fungerer vet jeg ikke, men det ser ikke ut til at det fungerer tilfredstillende. Det er iallefall klart at båten ikke kan forflytte seg 12meter på 3 sekunder.
En annen løsning kan være å bruke flære GPS'er som korrigerer hverandre istedenfor DGPS under slike forhold.
Bug fix, og implementering av mere online processing.
Vi hadde en del problemer innledningsvis under Svalbard toktet høsten 1999, noe som ført til at online prosessering ble strippet helt ned, for deretter å bli tatt opp igjen på siste leg. Det viste seg at det ikke var så veldig mange bugs i dette systemet da det var en deamon på innsamlings pc'en som skapte trøbbel. Dette programmet ble byttet ut med et helt nytt programm skrevet under innsamlingen av Ole Meyer. Dette så ut til å virke tilfredstillende. Får jeg det som jeg vil, blir denne prosessen bli skiftet ut med noe mer stabilt uansett. Det var dog et par bugs jeg likevel vil nevne.
- Bug i RMS image plotter.
- Online stack fungerer ikke ved lange linje, må forbedres eller deles opp i mindre biter.
- Bug i sustack rutinen i Seismic Unix, den er rettet opp i SU på seismix. Vet ikke om fixen blir rettet opp i neste versjon av SU.
- Forbedre rutiner på å lage plott underveis.
Det er laget en alfa versjon av en SEGB til SU konverterer (demultipleksing) for UNIX, jeg vil at denne skal implementeres i et acquisition program som skal lagre SEGY data direkte på tape samt mate et online prosessering system med data over 100mbit ethernet. Prosesseringsystemet er så å si det samme som vi hadde, men får en mer robust mating av data. Det er også et ønske om at det blir tilpasset nettverksinstallasjon slik at flære maskiner kan kjøre samme system samtidig. Det finnes også en mulighet for å lage et fullstendig brukergrensesnitt på det, men jeg tror det vil svekke fleksibiliteten en nå har ved at det er script basert. Det forutsetter dog en viss peiling på enkel script programmering.