Friday, August 15, 2014

OpendTect project portability

I have been doing many 3D seismic interpretation projects recently using OpendTect (OD). I have written elsewhere about its many wonderful features, but for the last week it was driving me nuts.

The back story is that I work across four different machines: Mac laptop, home iMac, office Mac Pro, and office windows machine.  OD data directories are on each machine, plus a common repository on my 1.5TB USB drive.  That is 5 data locations that have to be synced as interpretation goes forward.

When you start using OD, an OD data directory must be established and this holds project folders.  Within each project there are several folders to hold various kinds of information and files:

Two kinds of files are at issue in this note, session and horizon files.  First, session files (xxx.sess) live in the Misc directory and hold information to restore workspace exactly as it was when you saved the session.  Second, horizon files are stored in the Surfaces directory.  As a horizon is created, tracked and then saved, two files are created (xxx.hor and xxx.ts).

Now to the issue.  Earlier this week I was working on a small area inside a 3D seismic survey in SE Kansas.  I limited the work area, got a couple of lines open and a time slice, tracked new horizons (Miss and Woodford), then saved the session.  All this was on my laptop.  To sync my USB version of the OD data, I dropped the session file into the appropriate Misc folder and the horizon files into the Surfaces folder.

Later in the week, I was working at home and copied the new files to my OD directory on my iMac, launched OD, and opened the new session file. Or at least attempted to.  That is the rub, even though I could see the new .sess file from the Mac finder (it was there), the session load dialog box in OD did not show it.  The same thing happened with the horizons, they were there in the correct folder but OD did not see them for loading.

I suspected different operating systems (nope, all same version of OS X), different OD versions (nope, all 4.6).  I examined the new session file and compared to older ones that loaded; was there any difference in permissions or other properties? Nope.  Suspected the creation date was the issue, so manually changed it with unix command line; nope. Only the machine that created the session file could see it, ditto for surfaces. This cut right to the heart of project portability.

Diving into the Misc directory with a unix command line, I noticed an invisible .omf file.  Looking inside I saw something like this:
dTect V4.6
Object Management file
Fri 15 Aug 2014, 09:43:20
ID: 100070`7
Misc: 1
Miscellaneous directory: dGB`Stream
$Name: Misc
Radcliff: 2
Session setup: dGB`Stream
$Extension: sess
$Name: Radcliff.sess
#Created.At: Mon 14 Apr 2014, 18:25:14
#Created.By: Steve Milligan
Then it dawned on me. This is a database file that is updated when a new session or horizon is created.  By only copying the .sess or .hor/.ts files to other machines, the .omf did not get updated on that machine and therefore the new files could not be loaded.  Eureka!!

So the answer (now) is simple.  OpendTect project portability is a snap.  When you create a new horizon or session and want to port it to another machine, drag the whole Misc or Surfaces folder to the new machine and replace the old folder.  The .omf file goes along for the ride and your work will be available on the new machine.  Sweet.

Followup note: OD uses these invisible dot files as a native unix database. I find this far superior to other interpretation systems that hook into a commercial database.  In teaching my 3D seismic interpretation class, we have up to 30 students working across a network via shared drive. Database problems always arise requiring IT staff intervention, a major pain that can be completely avoided with OD. Maybe for some level of complexity a commercial database is necessary, like too many wells or surfaces or multiple users interpreting the same project. But I have not yet bumped into that limit. The chance to run an interpretation class across multiple platforms without any database is very appealing.


Matt Hall said...

Thanks — useful advice!

There may be some unforeseen edge-case that breaks this, but I've had good luck so far with just keeping my OdT projects in Dropbox. This way, the whole project is automatically synced across all my machines.

We even manage our Agile projects this way, using a shared Dropbox folder. Evan and I can then see the same data; we just maintain a naming convention to manage our stuff.

I guess one problem with Dropbox is potentially volume size — Evan and I have over 200GB each, which of course isn't even enough for lots of projects.

Unknown said...


Yeah it took me a while to figure out .omf files out too.

I'm not the biggest fan of this data structure, there are some obvious flaws with it.

It's kinda like the DGB guys are not quite sure if they need an actual DB or if they should use a unix philosophy of trusting the user got the file structure right.