Erstellung des digitalen Modells einer geologischen Schicht mittels

Erstellung des digitalen Modells einer
geologischen Schicht mittels Gocad sowie
anschließendem Export des Modells nach Petrel
Studienarbeit
von
Peter Menzel
Studiengang Geoinformatik
Matrikel-Nr: 44717
Betreuer:
P. Melzer (TU Bergakademie Freiberg)
S. Schmitz (DBI-GUT)
TU Bergakademie Freiberg - Professur für Mathematische
Geologie und Geoinformatik
Deutsches Brennstoff Institut - Gas- und Umwelttechnik
(DBI-GUT)
Inhaltsverzeichnis
1 Einleitung
1.1 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Ziel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2
2
2 Geologie
2.1 Geologie der zu modellierenden Schicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Notwendige Abweichungen des Modells von der realen Geologie . . . . . . . . . . . . . . .
3
3
3
3 Modellerstellung mittels ArcGIS und Gocad
3.1 Eingangsdatenlage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Verarbeitung der Rohdaten zu den zu modellierenden Horizonten . . . . . . . . . . . . . .
3.3 Erstellung des SGrids mit unregelmäßiger Form . . . . . . . . . . . . . . . . . . . . . . . .
4
4
4
7
4 Export des Gocad-SGrid-Modells
4.1 Exportmöglichkeiten von Gocad nach Petrel . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Generelle Problematik beim Export/Import . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Import der exportierten Daten in Petrel . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
9
9
11
5 Fazit
14
A Anhang
A.1 Dokumentation eines Exports aus Gocad nach Petrel . . . . . . . . . . . . . . . . . . . . .
A.2 Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.3 Importmöglichkeiten von Petrel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
15
17
18
1
1
Einleitung
Derzeitig befinden sich viele verschiedene geologische Modellierungs- und Simulationsprogramme auf dem
Markt und in Benutzung durch viele spezialisierte Anwender. Aufgrund komplexer Handhabung und vor
dem Hintergrund der kostenintensiven Lizenzen für die einzelnen Softwarepakete, benutzen die meisten
Anwender nur jeweils eines oder wenige der verfügbaren Programme. Dies führt dazu, dass für den Anwender die Möglichkeiten, Vor- und Nachteile sowie Schnittstellen von nicht benutzten Softwarepaketen
nicht oder nur unzureichend bekannt sind.
In dieser Studienarbeit werden die Kompatibilität der Softwarepakete Gocad, als Export- und Modellierungsplattform, und Petrel, als Importplattform, analysiert und mögliche Export/Importszenarien dokumentiert. Dazu wird mit Gocad ein parametrisiertes Modell einer realen geologischen Schicht modelliert
und dieses dann mittels der Gocad-eigenen Exportmöglichkeiten für die betreffenden Datentypen (z.B.
SGrid) exportiert und in Petrel importiert.
Ziel ist es, für einen Petrel-Anwender die Verwendung von mit Gocad erzeugten Daten zu ermöglichen
und mögliche Probleme bei der Portierung der Daten aufzuzeigen.
Für diese Arbeit werden Grundkenntnisse in der Gocad-Benutzung vorausgesetzt.
1.1
Aufgabenstellung
Aufgabe der Studienarbeit ist die Erstellung eines Reservoir Modells der Subsalinarschichten für die
subherzyne Mulde mit dem geologischen Modellierungsprogramm Gocad. Danach erfolgt der Export
des Reservoir Modells aus dem Modellierungsprogramm Gocad in das Modellierungsprogramm Petrel
zur späteren Benutzung durch die Simulationssoftware ECLIPSE. Ist der Export mit den Gocad-eigenen
Möglichkeiten nicht erfolgreich, müssen gegebenenfalls externe Export- oder Konvertierungsmöglichkeiten
implementiert werden.
Die Aufgabe gliedert sich in folgende Teilbereiche:
• Erstellung der räumlichen Körper der Subsalinarschichten als Versenkreservoir und der Salinarschichten als hangende Deckschichten,
• Implementierung reservoirmechanisch wirksamer Gesteinseigenschaften,
• Überführung des geologischen Modells aus Gocad in das Modellierungsprogramm Petrel.
Die Erarbeitung des Modells erfolgt an der TU Bergakademie Freiberg, die Betreuung hinsichtlich der
geologischen Fragestellungen bei DBI-GUT (Deutsches Brennstoffinstitut - Gas- und Umwelttechnik).
1.2
Ziel
Folgende Ziele sollen in dieser Arbeit erreicht werden:
1. Erstellung des Modells inklusive Reservoir-Parametern
2. Analyse der Exportmöglichkeiten von Gocad nach Petrel/ECLIPSE
3. Erstellung einer Dokumentation für den erfolgreichen Export von Gocad-Daten nach Petrel/ECLIPSE
2
2
2.1
Geologie
Geologie der zu modellierenden Schicht
Die zu modellierende Schicht liegt im Gebiet der subherzynen Mulde, welche sich südlich von Magdeburg
bis zum Nordrand des Harzes befindet. Das Gebiet erstreckt sich über 100 km Länge und ca. 50 km Breite
(Walter, 2007).
Aus dem beiliegenden Kartenmaterial „Verbreitung und Mächtigkeiten des sedimentären Rotliegenden“ 1
und „Isobathen der Zechsteinbasis (schematische Darstellung)“ 2 und externen Quellen lassen sich nachfolgende Aussagen über die Geologie des zu betrachtenden Gebiets und der zu modellierenden Schichten
treffen.
Geologisch wird das Gebiet der subherzynen Mulde im Norden durch die Flechtinger-Roßlauer Scholle
und im Süden durch das Harzmassiv begrenzt. Als östliche Begrenzung werden die Halle-Hettstedter
Gebirgsbrücke und der Paschlebener Grauwackenvorsprung angesehen. Die Oberharz-Schwelle wird als
westliche Begrenzung der subherzynen Mulde genannt, obwohl sie sich nicht eindeutig als geologische
Grenze identifizieren lässt. Laut Aussage von DBI-GUT führen hier stark abnehmende Mächtigkeiten
und veränderte Gesteinsparameter dazu, dass sich die betreffende Schicht nicht mehr als Speicherhorizont eignet und somit nicht mit modelliert werden soll.
Bei der zu modellierenden Schicht handelt es sich um sedimentäres Rotliegendes, vornehmlich um Sandstein und Konglomerate (Henning und Katzung, 2002; Patzelt, 2003) , das vor etwa 298-255 Millionen
Jahren entstanden ist. Sie befindet sich im Liegenden von salinarem Zechstein, bestehend aus verschiedenen geschichteten Sedimenten (Henning und Katzung, 2002; Patzelt, 2003; Mohr, 1993) , welche vor ca.
255-250 Millionen Jahren abgelagert wurden. Im Liegenden der betrachteten Rotliegend-Schicht befindet
sich eine Schicht, welche als Altpaläozoikum bezeichnet wird und älter als 300 Millionen Jahre ist. Das
Alter der o.g. Schichten wurden der geologischen Zeitskala aus „Einführung in die Geologie Deutschlands“
(Henning und Katzung, 2002) entnommen. Im Norden des zu betrachtenden Gebietes streicht das Rotliegende, bedingt durch die Flechtinger-Roßlauer Scholle, an der Erdoberfläche aus. In Richtung Süden
fällt die Schicht bis auf 2500 m Tiefe ab und wird dort von der Harznordrandstörung begrenzt. Die sedimentären Mächtigkeiten des Rotliegenden betragen zwischen 0 m und bis über 600 m.
Die zu modellierende Schicht ist über das gesamte Gebiet gestört. Die Störungen streichen größtenteils
nach NW/SE. Dabei tritt Versatz von bis zu mehreren hundert Metern auf.
Im Liegenden des sedimentären Rotliegenden befindet sich über weite Gebiete des zu modellierenden
Areals effusiv geprägtes Rotliegendes. Dieses stellt damit einen Teil der gesamten Rotliegendmächtigkeit.
Das zu betrachtende sedimentäre Rotliegende wird, vor allem im süd-westlichen Teil des Untersuchungsgebiets, von dem effusiven Rotliegenden (Henning und Katzung, 2002; Patzelt, 2003 ) komplett abgelöst.
2.2
Notwendige Abweichungen des Modells von der realen Geologie
Das geplante Modell soll nach der Portierung nach Petrel für eine Strömungssimulation in ECLIPSE
benutzt werden, um die Aufnahmefähigkeit der zu modellierenden Schicht für zu verpressende salzhaltige
Lösungen zu testen. Um diese Strömungssimulation erfolgreich durchführen zu können, müssen bei der
Modellierung einige Abweichungen von der realen Geologie beachtet werden.
Die effusiven Mächtigkeiten der realen Schicht sind aufgrund ihrer Gesteinsparameter nicht als Speichermedium interessant und sollen demzufolge nicht modelliert werden. Zudem wird davon ausgegangen, dass
nur etwa ein Drittel der sedimentären Mächtigkeit als Speicherhorizont in Frage kommt. Laut Aussage
von DBI-GUT ist die für diese Modellierung interessante Schicht nur auf einem Teil ihrer Mächtigkeit so
stark geklüftet, dass sie dort als Speicherhorizont genutzt werden kann. Diese geklüfteten Teilmächtigkeiten werden für die spätere Simulation zu einen Drittel der Gesamtmächtigkeit zusammengefasst. Deshalb
wird im Folgenden nur mit einem Drittel der realen Mächtigkeitsangaben modelliert.
Da ECLIPSE für die geplante Simulation zusätzlich zur gewünschten Speicherschicht noch undurchlässige Deck- und Grundschichten benötigt, ist es notwendig, auch diese zu modellieren. Dazu werden
weitere Schichten mit 100 m Mächtigkeit und veränderten Parametern über und unter dem eigentlichen
Speicherhorizont erstellt und diese dann mit dem Modell der Speicherschicht zu einem Gesamtmodell
zusammengefügt.
1 Karte „Verbreitung und Mächtigkeiten des sedimentären Rotliegenden“ nach A. SCHREIBER 1960(Nord-Osten) und
HOYNINGEN-HUENE 1966(Gebiete südlich des Harzes) liegt als digitale Version „Übersicht Verbr. Mächtk. Rotliegendes.JPG"bei’
2 Karte: „Isobathen der Zechsteinbasis (schematische Darstellung)“ nach LUGE (Süd-Osten) liegt als digitale Version
„TeufeZechsteinbasis.jpg“ bei
3
Name des Objekts
Grenze2
(Grenzen des Modellierungsgebietes)
Teufe_Iso
(Isolinien der Teufe der Zechsteinbasis)
faults
(Störungen durch das Gebiet)
Maechtigkeit
(Punktdaten der Rotliegendmächtigkeit)
shape-Typ
Polylinie
Eigenschaft
-
Polylinie
Teufe: Abstand zur
Erdoberfläche in m
-
Polylinie
Punkt
thickness:
Mächtigkeit in m
Tabelle 1: in ArcGIS digitalisierte Rohdaten
Um den Export von Gesteinsparametern validieren zu können, wird vorerst nur eine Gesteinseigenschaft,
die Porosität, modelliert und mit konstanten Werten belegt. Der Speicherbereich besitzt die Porosität
0.5, während die undurchlässigen Grenzschichten mit dem Wert 0.0 erstellt werden. Die Werte wurden
empirisch gewählt, da sie die gewünschten Eigenschaften gut repräsentieren und nach der Portierung gut
zu überprüfen sind.
Um die Komplexität des zu exportierenden Modells so gering wie möglich zu halten, wird auf die Modellierung der die Schicht durchziehenden Störungen in diesem Ansatz verzichtet.
3
Modellerstellung mittels ArcGIS und Gocad
3.1
Eingangsdatenlage
Als Eingangsdaten für die Modellierung liegen drei eingescannte Rasterkarten vor. Die Karten „Isobathen
der Zechsteinbasis (schematische Darstellung)“ und „Teufenlage Bernburg Nord“ 3 beinhalten die zur Modellierung des oberen Horizontes notwendigen Isolinien für die Teufe der Zechsteinbasis, sowie die lokale
Störungslage. Die Mächtigkeiten der zu modellierenden Schicht und deren räumliche Ausdehnung können
der Karte „Verbreitung und Mächtigkeiten des sedimentären Rotliegenden“ entnommen werden.
Als ersten Schritt zur Erzeugung der Rohdaten werden die Rasterkarten in ArcGIS mittels auf den
Karten vorhandener Koordinaten und externer Vektordaten der Gewässer und Bundesländergrenzen in
Gauß-Krüger-Koordinaten georeferenziert. Danach werden die notwendigen Daten in separate Shapefiles
digitalisiert (Tabelle 1), welche dann wiederum in Gocad importiert werden können (Abbildung 1).
Zusätzlich zu den digitalisierten Punktdaten der Mächtigkeit aus der Karte „Verbreitung und Mächtigkeiten des sedimentären Rotliegenden“ werden in den Bereichen, wo nur noch effusive Mächtigkeiten
vorherrschen, künstlich Punktdaten mit Mächtigkeit 0 m erzeugt, um dort bei der späteren Modellierung
eine Mächtigkeit von 0 m zu erzwingen.
3.2
Verarbeitung der Rohdaten zu den zu modellierenden Horizonten
Nach dem Import der Shapefiles, welche die o.g. digitalisierten Rohdaten enthalten, in Gocad liegen
die Daten mit Koordinate Z = 0 vor. Zum Erstellen des ersten Horizonts werden aber die Isolinien
der Rotliegendteufe (Gocad-Objekt: Teufe_Iso)4 als dreidimensionale Isolinien benötigt. Hierzu wird die
Z-Koordinate der Isolinien mit dem Wert belegt, welcher in ArcGIS im Parameter Teufe gespeichert
wurde.5
T euf e_IsoZ = T euf e_IsoT euf e
Anschließend wird mittels der Polylinie der Gebietsgrenze (Gocad-Objekt: Grenze2) und den Isolinien der Teufe der obere Horizont (Gocad-Objekt: DBI_Speicher_oben), also die obere Begrenzung des
sedimentären Rotliegenden, modelliert. Dazu wird als erster Modellierungsschritt der Objectcage der
beteiligten Gocad-Objekte erstellt. Ein Objectcage kann als oriented-bounding-box der umschlossenen
Gocad-Objekte angesehen werden. Eine genauere Betrachtung des Objectcages erfolgt in Abschnitt 3.3.
3 Karte
wurde von DBI-GUT bereitgestellt und liegt als digitale Version „Teufelage Bernburg Nord.jpg“ bei
und alle nachfolgend benannten Gocad-Objekte beziehen sich auf das beiliegende Gocad-Projekt subherzyn1311_final.gprj
5 Die Benennung der einzelnen Variablen erfolgt nach folgendem Muster: (GocadObjekt)
P arametername
4 dieses
4
Abbildung 1: in Gocad importierte Rohdaten: Punktdaten der Rotliegend-Mächtigkeit (Kreuze), Grenze
des Modellierungsgebietes (weiße Linie), Störungen (rote Linien), Isolinien der Rotliegend-Teufe (kolorierte Isolinien)
Anhand dieser bounding-box und der Isolinien wird als erster Lösungsansatz die Surface dieses Horizonts als „Object-Medium-Plane“ der Isolinien erzeugt. Dabei tritt als Problem auf, dass die erzeugte
Surface sich nicht über den gesamten Objectcage erstreckt. Es fehlen die Teile der Fläche, in denen die ZKoordinaten der „Object-Medium-Plane“, getrieben durch die gegebenen Daten, nicht mehr in den durch
die bounding-box definierten Koordinatengrenzen liegen. Es stellte sich später heraus, dass Gocad die
Erstellung einer „Object-Medium-Plane“ außerhalb der angegebenen Begrenzungen verhindert. Dies kann
durch eine Z-Skalierung des Objectcages behoben werden. Danach werden die Border-Constrains gesetzt
und die Punkte der Isolinien erst als Control-Points6 und dann als Control-Nodes7 definiert. Dies führt
allerdings zum „Zerreißen“ der Surface, d.h. zum Fehlen von Dreiecken innerhalb der Surface. Es ist zu
vermuten, dass dieser Fehler an z.T. hohem Versatz in Z-Richtung zwischen räumlich(in XY-Richtung)
nahen Punkten liegt. Als eine weitere Ursache kann angenommen werden, dass die Triangulationspunkte8 nicht den Datenpunkten entsprechen. Auch eine grobe globale Vortriangulation der Surface mittels
„Splitt->All“ und „Beautify->Beautify Triangles for Equilaterality“ verhindert das „Zerreißen“ nicht. Erst
eine sehr starke lokale Triangulation führt zu Verbesserungen, kann dass „Zerreißen“ jedoch nicht komplett beheben. Zudem repräsentiert diese starke Verfeinerung nicht mehr die vorhandene Datendichte.
Dieser erste Ansatz zur Erstellung des oberen Horizontes ist demzufolge für diese Daten nicht anwendbar.
In einem zweiten Ansatz zur Erstellung des oberen Horizontes wird direkt trianguliert. Dies hat zwei Vorteile: Zum einen kann die Surface innerhalb einer geschlossenen Curve mit dieser als äußere Begrenzung
erzeugt werden. Man kann also Surfaces bereits mit einer an die Daten angepassten Form erstellen und
6 bevorzugter
Zielpunkt für eine Interpolation. Er muss dabei aber nicht erreicht werden.
Zielpunk für eine Interpolation, der in die Triangulation nachträglich eingefügt wird und diese verändert.
Er darf durch eine spätere Interpolation nicht mehr verändert werden.
8 Gemeint sind Punkte, welche durch die Triangulation der Fläche entstanden sind. Sie repräsentieren nur die Geometrie
der Fläche, haben aber im Allgemeinen keinen Bezug zu den Daten.
7 erzwungener
5
muss diese nicht im Nachhinein modellieren. Des Weiteren werden die gegebenen Datenpunkte direkt als
Triangulationspunkte für die initiale Erzeugung der Surface benutzt. Als Curve wird die Polylinie der
Gebietsgrenze und als PointSet die Punkte der Isolinien der Teufe benutzt. Diese Gocad-Option bietet
einige Möglichkeiten zu Definition der nichtdatengetriebenen Triangulationspunkte. Diese reichen vom
ausschließlichen Benutzen der Datenpunkte über nur wenige Zwischenpunkte bis hin zur heuristischen
(algorithmengetriebenen) Triangulation mit z.T. sehr vielen nichtdatengetriebenen Punkten. Die besten
Ergebnisse werden mit der Option „few triangles“ erzielt, welche nur wenige Zwischenpunkte als Triangulationspunkte zur Surface hinzufügt. Die Anwendung dieser Option kommt vor allem Gebieten mit
geringem Datenbestand zu Gute. Des Weiteren muss darauf geachtet werden, dass die umgrenzende Polylinie nicht zu viele Knoten besitzt. Dies beeinflusst die Triangulation ungünstig, da alle Punkte der
Polylinie als Daten für die Triangulation genutzt werden. Entspricht also die Knotendicht der Polylinie
nicht in etwa der Datendichte des benutzten PointSets, kommt es in allen Randgebieten der Surface zu
einer ungewollt starken Verdichtung der Triangulation.
Danach werden wieder wie im 1. Ansatz die Border-Constrains für die Surface gesetzt und die TeufeIsolinien als Control-Points/Control-Nodes der Fläche definiert. Da nun die Datenpunkte definitiv auch
Triangulationspunkte sind, kommt es diesmal nicht zum „Zerreißen“ der modellierten Surface. Im Anschluss wird solange DSI9 auf die Surface des oberen Horizonts angewendet, bis keine Verbesserung der
Triangulation mehr erreicht werden kann.
Im Anschluss an die Erstellung des oberen Horizonts wird nun mit der Modellierung des unteren Horizonts (Gocad-Objekt: DBI_Speicher_unten), also der Rotliegendbasis, begonnen. Dazu werden die zur
Zeit noch zweidimensionalen Punktdaten der Rotliegendmächtigkeit vertikal auf den oberen Horizont
projiziert. Gocad bietet dafür die Option „transfer Property: By Vertical Projection“.
M aechtigkeitZ = DBI_Stauer_obenZ
Als nächster Schritt werden die projizierten Punktdaten um den thickness-Wert in Z-Richtung verschoben,
um die Stützpunkte für die Interpolation des unteren Horizonts zu erhalten. Dabei muss beachtet werden,
dass bei dieser Modellierung mit positiver Tiefenrichtung gearbeitet wurde, das heißt, die Richtung der
Z-Koordinate zeigt zum Erdmittelpunkt. Weiterhin wird nur ein Drittel der realen Mächtigkeit modelliert
(siehe Abschnitt 2.2).
M aechtigkeitZ = M aechtigkeitZ + (1/3) ∗ M aechtigkeitthickness
Nun können diese projizierten und verschobenen Punktdaten als Daten für die Modellierung des zweiten
Horizonts benutzt werden. Bei der Erstellung dieser Surface wird genauso vorgegangen, wie bei der der
oberen Surface. Diese Vorgehensweise führt jedoch dazu, dass nach der Erstellung weite Bereiche der
unteren Fläche über dem oberen Horizont liegen. Also Ursache dafür kann sowohl die z.T. sehr geringe
Datendichte der Punktdaten für die Mächtigkeit als auch auf die im Vergleich zur räumlichen Ausdehnung
des Gebietes sehr geringen Mächtigkeitswerte angeführt werden. Zudem sind die Daten sehr unregelmäßig
über das zu modellierende Gebiet verteilt. Die von Gocad erzeugte Triangulation der unteren Surface ist
aufgrund der o.g. Dateneigenschaften sehr viel gröber als die des oberen Horizonts. Auch die nachträgliche
Verwendung der Option „remove crossovers“ führt nicht zu den gewünschten Ergebnissen. Zwar befinden sich die Knoten der Fläche jetzt unterhalb der oberen Fläche, aber das Innere vieler Dreiecke liegt
dennoch über der Deckfläche. Auch globale und lokale Verfeinerungen der Triangulation verbesserte das
Ergebnis nur unwesentlich. Man müsste die Dreiecksvermaschung unverhältnismäßig stark verfeinern, um
brauchbare Ergebnisse erzielen zu können.
Eine mögliche Lösung für dieses Problem besteht darin, die gleich Dreiecksvermaschung für die zweite
Surface zu benutzen, mit der auch schon der obere Horizont trianguliert wurde. Dazu wird die obere
Surface ohne Constrains kopiert. Die Border-Constrains werden neu gesetzt und die neuen Datenpunkte
erst als Control-Points und dann als Control-Nodes definiert. Die räumliche Verteilung der Punktdaten
verhindert in diesem Fall das „Zerreißen“ der modellierten Fläche. Durch Verwendung der Option „remove
crossovers“ mit globaler und lokaler DSI und das Hinzufügen einiger weniger zusätzlicher Triangulationspunkte kann die untere Surface so interpoliert werden, dass sie global unter dem oberen Horizont liegt.
9 discrete
smooth interpolation: von Gocad benutztes Verfahren zur Interpolation
6
3.3
Erstellung des SGrids mit unregelmäßiger Form
Gocad initialisiert die äußeren Grenzen eines SGrids bei dessen Erstellung über eine Objectbox10 oder
einen Objectcage11 . Objectbox und Objectcage sind dabei selbst Gocad-Objekte und stellen faktische eine
axis-aligned-bounding-box (Objectbox) oder eine oriented-bounding-box (Objectcage) über eine definierte Menge an vorhandenen Gocad-Objekten dar und werden von Gocad als so genannte Voxets erstellt,
da in Gocad keine eigene Objekt-Klasse bounding-box existiert.
Ein Voxet ist ein reguläres Gitter, welches aus einer definierten Anzahl von Volumenelementen besteht,
welche als Voxel oder Cells bezeichnet werden. Die Zellen eines Voxets sind parallel zu den Achsen des
Voxets angeordnet. Diese Achsen müssen weder orthogonal zueinander noch gleich lang sein. Jede dieser
drei Achsen ist definiert durch ihren Ursprung und ihren Endpunkt, wobei der Ursprung aller drei Achse
derselbe Punkt ist. Für jede Achse werden zusätzlich die Anzahl der Knoten auf dieser Achse und ein
so genannter step-Vektor definiert. Der step-Vektor ist der Vektor von aktuellen Knoten auf der Achse
zu nächsten Knoten auf der Achse und ist konstant auf der zugehörigen Achse. Sein Betrag stellt damit
die Länge jeder Zellen in dieser Achse dar. Demzufolge gilt, dass alle Zelle auf der jeweiligen Achse die
gleiche Ausdehnung haben. Da dies für jede der drei Achsen gilt, sind alle Zellen immer gleich groß.
Sind für ein Voxet Eigenschaften definiert, ist in jeder Zelle der Werte jeder Eigenschaft im Zentrum der
Zelle, also zellenzentriert, gespeichert.12
Für Objectbox und Objectcage gilt speziell, dass beide nur eine Zelle besitzen, welche sich über die gesamte Ausdehnung des Voxets erstreckt. Die Achsen der Objectbox sind dabei immer parallel zu den
globalen Koordinatenachsen. Dies ist beim Objectcage nicht notwendigerweise der Fall.
Wird ein SGrid von Gocad erzeugt, so besitzt es die selben geometrischen Komponenten wie ein Voxet,
also Ursprung, Achsen, Anzahl der Knoten pro Achse und für jede Zelle einen step-Vektor für jede Achse. Im Gegensatz zum Voxet muss aber in einem SGrid eine definierte Eigenschaft nicht zellenzentriert
gespeichert werden. Alternativ dazu können Eigenschaftswerte in den Eckpunkten der Zellen gespeichert
werden. Welche der beiden Möglichkeiten genutzt wird, entscheidet der Anwender bei der Erstellung des
SGrid. Beiden Varianten schließen sich gegenseitig aus, es kann also für ein und dasselbe SGrid nur eine
der beiden Möglichkeiten aktiv sein.
Ein weitere Unterschied zwischen Voxet und SGrid besteht darin, dass ein SGrid deformiert werden
kann, indem man es an eine oder mehrere Kontrollflächen anpasst. Durch diese Anpassung werden die
Zellen des SGrids deformiert, also in Form und Orientierung verändert, in dem für jede Zelle separat die
step-Vektoren an die neue Geometrie angepasst werden. Dies ermöglicht die Erzeugung ungleichförmiger
Gitterzellen, was eine besser Anpassung an komplizierte Geometrien ermöglicht.13
Im weiteren Verlauf dieser Arbeit werden SGrids, bei denen keine Zellen nachträglich entfernt wurden,
als SGrids mit regelmäßiger Form bezeichnet. SGrids, bei denen nachträglich Zellen aus der initialisierten
Geometrie entfernt wurden, werden als SGrids mit unregelmäßiger Form bezeichnet. Das Entfernen von
nicht benötigten Zellen kann zur nachträglichen Formanpassung des SGrids genutzt werden, es können
so auch Löcher in einem SGrid erzeugt werden.
Um die drei betreffenden Schichten, also die Speicherschicht und die beiden Grenzschichten, als SGrids
modellieren zu können, müssen noch zwei Hilfsflächen erstellt werden. Dazu wird der obere Horizont
kopiert und die Kopie 100 m nach oben verschoben. Analog wird mit der unteren Schicht verfahren, nur
dass die kopierte Fläche 100 m nach unten verschoben wird. Nun liegen vier übereinander liegende Surfaces vor, anhand derer die drei gewünschten Schichten erzeugt werden können. Zuerst müssen für jedes
SGrid die Objekte definiert werden, in deren bounding-box sich das SGrid befinden soll. Danach kann
die Geometrie des SGrids durch Angabe der oberen und unteren Grenzhorizonts initialisiert werden. Als
Auflösung für alle drei Schichten wurde 500x500x1 Zellen gewählt. Die hohe Auflösung in X-Y-Richtung
war notwendig, damit die SGrids die z.T. stark differenzierten Surfaces gut abbilden können.
Diese SGrids wurden anhand der angegebenen Surfaces erzeugt (angegeben ist immer erst die obere
Surface und dann die Untere):
1. sg_dbi_Speicher: dbi_speicher_oben und dbi_speicher_unten
2. sg_stauer_o: dbi_stauer_oben und dbi_Speicher_oben
3. sg_stauer_u: dbi_speicher_unten und dbi_stauer_unten
10 Achsen
parallel zu den globalen Koordinatenachsen
parallel zu den sich aus den beteiligten Objekten ergebenden Hauptachsen, keine Orientierung an den globalen
Koordinatenachsen
12 Die Eigenschaften eines Voxets wurde der Gocad-Online-Hilfe entnommen.
13 Die Eigenschaften eines SGrids wurde der Gocad-Online-Hilfe entnommen.
11 Achsen
7
Nach der Erstellung der SGrid-Geometrien wurde bei allen SGrids eine neue property mit der Bezeichnung „Porosität“ definiert und mit den im Abschnitt 2.2 genannten Werten belegt.
Die derzeit erstellten Modelle der Schichten besitzen noch eine regelmäßige Form, das heißt, ihre äußeren
Abmessungen in der x- und y-Koordinate entsprechen der bounding-box der zur Modellierung benutzten
Objekte (weiße Gebiete in Abbildung 2). Um die unregelmäßige Form der SGrids modellieren zu können,
muss eine Grenzsurface erstellt werden, mit der man dann die SGrids verschneiden kann. Diese Grenzfläche wird aus zwei Kopien der Grenzpolylinie erstellt, welche so verschoben werden, dass eine Kopie
komplett über den drei Schichten liegt und eine komplett darunter. Mittels der Option „Create Surface
From Two Curve Parts“ lässt sich aus diesen beiden geschlossenen Kurven eine senkrechte geschlossene
Fläche erzeugen. Danach können alle drei SGrids mittels der Option „cut with surfaces“ und Angabe
der Grenzfläche mit dieser verschnitten werden. Jedes SGrid wird dabei in Regionen unterteilt, welche
entweder komplett innerhalb der Grenzfläche liegen, oder komplett außerhalb.
Die Zellen der Regionen, die nicht erwünscht sind, das sind die, welche komplett außerhalb der Grenzfläche liegen, kann man im regions-Menü unter der Option „Set Region Dead“ als dead cells definieren.
Das hat zur Folge, dass sie aus der initialisierten Geometrie des betreffenden SGrids entfernt werden und
nur noch die komplett innerhalb der Grenzfläche liegende Geometrie beibehalten wird (rote Gebiete in
Abbildung 2). Alle drei so veränderten SGrids werden ohne ihre Regionen in neue SGrids kopiert, um
alle Regionen zu entfernen, aber die originalen SGrids mit ihren Regionen bei zu behalten. Alle nachfolgenden Operationen werden mit diesen Kopien durchgeführt. Auf die drei SGrids wird die Option „merge
SGrids“ angewendet, die sie zu einem neuen SGrid zusammen fasst. Dieses neue SGrid beinhaltet jetzt
keine Regionen mehr, da diese bereits aus den Einzelsgrids entfernt wurden. Das dadurch entstandene
SGrid (Gocad-Objekt: corr_complete) wird für den anschließenden Datenexport benutzt.
Zusammenfassung Für die Erstellung eines SGrids mit unregelmäßigerer Form sind folgende Schritte
notwendig:
1. Erstellen des regelmäßigen SGrids und Initialisieren der Geometrie
2. Erstellen der Grenzfläche und Verschneiden des SGrids mit dieser. Dadurch erhält man die verschiedenen Regionen im SGrid.
3. Für die weitere Arbeit empfiehlt es sich, das ursprüngliche SGrid unverändert beizubehalten und
nur mit Kopien zu arbeiten.
4. Die Zellen der Regionen, deren Geometrie man entfernen möchte, mittels der Option „Set Region
Dead“ als tote Zellen (dead cells) definieren.
Um die verschiedenen Regionen im SGrid zu erhalten, muss Schritt 2 nicht notwendigerweise wie oben
genannt durchgeführt werden. Es gibt verschiedene Möglichkeiten, Regionen zu erhalten. Zum Beispiel
kann man Regionen anhand von Parameterintervallen für eine vorher implementierte property definieren.
8
Abbildung 2: regelmäßige Ausdehnung des erzeugten SGrids (weiß) und die durch die Grenzsurface (gelb)
umrandete Ausdehnung des unregelmäßig geformten SGrids (rot)
4
4.1
Export des Gocad-SGrid-Modells
Exportmöglichkeiten von Gocad nach Petrel
Das im Abschnitt 3 erstellte Modell soll in einem Softwaresystem bestehend aus der Modellierungssoftware Petrel und der Simulationssoftware ECLIPSE für eine Strömungssimulation genutzt werden und
muss dazu nach Petrel exportiert werden. Gocad beinhaltet keine direkte Exportmöglichkeit für Petrel,
kann aber nach ECLIPSE und in verschiedene ASCII- und binär-Formate anderer Software-Standards
(siehe Tabelle 2) exportieren. Des Weiteren ist bekannt, dass Petrel sehr viele Importmöglichkeiten hat
(siehe A.3). Diese betreffen verschiedenste ASCII- und binär-Formate anderer Softwaresysteme, allerdings
nicht Gocad. Aus diesem Grund werden im Folgenden die von Gocad bereitgestellten Exportoptionen für
ihre Tauglichkeit für den Import nach Petrel untersucht. Eine Beschreibung des Exportvorgangs nach
Petrel und des Imports der Daten in Petrel erfolgt in Abschnitt A.1.
4.2
Generelle Problematik beim Export/Import
Nicht alle von Gocad unterstützten Exportformate für SGrids werden von Petrel für den Import unterstützt. Zusätzlich treten weitere generelle Probleme beim Export/Import von Gocad nach Petrel auf.
Verlust der unregelmäßigen Gestalt des SGrids
Beim Export aus Gocad kann die unregelmäßige äußere Form des exportierten SGrids verloren gehen.
Gocad exportiert Zellen, die vorher als „dead cells„ definiert wurden, als normale Zellen des SGrids.
Vermutlich liegt das daran, dass „dead cells“ immer noch in der SGrid-Geometrie vorhanden sind und nur
nicht mehr grafisch dargestellt werden. Die Exportformate unterstützen die Eigenschaft „dead cell“ nicht
notwendigerweise, was dazu führen kann, dass diese Zellen zwar exportiert werden, aber ihre Eigenschaft
9
Exportformat
CMG
ECLIPSE
RESCUE
VIP
AVF
Datenformat
ASCII
ASCII/binär
ASCII/binär
ASCII
ASCII
VELF
ASCII
Temis3D
MSExcel
ASCII
binär
zugehörige Software
keine, file-Format für für Export von 3d-Grids
Simulationssoftware ECLIPSE
Rescue
VIP
keine, file-Format für Export von Geschwindigkeitsdaten
keine, file-Format für Export von Geschwindigkeitsdaten
Temis3D
Microsoft Excel
Tabelle 2: Von Gocad bereitgestellte Exportformate für SGrids, die zugehörige Software wurde der GocadOnline-Hilfe entnommen
als „dead cell“ beim Export verlieren.
Um den Export dieser Zellen zu erleichtern, kann man kann bei bestimmten Exportformaten (z.B. CMG,
ECLIPSE-ASCII, ECLIPSE-binär u.a.) eine gesonderte Behandlung von als „dead cell“ definierten Zellen
angeben.
Veränderte Datenformate und damit einhergehende veränderte Datenmengen
Man kann Gocad-SGrids als ein nur für Gocad lesbares Format speichern, um z.B. den Transport zwischen verschiedenen Gocad-Projekten zu erleichtern. Dieses Format besteht aus einer ASCII-Datei und
mehreren binären Dateien, welche nur Gocad verarbeiten kann. Dieses Gocad-spezifische Format ist für
den Export in andere Systeme ungeeignet, da man nicht davon ausgehen kann, dass andere Systeme die
Gocad-internen Verfahren zur Verarbeitung dieser Dateien kennen und benutzen. Für die Portierung in
andere Software sind reine ASCII-Formate oder binär-Formate, deren Verarbeitungsalgorithmen „open
source“ 14 verfügbar sind, am geeignetsten. ASCII-Dateien haben zudem den Vorteil, dass man sie auch
mit einfachen Texteditoren lesen und bearbeiten kann.
Die Erfahrung zeigt, dass reine ASCII-Files meist eine erheblich höhere Datenmenge produzieren als vergleichbare binär-Files. In Bezug auf die von Gocad angebotenen Exportformate für SGrids lässt sich diese
Erfahrung nur bedingt anwenden, was auf die zum Teil erheblich unterschiedliche Komplexität der einzelnen Exportformate zurück zuführen ist. Vor allem beim Export in die ECLIPSE-Formate kann man davon
ausgehen, dass die interne Struktur der ASCII- und binär-Dateien auf unterschiedlichen Philosophien beruht. Diese Vermutung wird dadurch bestärkt, dass Gocad für die beiden Varianten unterschiedliche
Export-Plugins benutzt, obwohl die Zielplattform die gleiche ist. Beim RESCUE-Format ist dies nicht
der Fall. Nach Temis3D wird zwar auch der binäre Export angeboten, allerdings unterstützt Gocad dies
unter Windows nicht und der Export wird mit einer Fehlermeldung abgebrochen.
Mit wenigen Ausnahmen exportiert jedes von Gocad bereitgestellte Exportplugin das SGrid in eine feste,
vom SGrid unabhängige, Anzahl von Dateien. Die Plugins für CMG, ECLIPSE-ASCII und VIP bieten
die Möglichkeit, alle Daten in eine Datei oder in mehrere separate Dateien zu exportieren. Beim Export in mehrere Dateien wird zusätzlich zu der Datei mit den Geometrie-Informationen noch für jede
exportierte property eine Datei erstellt. Zum Teil wird zusätzlich noch eine weitere Datei mit den Daten
für eventuelle „dead cells“ erstellt. Diese wird immer dann erstellt, wenn beim Export eine gesonderte
Behandlung dieser Zellen erzwungen wird. In Tabelle 3 sind die einzelnen Datenformate und -mengen
der Exportvarianten für das in Abschnitt 3 erzeugte SGrid im Vergleich zum Gocad spezifischen Format
aufgeführt.
Veränderte Koordinatenachsenrichtungen
Generell ist bei der Portierung zwischen unterschiedlicher Modellierungs- und Simulationssoftware immer
zu bedenken, dass es zu einem Wechsel zwischen unterschiedlichen Koordinatensystemen kommen kann.
Hinter jedem dieser Programme steckt eine eigene Philosophie, was die intern benutzten Koordinatensysteme betrifft. Häufig werden links- oder rechtshändige Koordinatensysteme benutzt, zusätzlich kann noch
die Richtung der Z-Koordinate je nach Anwendung unterschiedlich sein. Dies kann beim Import in diese
anderen Programme zu veränderten Koordinatenachsenrichtungen und damit zu einer Spiegelung des
14 öffentlich
zugänglicher Quellcode
10
Exportformat
sg (Gocad spezifisch)
CMG
ECLIPSE-ASCII
ECLIPSE-binär
RESCUE(ASCII)
RESCUE(binär)
VIP
AVF
VELF
Temis3D
MSExcel
max. Anzahl erstellter Dateien
6
2 + nP
2 + nP
2
8
8
1 + nP
1
1
> 10(SGrid abhängig)
1
Datenformat
ASCII/binär
ASCII
ASCII
binär
ASCII
binär
ASCII
ASCII
ASCII
ASCII
binär
Datengröße in MB
22.7
117
116
133
35
13
260
56.9
26.1
12
47.3
Tabelle 3: Veränderte Datenformate und -mengen der Gocad-Exportformate im Vergleich zum Gocadspezifischen Format für den SGrid-Export am Beispiel des in dieser Arbeit exportierten SGrids. nP gibt
die Anzahl der zum Export angegebenen properties an.
Modells an den betreffenden Achsen führen. Auch kann das Import-Programm die bei der Modellierung
zugrunde liegenden Koordinatensysteme nicht in jedem Fall erkennen.
Viele Gocad-Exportplugins für SGrids bieten deswegen die Möglichkeit, die Koordinatenrichtungen beim
Export zu vertauschen. Das Anwenden dieser Optionen ist natürlich erst dann sinnvoll, wenn man die
speziellen diesbezüglichen Probleme eines differenzierten Export/Import-Vorgangs kennt und dementsprechend validiert.
4.3
Import der exportierten Daten in Petrel
Die von beiden Systemen, also von Gocad und Petrel, unterstützten Formate für 3d-Grids umfassen nur
einige der von beiden Programmen unterstützten Export-/Importformate. Folgende Formate werden von
beiden Softwaresystemen unterstützt (auch ersichtlich in Anhang A.3):
• CMG
• ECLIPSE(ASCII)
• ECLIPSE(binär)
• Rescue(ASCII/binär)
• VIP
Da bei DBI-GUT bereits mit einem Petrel/ECLIPSE-System gearbeitet wird, überrascht die Unterstützung der ECLIPSE-Formate nicht. Auch die Unterstützung des CMG-Formates verwundert nicht, da es
sich hierbei um ein reines ASCII-Format für 3d-Grids handelt, welches nicht an eine Software gebunden
ist. Dass auch die Formate von externen Softwaresystemen wie Rescue und VIP von den beiden in dieser
Arbeit benutzten Programmen unterstützt werden, kann auf die weite Verbreitung dieser Software und
auf eventuelle Kooperationen der beteiligten Firmen zurückgeführt werden.
Nicht bei allen dieser Formate konnte jedoch ein erfolgreicher Import der in dieser Arbeit erstellten Daten
in Petrel erreicht werden. Dies betrifft die Formate VIP und ECLIPSE(binär). Das Gocad-Plugin für den
VIP-Export erstellt nicht alle der für den VIP-Import in Petrel notwendigen Keywords im exportierten
File. Dies kann eventuell manuell nach gearbeitet werden, da es sich um ein reines ASCII-File handelt.
Warum das ECLIPSE(binär)-Format nicht erfolgreich importiert werden konnte, kann aufgrund der binären Formatierung der erstellten Files nicht exakt nachvollzogen werden. Als wahrscheinlichste Ursache
dafür kann ein inkompatibler Versionsunterschied zwischen den exportierten Dateien und den für den
Import benötigten Dateien angenommen werden. Binäre Formate sind für diese Inkompatibilitäten anfälliger als ASCII-Formate, bei denen der Unterschied schnell erkennbar ist und möglicherweise manuell
behoben werden kann.
Bei den Formaten CMG, ECLIPSE(ASCII) und Rescue(ASCII/binär) konnte ein erfolgreicher Import in
Petrel durchgeführt werden. Dabei lassen sich einige Vorteile von Petrel als Importplattform feststellen.
Zum einen erkennt Petrel die in den in Abschnitt 3 erstellten Daten nach unten gerichtete z-Achse und
passt die internen Voreinstellungen automatisch an. Des Weiteren ist Petrel in der Lage, das importierte
11
Exportformat
CMG
ECLIPSE(ASCII)
Rescue(ASCII/binär)
ECLIPSE(binär)
VIP
Vorteile
Nachteile
seperable z-Zonen; reines ASCII- nur regelmäßige Form des SGrids; große
Format
Datenmenge
unregelmäßige Form des SGrids; sepe- große Datenmenge
rable z-Zonen; reines ASCII-Format
unregelmäßige Form des SGrids; gerin- keine seperablen z-Zonen
ge Datenmenge
kein erfolgreicher Import
kein erfolgreicher Import
Tabelle 4: Vor und Nachteile der für den Import in Petrel unterstützte Gocad-Exportformate
Modell anhand der gegebenen Parameter in verschiedene Zonen auf der z-Achse zu separieren, obwohl das
Modell zuvor als eine Einheit exportiert worden ist. Damit konnte eine erneute exakte Trennung der drei
in Gocad modellierten Schichten in Petrel erreicht werden. Nur bei den im Rescue-Format exportierten
Daten war dies nicht automatisch möglich, konnte aber mit einigem Aufwand manuell erreicht werden.
Für den Rescue-Export empfiehlt es sich demzufolge, möglichst nur separate Schichten zu exportieren
und diese dann in Petrel zu importieren.
Außer beim CMG-Format übernimmt Petrel zusätzlich noch die in Gocad erzeugte unregelmäßige Form
des Modells aus den importierten Daten. Zwar konnte beim Export in das CMG-Format, ähnlich wie
bei Export in das ECLIPSE(ASCII)-Format, eine gesonderte Behandlung der als „dead cells“ definierten
Zellen erzwungen werden, doch scheint Petrel dies beim CMG-Format zu ignorieren. Das CMG-Format
eignet sich dem zufolge am Besten für den Export von SGrids mit regelmäßiger Form. Siehe dazu auch
Tabelle 4 und die Abbildungen 3 und 4.
Einige der unterstützten Exportformate bieten die Möglichkeit, die Daten in mehrere separate Dateien
zu speichern. Dies erhöht allerdings den Importaufwand erheblich. Erst müssen die Geometriedaten und
danach jede exportierte property einzeln importiert werden. Für einzelne Datensätze ist dieser zusätzliche Aufwand nicht notwendig, da die Daten auch im jeweiligen Einzelfile vorhanden sind und Petrel
diese sofort mit importiert. Für den Import nachträglich erstellter properties oder wenn man bei sehr
umfangreichen Datensätzen mit vielen properties nicht alle properties gleichzeitig importieren möchte,
ist der Export in mehrere Files jedoch sinnvoll.
Abbildung 3: In Petrel importierte CMG-Daten mit regelmäßiger Form.
12
Abbildung 4: In Petrel importierte Daten mit unregelmäßiger Form.
13
5
Fazit
Diese Arbeit zeigt, dass es auch ohne direkte Schnittstelle zwischen Gocad und Petrel möglich ist, komplexe Daten ohne Verluste aus Gocad zu exportieren und diese in Petrel zu importieren. Dies geschieht
über Gocad- und Petrel-fremde Datenformate, welche dennoch von beiden Softwaresystemen unterstützt
werden. Die zusätzliche Implementierung eines Gocad-Plugins für nach Petrel zu exportierende Daten
oder eines Exportfilekonvertierungstools waren für diesen Ansatz nicht notwendig.
Die in Abschnitt 3 modellierte sedimentäre Speicherschicht der subherzynen Mulde, wurde als ein SGrid
mit unregelmäßigerer Form und Reservoirparametern modelliert. Diese Daten wurden mittels der in
Gocad vorhandenen Exportplugins für SGrids exportiert. Davon konnten die Formate CMG, ECLIPSE(ASCII) und Rescue erfolgreich in Petrel importiert werden (Tabelle 4).
Für diese Daten hat sich das ECLIPSE(ASCII)-Format als das effektivste Exportformat erwiesen. Obwohl sich der Datenaufwand dadurch erhöht(Tabelle 3), liegen die in Gocad definierte unregelmäßige
äußere Form und die Reservoirparameter in Petrel nach dem Import wieder vor. Zusätzlich ist Petrel in
der Lage, die als eine Einheit exportierten Daten in drei so genannte z-Zonen zu unterteilen, welche den
drei initial in Gocad erstellten Einzelschichten entsprechen(Tabelle 4). Dies ist jedoch vermutlich nur bei
scharfen Parametergrenzen im Modell möglich.
Das für diese Arbeit effektivste Exportformat kann jedoch nicht als allgemein gültig angesehen werden.
Für andere Exportdaten können sich andere Exportformate als effektiv erweisen. Auch die Formate, für
die in dieser Arbeit kein erfolgreicher Petrelimport erreicht werden konnte, könnten bei anderer Datenlage
oder angepasstem Exportvorgang einen erfolgreichen Petrellimport erreichen. Die generelle Untauglichkeit für den Petrelimport kann in dieser Arbeit nicht belegt werden, da der Export nur an einem speziellen
Datensatz erprobt wurde. Aus diesem Grund bietet es sich an, für weitere Export-Import-Vorgänge zwischen Gocad und Petrel alle in Abschnitt 4.3 aufgeführten Exportformate in Erwägung zu ziehen und
ihre Tauglichkeit für den neuen Datensatz zu testen.
Die in Abschnitt 1.2 aufgeführten Ziele dieser Arbeit wurden erreicht und damit können die in Abschnitt 1.1 definierten Aufgabenstellungen als erfüllt angesehen werden.
14
A
A.1
Anhang
Dokumentation eines Exports aus Gocad nach Petrel
Export aus Gocad
Diese Dokumentation bezieht sich auf GocadSuite 2.5.0. Bei anderen
Versionen können sich spezielle Arbeitsabläufe oder Export-Plugins
unterscheiden. Der grundlegende Ablauf ist aber ähnlich.
Um ein beliebiges SGrid aus Gocad in ein Format zu exportieren,
welches später nahezu verlustfrei in Petrel importiert werden kann,
müssen folgende Schritte durchgeführt werden:
In der Gocad-Registerkarte „Objects“(A) unter dem Punkt „SGrid“(B)
das zu exportierende SGrid anwählen.
Abbildung 5: Export eines
SGrids aus Gocad nach Petrel
Ein Rechtsklick auf das betreffende SGrid öffnet
das zugehörige Kontextmenü. Dort muss die Option
„Export to“(C) ausgewählt werden, woraufhin sich
ein weiteres Kontextmenü öffnet, in welchem die
vorhandenen Exportplugins aufgeführt sind.
Nicht alle angebotenen Plugins werden für den
Petrelimport unterstützt. Nur die Plugins für
CMG(D1), ECLIPSE ASCII (D2), ECLIPSE binary(D3), RESCUE (D4) und VIP (D5) können von
Petrel grundsätzlich importiert werden.
Abbildung 6: Export eines SGrids aus Gocad
nach Petrel
Hinweis: Es kann nicht garantiert werden, dass alle genannten Plugins für ein spezielles SGrid zu
einem erfolgreichen Import in Petrel führen. Es empfiehlt sich daher, mehrere dieser Exportmöglichkeiten
zu testen, um die für die speziellen Daten geeignetste Möglichkeit zu finden.
Exemplarisch wird für den weiteren Export das Exportplugin ECLIPSE ASCII benutzt.
15
Nach Auswahl des gewünschten Exportplugins öffnet
sich der zugehörige Exportdialog.
Dort muss unter dem Punkt „Reservoir Grid“(E) das zu
exportierende SGrid ausgewählt werde, sofern es noch
nicht ausgewählt ist.
In der Registerkarte „Grid Data“(F) sollte die Option
„One Single File“(G) ausgewählt werden, da es für einen
einzelnen Export nicht unbedingt notwendig ist, in mehrere Dateien zu exportieren.
Unter dem Punkt „Output File „(H) können Name und
Pfad der zu exportierenden Datei angegeben werden.
Wird für die Datei keine Dateiendung vorgeschlagen,
empfiehlt es sich, die Endung .dat zu wählen.
Wenn neben Eigenschaftswerten auch Geometriedaten
exportiert werden sollen, muss die Option „Export Geometry“(I) aktiviert sein.
Um in Gocad definierte Eigenschaften des SGrids zu exportieren, können im Bereich J vorgefertigten Eigenschaftskeywords diesen Gocad-Eigenschaften zugewiesen werden. Diese werden dann exportiert. Es ist ebenfalls möglich, eigene Keywors zu definieren und diesen dann Gocad-properties zuzuweisen. Es kann jedoch
nicht garantiert werden, dass diese eigenen Keywords
später richtig importiert werden.
Abbildung 7: Export eines SGrids aus Gocad
nach Petrel
In der Registerkarte „Advanced“(K) können weitere
Einstellungen für den Export des Grids getroffen
werden. Es können der Koordinatenursprung neu
gesetzt und die Koordinatenachsen vertauscht oder
skaliert werden. Diese Optionen wirken sich nicht
auf das Gocad-Modell aus, sondern werden allein für
den Export benutzt. In diesem Fall muss keine dieser
Optionen angewendet werden.
Wichtig ist allerdings die Option „Include dead cells
for ACTNUM Keyword“(L). Ist diese Option aktiviert,
werden als „dead cell“ definierte Zellen unter einem
gesonderten Keyword exportiert, welches bewirkt,
dass sie nach dem Import weiterhin als Zellen ohne
initialisierte Geometrie vorliegen.
Wenn alle Einstellungen getroffen sind, kann mittels der Buttons „OK“(M) oder „Apply“(N) der Export
durchgeführt werden. Wurde der Button „Apply“
benutzt, schließt sich der Dialog nicht automatisch, es
können also weitere Exporte durchgeführt werden.
Abbildung 8: Export eines SGrids aus Gocad
nach Petrel
Hinweis: Vor allem bei größeren Datenmengen
kann der Export sehr lange dauern und sehr viel
Rechenleistung beanspruchen. Zu dem sind die exportierten Dateien zumeist sehr groß. Es empfiehlt sich
deshalb, die Daten nicht sofort auf langsame Datenträger wie USB-Sticks o.ä. zu exportieren, sondern
sie erst lokal speichern zu lassen und sie erst nach
dem abgeschlossenen Export auf den gewünschten
Datenträger zu kopieren.
16
Import in Petrel
Die exportierten Daten können nach dem Öffnen eines Projektes in Petrel importiert werden. Dazu wird in
der Registerkarte „modells“ mittels Rechtsklick in die Registerkarte das zugehörige Kontextmenü geöffnet.
Dieses enthält unter anderem auch die Option „import“. Wird diese ausgewählt, erscheint ein Dialog zum
Öffnen der Daten. In diesem Dialog muss der Dateipfad der Daten angegeben werden. Zusätzlich kann
man unter „Dateityp“ das zu importierende Datenformat angeben. Dies ist notwendig, damit das für den
Import notwendige Plugin geladen wird. Für den o.g. Fall wäre der Dateityp „ECLIPSE keywords (grid
geometry and properties) (*.DATA)“ anzugeben, auch wenn die Dateiendung nicht .DATA, sondern .dat
lautet. Für diese Art von ASCII-Dateien spielt die Dateiendung keine Rolle. Es ist in diesem Fall nur
notwendig, das richtige Plugin für den Import anzugeben. Nach der Auswahl der Datei und dem Bestätigen
dieser Auswahl öffnet sich der eigentliche Importdialog, in dem man unter anderem angeben kann, ob
man Koordinatenrichtungen spiegeln möchte oder ob z-Zonen separiert werden sollen, sofern dies möglich
ist. Es empfiehlt sich in einem ersten Schritt, die von Petrel angebotenen Standartoptionen zu benutzen.
Mit dem Bestätigen dieses Dialoges startet der Importvorgang. Ist dieser abgeschlossen, erscheint das
importierte Modell in der Liste aller Modelle in der Registerkarte „modells“. Nun kann validiert werden,
ob der Importvorgang erfolgreich war oder ob man, bei einem erneuten Import, Änderungen in den
Optionen vornehmen muss.
A.2
Literatur
Henningsen, D. und Katzung, G. (2002): Einführung in die Geologie Deutschlands, Spektrum Akademischer Verlag, 6. Auflage, S. 96
Mohr, K. (1993): Geologie und Minerallagerstätten des Harzes, E. Schweitzerbartsche Verlagsbuchhandlung, 2. Auflage, S. 365-367
Patzelt, G. (2003): Sammlung geologischer Führer Nr. 96, Nördliches Harzvorland, Gebrüder Borntraeger
Berlin-Stuttgart, S. 5-13
Walter, R. (2007): Geologie von Mitteleuropa, E. Schweitzerbartsche Verlagsbuchhandlung, 7. Auflage,
S. 110
17
A.3
Importmöglichkeiten von Petrel
Die nachfolgenden Tabellen 5, 6, 7 beinhalten die von Petrel unterstützten Export- und Importformate.
Die auch von Gocad unterstützten Formate in Bezug auf 3d-Grids wurden hervorgehoben.
Format name
Aquifer (ASCII)
Bitmap log (BMP,JPG,PCX,TIFF,TGA)
Black oil fluid model (Keywords)
CMG grid (ASCII)(*.GRDECL)
CMG properties (ASCII)
Charisma 2D interpretation lines (ASCII)
Charisma fault sticks (ASCII)
Charisma Irap 2D interpretation lines (ASCII)
Charisma 3D interpretation lines (ASCII)
Checkshots format (ASCII)
CPS-3 grid (ASCII)
CPS-3 lines (ASCII)
CPS-3 grid (Binary)
CPS-3 grid (GeoFrame) (ASCII)
CPS-3 (GeoFrame) lines (ASCII)
Cross plot X,Y (ASCII)
ECLIPSE / FrontSim data and results
ECurtain (XML)
EarthVision grid (ASCII)
ECLIPSE fault data (ASCII)
ECLIPSE well completion data (ASCII)
ECLIPSE Well Connection Data (ASCII)
ECLIPSE .GRID (Binary) or .FGRID (formatted on import only)
ECLIPSE properties (BINARY)
ECLIPSE extended grid (egrid, fegrid)
ECLIPSE Fault Transmissibility Multiplier Data
(ASCII)
Generic ECLIPSE style (ASCII) grid geometry and
properties (*.GRDECL)
ECLIPSE keywords (grid geometry and properties) (*.DATA)
ECLIPSE Fault Data (ASCII)
Generic ECLIPSE style (ASCII) properties
(*.GRDECL, *.*)
ECLIPSE keywords (grid properties) (*.DATA)
RFT Format (Binary/ASCII)
ECLIPSE properties
SCAL and ROCK (Rock Physics) Keywords
ECLIPSE unified summary (Ascii and binary)
ECLIPSE summary RSM (Excel)
Import
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Export
X
X
X
X
X
X
X
Data type
Aquifer
BitmapLog
BlackOil
PillarGrid
Property
Polygons
Polygons
Polygons
Polygons
Points
Surface
Polygons
Surface
Surface
Polygons
CrossPlot
PillarGrid
IntersectPlane
Surface
Fault
PillarGrid
PillarGrid
GlobalGrid
X
X
Property
GlobalGrid
BaseFault
X
3D grid
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
GlobalGrid
X
Fault
Property
Property
CasesTree
Property
SatFuncRegion
Summary
Summary
Tabelle 5: Petrel Import-/Exportformate (zur Verfügung gestellt von DBI-GUT)
18
Format name
Well event data (Ascii)
Fracture Patches in FAB format
FEFLOW grid and properties (ASCII)
Function X,Y (ASCII)
GRF File (Ascii)
General lines/points (ASCII)
BlockK properties (ASCII)
Golder grid properties (ASCII)
Gslib properties (ASCII)
IESX 2D interpretation lines (ASCII)
IESX 3D interpretation lines (ASCII)
IESX Fault polygons (ASCII)
IESX Fault sticks (ASCII)
Bitmap image (BMP,JPG,PCX,TIFF,TGA)
Petrel format (BINARY)
Irap classic grid (ASCII)
Irap classic lines (ASCII)
Irap classic points (ASCII)
Irap classic grid (BINARY)
Irap classic layer (BINARY)
Irap classic lines (BINARY)
Petrel fault model (ASCII)
Kingdom 2D interpretation lines (ASCII)
Kingdom 3D interpretation lines (ASCII)
Kingdom fault sticks (as charisma) (ASCII)
MODFLOW grid and properties (ASCII)
OFM vol data (Ascii)
Well observed data (Ascii)
Open Petrel format (binary)
Open RMS format (binary)
Petrel Summary Data (Ascii)
Point well data format (ASCII)
Petrel points with attributes(ascii)
Rescue format
SEG-Y Import with preset parameters
SEG-Y seismic data
Seisworks fault sticks (ASCII)
Seisworks 3D interpretation (ASCII)
SIMOPT observed survey (ASCII)
Bitmap log (A2D)
Streamlines (BINARY)
Petrel summary data (Ascii)
Historic Summary Data Flat Format (Ascii)
Well tubing data (Ascii)
VFP Format
Import
X
X
Export
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Data type
WellTrace
Fracture Patches
PillarGrid
Function
ModelsTree
Property
Property
Property
Polygons
Polygons
Polygons
Polygons
Image
Data
Surface
Polygons
Points
Surface
Surface
Polygons
KeyPillars
Polygons
Polygons
Polygons
PillarGrid
Summary
WellTrace
PillarGrid
PillarGrid
Summary
Points
Points
3D grid
Seismic
Seismic
Polygons
Polygons
Property
BitmapLog
StreamLines
Summary
Summary
WellTrace
VFP
Tabelle 6: Fortsetzung: Petrel Import-/Exportformate (zur Verfügung gestellt von DBI-GUT)
19
Format name
VIP fault transmissibility multiplier data (ASCII)
VIP well completion data (ASCII)
VIP well connection data (ASCII)
VIP grid (grdecl) (ASCII)
VIP Init/Restart (ASCII)
VIP properties (ASCII)
VIP summary ascii (.plt)
Wavelet (ASCII)
Comment well log (ASCII)
Completion logs
Well design X,Y,Z (ASCII)
Well design trajectory transfer (DO)
Well path/deviation (ASCII)
Well logs (DLIS)
Well heads
Well logs (ASCII)
Well logs (LAS 3.0)
Multiple well logs (ASCII)
Petro works SM1 well format
Production logs
Irap RMS well (ASCII)
Simple well & log (ASCII)
Multiple well paths/deviations (ASCII)
Well simulation general format (ASCII)
Petrel well tops (ASCII)
Seismic data in ZGY bricked format
Zmap+ fault traces (ASCII)
Zmap+ grid (ASCII)
Zmap+ lines (ASCII)
Zmap+ points (ASCII)
Import
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Export
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Data type
BaseFault
PillarGrid
PillarGrid
PillarGrid
Property
Property
Summary
Wavelet
CommentLog
WellTraceSub
WellTrace
WellTrace
WellTrace
WellTrace
Points
WellTrace
WellTrace
WellTrace
WellTrace
WellTraceSub
WellTrace
WellTrace
WellTrace
PillarGrid
Points
Seismic
Polygons
Surface
Polygons
Points
Tabelle 7: Fortsetzung: Petrel Import-/Exportformate (zur Verfügung gestellt von DBI-GUT)
20