Klein Bottles, 3D models and the big picture

Oil IT Journal editor struggles with 3D modeling, mapping and vertical application software as used to model reservoirs and production platforms. Without reaching any hard and fast conclusions, he suspects that today’s focus on ‘integration’ is a little off-target. A multiplicity of 3D applications fulfill diverse, domain-specific needs. But 3D data management may prove a greater commonality.

I saw an ad recently for a piece of software that modeled a Klein bottle. You must have seen them, the neck bends around and goes through the wall of the bottle, continues inside and reappears as an opening in the base. You can see (and buy) one on kleinbottle.com. I wondered how many geo modelers could model the Klein bottle—and whether they might ever need to. I have been struggling with an editorial on 3D since the ESRI PUG, the Klein bottle was an inspiration to try again.

3D is hot

3D is both ubiquitous and ‘hot’. The map may be the ‘integration platform’ of today, but the 3D viewer/modeler will be the integration platform of tomorrow. This is reflected in a lot of activity in the commercial world—from ESRI, the software majors and niche players like EDS, Paradigm and Roxar.

3D is everywhere

3D is everywhere in oil country data and application software. The most basic 3D is the ‘plain sailing’ x,y,z coordinate reference framework. Here, any conversions from geographic coordinate reference systems (CRS) are assumed to have been carried out before data is loaded to the application. Most all interpretation software falls into this GIS naïve category.


A greater level of sophistication is reflected in a proper mapping package like ESRI’s ArcGIS. Such systems can consume data from a variety of different CRSs and map them correctly. ESRI’s software also offers ‘2 D’ support. A point on the earth’s surface can be ‘extruded’ to map a mountain in 3D. While this is ok for topography, or even representing buildings, it will struggle with an overhanging cliff, let alone a salt dome or buried Klein bottle.


In the engineering community 3D is omnipresent with CAD diagrams of plants and pipes. This leads one to wonder if we are doing the same 3D thing over again. Isn’t there a way of seeing the plant model alongside the reservoir model? This is actually a popular boardroom pursuit. I have seen such holistic views including plant data from AutoCad in both ESRI and in Geoprobe. Both times it was clear that the world would have been a better place if the data was available in the appropriate format. ESRI is now ‘reaching out’ to the engineering community with a special track at the ESRI Summit—and a move is afoot to enhance ESRI’s software to allow it to handle true 3D models. This may come as something of a surprise to those who are engaged in reservoir modeling using the many, robust tools that are available today. This is where we have to start considering cultural issues.


Twenty years ago, companies had draftsmen and surveyors who worked on a combination of data management, conversion and mapping to produce base maps etc. A decade ago, the few survivors from this community resurfaced in data management and ‘geomatics.’ Their Swiss Army knife was ESRI and their bread and butter the Shapefile. In the last decade or so, interpretation systems have moved from the map paradigm and into the 3D space. Application software has also discovered a host of new data objects—voxels, surfaces, and geobodies. The mapping community now looks like ‘flatlanders’— hence the desire to extend ArcGIS to true 3D.


As in any community, demarcation is an important issue. The spatial brigade makes a lot of the fact that almost all data has a ‘spatial component’ and therefore falls within their bailiwick, and by implication, should be managed in ESRI. This is a little like saying that, because almost all data has a textual or numeric component, it should be managed in Documentum or Excel (I know, most of it probably is!).


The real differentiation of 3D application software like Autocad, Catia, GoCad, Petrel, VoxelGeo, IRAP etc. is the serious domain knowledge built into these tools. They may not model a Klein bottle, but some know what a fault is, others will ensure that a pipe doesn’t ‘collide’ with another piece of the plant—they may even know what fluid is in the pipe. Some may know that one object is ‘Jurassic,’ others that a cell has a certain permeability or a voxel’s accoustic impedance is 2.6!

GIS as data management

To conclude I submit that the status quo of GIS-naïve applications with a high level of domain specificity is probably a good thing. This moves GIS-awareness upstream of application software and into the data management field. Interestingly enough, at the 2005 PNEC Data Integration Conference there were signs that the data management community is moving on from its obsession with nomenclature and UWIs to discuss CRS management. A sign of things to come?


If this was a blog, I would point you in the direction of Roxar CEO Sandy Esslemont’s excellent editorial on the state of the service industry in the April issue of Hart’s E&P magazine. Esslemont complains of the dual role played by many oil companies who are both technology provider and user. He was scathing about the support given by an operator defending a ‘breakaway group of employees’ from an ‘innovative technology firm’ that had taken ‘intellectual property that was not rightfully theirs.’

Jump ship

The most significant lawsuit that has come into our radar since Oil IT Journal began was the Amoco/Landmark/Coherence tussle (Oil ITJ Vol. 2 N° 7). But technology ‘transfer’ happens all the time—usually without so much fuss. The original Petrel developers hailed from Roxar’s parent Smedvig. And ex-members of the Eclipse team helped code Roxar’s own Tempest simulator! It really is a small world. A fact you can see for yourselves (in 3D!) on keyhole.com..

Click here to comment on this article

Click here to view this article in context on a desktop

© Oil IT Journal - all rights reserved.