Strata

A Stratigraphic Modeling Package

Release 2.14

P.B. Flemings, J.P. Grotzinger, J.E. Morris

User Manual

This was written as part of Basin Research at Penn State

You can download the code, user manual, and a tutorial guide to Strata.


*** Strata was last revised December '97 ***

If you have an older version, you will want to download updated material.


Table of Contents

  1. Introduction
  2. Using Strata
    1. Setbasin
    2. Simbasin
    3. Plotbasin
    4. Filmbasin
  3. Discussion of the controlling variables
    1. Measures Group Parameters
    2. Ages Group Parameters
    3. Clastics Group Parameters
    4. Carbonates Group Parameters
    5. Sealevel Group Parameters
    6. Subsidence Group Parameters
    7. Compaction Group Parameters
    8. Heat Flow Group Parameters
  4. Seismic Response Prediction
  5. Appendices
    [ References | Downloading Strata | Licenses and Copyrights | GNU General Public License | Changes from Release 2.0 | Known Bugs | Unimplemented Features | Mailing Lists | File Formats ]

History

Strata is a basin modeling package now freely available on the Internet. The model was originally developed as a part of Flemings' dissertation at Cornell University under the direction of Teresa Jordan (Flemings and Jordan (1989), Flemings and Jordan (1990), and Jordan and Flemings (1991)). Subsequently, support from Chevron Oil Field Research Company (now Chevron Petroleum Technology Company) allowed Flemings and Grotzinger to begin collaboration with Morris, then an undergraduate at MIT. Development has continued at both Penn State and MIT. NSF Grant EAR-90-19633 (Flemings), PRF American Chemical Society Grant 18887-AC2 (Jordan), and funding from Chevron (Flemings and Grotzinger) and Shell Development (Flemings) have supported this project.

Introduction

Strata is composed of four programs: a pre-processor setbasin to set the model's parameters, a processor simbasin to run the model with the user-defined parameters, a post-processor plotbasin to display results, and a special utility filmbasin which combines processing and post-processing to make a movie.

The Strata package should work on UNIX and UNIX-like systems (incl. Linux, NetBSD) in general. (See Downloading Strata.) It is not available for other systems (e.g. MS Windows, Macintosh).

Some annotation in this manual: typewriter font indicates commands to be entered by the user. Names in < angles > indicate controls on a graphic interface. Italicized text usually indicates a file or directory.

The Appendices have information about academic references, downloading Strata (and information on program development and environments), licenses and copyrights and the GNU General Public License, changes from the last release (including patches), known bugs and not-yet-implemented features as of this release, Strata-related mailing lists, and necessary file formats to interface your own models with Strata.

Using Strata

Refer to Downloading Strata for instructions on downloading Strata. You should have the executables for setbasin, simbasin, plotbasin, and filmbasin either installed on your system (so that they can be used from anywhere) or in their subdirectories in src. If the latter, we recommend you make a simulations directory somewhere and link the executables into it. (E.g. ln -s /myhomedir/strata/src/*basin/*basin /myhomedir/strata/simulations/ will link all of them at once, after you've compiled them in src.)

With the executables available, you are ready to begin using the applications.

Setbasin

This is the pre-processor; its purpose is to edit the model's parameters. These are held in a library file which defines the basin and is always given a .dat suffix to distinguish it. (All Strata programs will assume a .dat suffix for libraries.) Library files are created with setbasin and passed to simbasin; users shouldn't edit them directly. (Users of Strata 2.0 should see Changes from Release 2.0 about using setbasin to convert their old libraries to v2.1 format.)

To create a library from scratch, you might do the following:

You now have the library mybasin.dat with the parameters you specified. Any you did not change have the default values; you can get a perfectly good library (which produces a short, small simulation) with just the default values and no changes.

To make a similar library later, you could start up with setbasin mybasin. This automatically loads up mybasin.dat and presents you with those parameters. You can then make changes and save back to mybasin.dat (the default choice it presents you with when you click < save > ) or to a different library.

If you're already running setbasin and want to load your library, you can click < load > and type mybasin in the resulting subwindow (and then hit < confirm > ). Setbasin will then have the mybasin.dat parameters. It is not necessary for a library file to be complete. If some parameter is not specified --- either because you used the options to save and load in groups, or (most likely) because new parameters have been added in a new release --- simbasin will use the default values for the unspecified parameters. If you load an incomplete library into setbasin, it will use all the values the library does give, and leave the other parameters as they were before.

Simbasin

This is the processor; its purpose is to run the simulation and generate the output files to be viewed with plotbasin (the post-processor).

Plotbasin

This is the post-processor; it displays the results of the simulation and can generate hardcopy. To produce hardcopy in plotbasin, select an option under < dump > and specify a path. An .xwd ending produces an xwd file, and a .gif ending, a gif. Note that the colors may not come out as finely as they appear in plotbasin.

Filmbasin

Filmbasin is used to produce a sequence of snapshots of the simulation, which can then be viewed together as a movie. Filmbasin splits itself into a copy of the processor and a copy of the post-processor and arranges for them to talk to each other in a certain way. After the post-processor knows what data to display and how, the processor simulates the model up until the time for the first snapshot, then pauses while the post-processor displays this and saves the picture, after which the post-processor pauses while the processor continues the simulation until the next snapshot... etc. At the end of the simulation the processor and post-processor die automatically, leaving your files behind. Filmbasin has the same prerequisite as simbasin; namely, a library file as created by setbasin. The syntax is then

filmbasin library tag [-s simulator] [-p plotter] [-f number of frames] [-a]

Library specifies the library in the usual fashion. The tag is a string to affix to the file names to make sure things aren't overridden --- if you make a film from the library mybasin with tag poros, you'll get files named mybasin.film.poros.001.gif etc., which then won't get erased when you run a film from the same library with a different tag (hence different names).

You may optionally specify a plotter (post-processor) with the -p flag. If you do not specify one, it will look for plotbasin (i.e. something named "plotbasin" along your path). You may specify a simulator (processor) with the -s flag. If you don't, it will look for something called simbasin. These two flags are useful if (and only if) you have your own special processor and/or post-processor, or your copies of plotbasin and simbasin are located somewhere not on your path.

You will frequently want to specify the number of frames with the -f flag. If you do not, it defaults to the number of timelines as specified in the library file. If you specify a number greater than this, it will be cut down to this.

If the -a flag was given, filmbasin will prompt you for arguments to pass to the plotter and simulator. Either or both may be left blank. Any arguments you specify will have the same effect as using them directly in the plotter or simulator. For instance, if you specify -p myparams as a plotter argument at this point, and the plotter is plotbasin, it will load the parameter file myparams at startup, that being what plotbasin library -p myparams would do.

The size of the plotbasin window is fixed when started by filmbasin, because the methods we have found so far to turn gifs into real physical films require this size; if people find problems with this it'd be easy enough to change (I don't know why it isn't a settable flag already). You can set whether the timelines are visible, what color data to plot, etc., normally in plotbasin. Set these as desired; they remain fixed throughout the film. You will probably want to run plotbasin normally on the output of simbasin on this library to see what settings produce nice-looking pictures beforehand. Once you are done with the settings on the plotter started up by filmbasin, click on any of the age markings, which will all be zeros, to start it filming. Everything from there is automatic; you can no longer use the plotter controls.

If you are filming the progress of color data, remember that most types automatically scale between the highest and lowest values so far encountered, which means the color scale will change over the course of the film. To avoid this, figure out a range which includes the highest and lowest values you expect to encounter (doing a non-film run first is the best way to do this), set the data to scale between those values in the parameters window, and turn scaling on for that datum. See the plotbasin help entries on color data and scaling for specifics. Also note that data fields frequently assume atypical extreme values during the first few iterations of the simulation, so scaling may result in odd ranges (most notably for porosity, which seems to always have its low end pushed to zero at the start of films).

The files generated will be named in the format (library).film.(tag).(number).gif, where (number) is the number of the frame and gets zero-padded to make them all have the same number of digits (i.e. a 2000-frame picture will have numbers 0001... 0010... etc.). The plotter automatically makes gif rather than xwd files when started by filmbasin.

Note that all this will take a long time to run. If you use the default number of frames, and don't have an unusually coarse-grained or unusually small simulation, expect to leave it running overnight. Also, while a gif file is a highly compressed way to store graphics data, storing thousands of them still takes up a lot of space --- make sure you have room!

How do you get an actual film out of the files? There are companies that will take a collection of gif files and hand you film. Check the yellow pages.

There are also various utilities out there that let you view the film on the screen with little or no further processing of the .gif's.

XAnim is one such utility. It's free and fairly widely distributed, so you may well have it already. If not, look at the xanim homepage or ftp to xanim.va.pubnix.com. These have very good directions for getting, compiling, and using xanim.

We didn't write xanim and we haven't used it very much, so we probably won't be able to help if you have questions about it. We have found that xanim displays Strata films nicely when invoked by

xanim -Cd (library).film.(tag).*.gif

though you should note that it takes quite a while to start up to the point of providing a window, and a long time after that to start the animation --- it's loading a lot of data! Also, if there are a lot of gifs it may not be able to store all of them.

MPEG is a standard format for video data. Again, we didn't write it and we don't know much about it, so we'll only say a little about it here. There's a good chance you have the applications mpeg_encode and mpeg_play available on your system. The former can take a bunch of .gif files (among other things) and turn them into an MPEG file; the latter can display an MPEG file as a movie. An HTML link to an MPEG file (with a .mpeg, .mpg, or .mov extension) will provide a click-to-view movie on a webpage.

Mpeg_encode requires as input a parameter file describing what it's supposed to be doing along with the .gif's it's supposed to do it to. We have found that a parameter file that looks like

PATTERN              IBBPBBPBBPBBPBB
OUTPUT               mybasin.mpeg
BASE_FILE_FORMAT     PPM
GOP_SIZE             30
SLICES_PER_FRAME     1
PIXEL                HALF
RANGE                10
PSEARCH_ALG          LOGARITHMIC
BSEARCH_ALG          CROSS2
IQSCALE              8
PQSCALE              10
BQSCALE              25
REFERENCE_FRAME      ORIGINAL
YUV_SIZE             640x480
INPUT_CONVERT        giftopnm *
INPUT_DIR            .
INPUT
mybasin.film.mytag.*.gif [001-250]
END_INPUT
produces the correct results. Depending on what graphics converters you have, you may need to change the BASE_FILE_FORMAT and/or INPUT_CONVERT lines. If the above is in mpeg.params, then mpeg_encode mpeg.params will read files mybasin.film.mytag.001.gif thru mybasin.film.mytag.250.gif and produce mybasin.mpeg. Mpeg_play mybasin.mpeg will then display the latter.

Discussion of the controlling variables

The following discussion will explore how each of the parameters, defined in setbasin, affects the operation of the simulator, group of parameters by group. It is recommended that you read setbasin's help entry for each parameter before altering it. A tutorial of exercises in Strata is available with the Strata package; we recommend using it as a guide to the effects of each parameter.

At the heart of the simulation is the assumption that sediment transport behaves diffusively (i.e. volumetric flux is proportional to local gradient). For carbonate simulations the sediment source is proportional to water depth, while for clastic simulations the sediment source is a user-specified function. We strongly recommend that you flip through Jordan Flemings (1991), Flemings and Jordan (1989), Flemings and Jordan (1990), and Kaufman et al. (1991) to gain a physical insight into this process. The most useful of these for marine simulations will be Jordan and Flemings (1991).

What follows is a quick description of the important controls. A note on units: any system can be used as long as it is self-consistent. We have personally been working in an m/k/yrs world, and examples are in m/k/yrs units; when plotbasin gives a unit label, it assumes m/k/yrs, so you will need to mentally apply conversion factors there if you use another system.

Measures Group Parameters

total width covered
specifies the horizontal span of the simulation.
spatial divisions
determines how many intervals the total width is divided into; it is therefore the spatial accuracy of the simulation. Note that the simulator runtime is proportional to the square of the number of spatial divisions, and file output size is linearly proportional.
total time covered
specifies the duration of the simulation.
temporal divisions
determines how many intervals the duration will be divided into in calculating the time evolution of the basin; it is therefore the temporal resolution of the simulation. This must be a multiple of the number of timelines.
# timelines
determines how many recordings the simulator makes of the state of the simulation. It must be a factor of the number of temporal divisions. Each timeline records the surface condition (and the condition of every underlying surface) at that time. The default parameters specify 1000 temporal divisions in 100 timelines, so the state is saved after every 10th iteration (every 20,000 years). Note that the runtime of the simulation varies linearly with the number of temporal divisions; file output size is linear in the number of timelines. Also, while the validity of the model's approximations is obviously generally dependent on the number of temporal divisions, the porosity and thermal data fields are actually dependent on the number of timelines instead, as they are calculated at timelines only, rather than at each iteration.

Ages Group Parameters

use even increments
specifies whether the ages of the time slices should just be even divisions of the total duration. The default is that they should be, allowing you to ignore this group entirely.
age of nth time slice
specify the individual time slice ages if they are not being automatically set to even increments. They must be in increasing order. At each time slice, the simulator will save a data file describing the state of the simulation at that age. These ages are those listed beneath the image in plotbasin (well, actually each one is the first age at least equal to the specified age, since the iterations may not hit the specified age exactly).

Clastics Group Parameters

These define the diffusion specifications for the model. Both marine and non-marine transport rates are controlled by the topographic gradient,

See Jordan and Flemings (1991) and Kaufman et al. (1991) for insight into the meaning of these diffusion constants. To generate a realistic shelf break, the nonmarine diffusion constant is set to a high value, while the marine diffusion coefficient is set to a much lower value. A simple rule of thumb is that to generate steeper clinoforms you should decrease the marine diffusion constant.
nonmarine diffusion constant
sets k in the sedimentation equation above, in at least the nonmarine zone (i.e. water depth less than zero.) Depending on the other parameters, it may set k everywhere.
simulate marine sedimentation
allows for k to vary between marine and nonmarine zones. If false, k will have the nonmarine value everywhere.
marine diffusion constant
sets k in the marine zone (very large water depth) if marine sedimentation is being simulated. The transition between nonmarine and marine diffusion constants can be smooth or abrupt; see the diffusion constant decay equation below.
decay coeff. for marine diffusion constant
governs the (exponential) rate of decay for marine diffusion from nonmarine to marine values. That is,

for w > 0, the decay constant being lambda.
left, right clastic fluxes
define the flux entering the basin from each side. Each may be specified as a number, which means a constant flux, or as a file, which means that file defines the flux as a function of time (see the setbasin help entry on flux files). We recommend that all clastic flux files be given a .clas extension.
pelagic sedimentation rate
defines a constant sedimentation rate in the marine zone as an additional source term.

Carbonates Group Parameters

This group of parameters deals with calcium carbonate sedimentation. The fundamental difference between CaCO3 sedimentation and clastic sedimentation is that the CaCO3 sedimentation is a source term whose magnitude is dependent on water depth and which can occur anywhere along the cross-section being modeled. In contrast, the clastic sedimentation is defined by an input flux on the left- or right-hand side of the model; this flux is then redistributed by slope-dependent diffusion. See Gildner and Cisne (1990) for more details.
carbonate file
Two carbonate deposition algorithms are possible and can be mixed together in a single profile, epeiric sedimentation and oceanic sedimentation. The carbonate file specifies (as per the setbasin help entry) exactly what carbonate deposition operates at each point. Setbasin has a facility (explained therein) to allow you to view the shape of the curves defined by each carbonate equation with your parameters. We recommend that all carbonate files be given a .carb extension.


Epeiric (exponential-depth) sedimentation, where c_1 is the maximum sedimentation rate and w_0 is the depth of the maximum sedimentation rate. See Gildner and Cisne (1990).

epeiric CaCO3 sed --- max rate
specifies c_1 in the above equation.
epeiric CaCO3 sed --- depth of max rate
specifies w_0 in the above equation.


Oceanic (lag-depth) sedimentation, where c_1 is the maximum sedimentation rate, c_2 is the exponential decay constant, and w_0 is the depth of the maximum sedimentation rate. For w < w_0, dsed/dt = c_1.

oceanic CaCO3 sed --- max rate
specifies c_1 in the above equation.
oceanic CaCO3 sed --- exp. decay constant
specifies c_2 in the above equation.
oceanic CaCO3 sed --- depth of max rate
specifies w_0 in the above equation.
lag on zero water depth
controls carbonate lags when the system shoals to sealevel. If it is set to True, the lag (depth and/or time) is initiated when the depositional surface exactly matches (or exceeds) the sealevel, allowing multiple shoaling cycles even with no external forcing. If this is False, the lag is only initiated when the depositional surface is above the sealevel (which must be caused by non-carbonate effects).
isotope signal file, isotope offset time
aren't really carbonate parameters, but they're closer to that than to anything else. They allow for the tracking of spatially homogenous, temporally varying isotope signals, as recorded at the surface. Subsequent vertical movement of the stratigraphy inhomogenously stretches and compresses the signal (possibly eliminating some, at lacunae); no other dynamics are taken into effect. The final (horizontally varying) distorted signals can be examined to test isochronicity fitting. See the help entries for descriptions of isotope files and further information.

Sealevel Group Parameters

sealevel file
may be omitted completely (in which case the other sealevel parameters are used to generate a sine wave eustatic curve) or used to specify the eustatic curve in great detail. Such files can give a point-by-point specification of the sealevel, or define a series of fully-parameterized sine waves turning on and off with time whose sum is the sealevel.

See the setbasin help entries for details on sealevel files. We recommend that all sealevel files be given a .sea extension.

The file exxon.sea is a special case; it holds the Haq Sealevel Curve, with times given relative to the present. Note that using it may be a bit non-intuitive due to the format of Haq's file. Since it gives time from the present, and the model always uses time from the start of the simulation, it is necessary to use a highly negative time offset, at least as great as the total duration of the simulation. For instance, if the simulation is to run for 20 ma, and the time offset is specified as -100 ma, the portion of the Haq curve from -100 ma to -80 ma will be applied.

time offset
applies to all sealevel functions. At time T, eustatic calculations will use (T - offset) as the time.
datum for sealevel oscillation, sealevel oscillation amplitude, sealevel oscillation period
define the eustatic curve in the absence of a sealevel file. The curve will be a sine wave with these parameters as center, amplitude, and period, and < time offset > as the offset.

Subsidence Group Parameters

subsidence rate
determines the driving subsidence rate, either as a number (a constant subsidence) or as a file (see the setbasin help entry for details on subsidence files). Any number of subsidence histories, defined with "wells" at positions along the profile, can be specified. We recommend that all subsidence files be given a .subs extension.
profile
is either ``cratonic'' (flat; subsidence constant across basin), ``foreland'' (subsidence is maximum at the left), or ``passive'' (subsidence is maximum at the right). The subsidence decrease along the basin in non-cratonic profiles is linear.
flexural isostatic compensation
determines whether or not the surface of the earth behaves as an elastic plate.
flexural rigidity
governs the elastic flex response of the earth to loads. A zero flexural rigidity will simulate perfect isostacy. Please see the setbasin help entry about low flexural rigidity values.
densities of air, crust, mantle, water; gravitational constant
have obvious impact upon the loads flexing the surface. Setbasin allows them to be specified to allow for other systems of units, and for the ambitious to model basins on other planets.

Compaction Group Parameters

compact sediments
determines whether compaction occurs at all. If this is set to False, the other parameters in this group become irrelevant. If it is set to True, compaction will occur.

We follow the approach of Sclater and Christie (1980) and assume porosity is an exponential function of depth:

where f is the fraction of sand (assuming only sand and shale are present) and the constant parameters are defined below.

let erosion affect compaction
determines whether the effects of erosion will be taken into consideration in the compaction calculations. If so, compaction is irreversible (i.e. the strata do not expand when the overburden is decreased). See Hart et al. (1995) for a discussion of this behavior.
decay constants for sand, shale compaction
specify lambda_{sand} and lambda_{shale} respectively in the above porosity equation and govern the falloff of porosity with depth as per Sclater and Christie.
initial porosities for sand, shale
specify phi_{0, sand} and phi_{0, shale} respectively in the above porosity equation and determine the surface porosities as per Sclater and Christie.

We note that the default values from Sclater and Christie (1980) are:

cutoff for sand composition, decay constant for composition
There are two ways in which Strata may calculate the sand-shale percentages in the model: from diffusion constants, or as a function of water depth. If < cutoff for sand composition > is set to a negative number, then < decay constant for composition > becomes irrelevant and the composition is determined by linear interpolation of diffusion constants. If < cutoff for sand composition > is zero or positive, then the composition will be taken to be pure sand between the surface and this depth, and decay exponentially with the specified constant below the cutoff depth.

Heat Flow Group Parameters

Strata is capable of using a simplistic steady-state model to calculate temperature distributions and thermal evolution (i.e. integrated time-temperature history, Sum TTI) of the basin. Only vertical heat transport is accounted for, and the only heat source is flux supplied at the base of the basin. The temperature distribution is calculated from

where k is the thermal conductivity (watts per meter degree), T is temperature (degrees Celsius), and q is the heat flux (watts per square meter). Because this is a steady-state problem, given q and k we can calculate the temperature gradient at any point given any boundary condition. We choose to set the temperature at the sediment surface by explicitly specifying the temperature at the air interface and using

to determine the temperature at the sediment-water interface for underwater areas. We can then calculate the temperature at any location.

The thermal conductivity is assumed to vary as a function of lithology and porosity.

where f is again the fraction of sand in the sand and shale, and phi is porosity. We work in MKS units (since the thermal quantities only enter the model in equations with each other, we can safely think of them all in MKS instead of m/k/yrs with no effect on the numbers), and so our usual values are (Turcotte and Schubert, 1982)

where the third significant digit has been specified so that areas of sand and shale will be distinguishable when the model runs without compaction (and therefore with zero porosity).

thermal flux
specifies q in the steady-state thermal equation above. It may be specified as a nonnegative number, giving a constant thermal flux, or as a file, giving the thermal flux as a function of time. No thermal calculations will be performed if there is no thermal flux. See setbasin's help material for details on thermal flux files. We recommend that all thermal flux files be given a .therm extension. Typical continental heat fluxes are 56.5 milliwatts per square meter; typical oceanic heat fluxes are 78.2 milliwatts per square meter (Turcotte and Schubert, 1982). Note: syn-rift heat fluxes are typically higher than continental heat fluxes (Turcotte and Schubert (1982), Waples (1985)).
thermal conductivities of sand, shale, fluid
specify k_{sand}, k_{shale}, and k_{fluid} respectively in the thermal conductivity equation above.
surface temperature
specifies T_{air} in the temperature falloff equation above.
surface temp falloff
specifies alpha in the temperature falloff equation above.
The simulator calculates the Sum Time-Temperature Index (Sum TTI) as

where the TTI which is summed is a continuous version of the empirical

for which n(T) has been found to be crudely approximated by

The fundamental trait here is that the reaction rate doubles with every temperature increase of 10 degrees C.

The TTI value indicates how much the sediment has matured in that time interval. The Sum TTI is thus the total maturity of the sediment. The following table shows the usual interpretation of the Sum TTI values. (Note that these are typically given in megayears, not years.)

Seismic Response Prediction

Plotbasin has the ability to predict the seismic response of the modeled basin. Briefly, since the porosity is everywhere known, as is the sand-shale composition, the density of and velocity of sound in the material is uniquely determined. (If the library turned compaction off, the porosity is taken to be zero everywhere.) As described in Compaction Group Parameters, simbasin and plotbasin determine the sand-shale composition via either the prevailing diffusion constant or deposition water depth.

Velocities are determined from the Wylie equation

where f is again the fraction of sand in the sediment (ignoring fluid), v_{material} is the velocity of sound through that material. V_b is the resulting bulk velocity and is a selectable data type under < fill > , < log > , and < contour > .

The velocities of sound in sand, shale, and fluid are set in the parameters window. Typical acoustic velocities are (from Schlumberger, 1987)

Bulk density is determined from

where rho_{material} is the material density and rho_b is the resulting bulk density, which is a viewable data type. Material densities are also specified in the parameters window.

The impedance of a layer of sediment to sound (also selectable data) is derived as

The reflection coefficients are defined by

and may be made visible with the < misc > menu.

The final signal, consisting of the explosive wavelet (selected in < misc > and visible when relevant in the top left) convolved with the reflection coefficients, may take a few moments to be calculated. It is viewable under < fill > or < log > . (Signal data cannot, of course, be contoured.)

Appendices

  1. References
  2. Downloading Strata
  3. Licenses and Copyrights
  4. GNU General Public License
  5. Changes from Release 2.0
  6. Known Bugs
  7. Unimplemented Features
  8. Mailing Lists
  9. File Formats

References

Flemings, P.B. and T.E. Jordan, ``Stratigraphic Modeling of Foreland Basins: Interpreting Thrust Deformation and Lithospheric Rheology,'' Geology 18: 430-434, 1990.

Flemings, P.B. and T.E. Jordan, ``A Synthetic Stratigraphic Model of Foreland Basin Development,'' Journal of Geophysical Research 94: 3851-3866, 1989.

Gildner, R.F. and J.L. Cisne (ed.), ``Quantitative Modeling of Carbonate Stratigraphy and Water-Depth History Using Depth-Dependent Sedimentation Function in Cross, T.A.,'' Quantitative Dynamic Stratigraphy. Prentice Hall, New Jersey, 1990.

Haq, B.U., J. Hardenbol, and P.R. Vail, ``Chronology of fluctuating sea levels since the Triassic,'' Science 235: 1156-1187, 1987.

Hart, B.S., P.B. Flemings, and A. Deshpande, ``Porosity and pressure: Role of compaction disequilibrium in the development of geopressures in a Gulf Coast Pleistocene basin,'' Geology 23 (1): 45-48, 1995.

Jordan, T.E. and P.B. Flemings, ``Large-Scale Stratigraphic Architecture, Eustatic Variation, and Unsteady Tectonism: A Theoretical Evaluation,'' Journal of Geophysical Research, 96 (B4): 6681-6699, 1991.

Kaufman, P., J.P. Grotzinger, and D.S. McCormick, ``Depth-dependent diffusion algorithm for simulation of sedimentation in shallow marine depositional systems in Franseen, E.K.,'' in W.L. Watney, C.G.S.C. Kendall, W. Ross (eds.) Sedimentary modeling: Computer simulations and methods for improved parameter definition, Kansas Geological Survey, 1991.

Log Interpretation Principle/Application, Schlumberger Educational Services. Houston, 1987.

Pegrum, R.M. and A.M. Spencer, ``Hydrocarbon Plays in the northern North Sea,'' in Brooks, J. (ed.) Classic Petroleum Provinces. Geological Society Special Publication, London, 1990.

Ross, W.C., D.E. Watts, and J.A. May, ``Insights from Stratigraphic Modeling: Mud-Limited Versus Sand-Limited Depositional Systems,'' AAPG Bulletin 79(2): 231-258, 1995.

Sclater, J.G. and P.A.F. Christie, ``Continental Stretching: An Explanation of the Post-Mid-Cretaceous Subsidence of the Central North Sea Basin,'' Journal of Geophysical Research 85 (B7): 3711-3739, 1980.

Turcotte, D.L, and G. Schubert, Geodynamics: Applications of continuum physics to geological problems. John Wiley & Sons, New York, 1982.

Waples, D.W., Predicting Thermal Maturity, in Geochemistry in Petroleum Exploration. International Human Resources Development Corporation, 1985.

Downloading Strata

Strata is written in C with X Windows graphics (using the X Toolkit and the Athena Widget set, both of which are part of the standard X distribution), development being with X11R5.

Strata has been successfully used on some DEC MIPS Ultrix, HP/UX v9, SGI, AIX, NetBSD, Linux, Solaris, and SunOS systems; the latter two platforms probably offer the most stability, being the main development environments. It ought to work in UNIX and UNIX-like systems in general. Strata is not available for other systems (e.g. MS Windows, Macintosh).

Copies of this manual in Latex and Postscript are available on the Strata Downloading page along with the Strata source, tutorial, and patches.

You may also retrieve Strata via anonymous ftp from the Penn State sytem:

The first file you should get is README; read it. It will tell you what the other files there are. For any other file that you download, if there's a README for it you should get that too and read it --- e.g. if you get tutorial.tar.gz first read tutorial.README.

Unpacking: Most of the material is packed in .tar.gz files. To unpack such a file, either gtar xvfz name.tar.gz if you have gtar (gnu tar) on your system, or else do gunzip name.tar.gz and then tar xvf name.tar. In either case, you will be left with a copy of the tarfile as well as its contents; you'll want to rm the leftover tarfiles.

Gzip: Most UNIX environments have gzip, but it's easy to get if you don't. Like other GNU applications (e.g. gtar), gzip source for various environments is available to anonymous ftp to prep.ai.mit.edu in /pub/gnu. If necessary, gzip -d acts the same as gunzip.

Source Code: The source tarball creates the directory src, and in it a directory for each of the programs, each with its own source. In src there is a configure script which will handle compilation for you. Cd to src and do

This should leave you with each program's executable in its directory. If you have the correct access you can install these with make install --- if you have this access, you probably already know about this; if not, you should talk to your sysadmin if you want the programs installed. See README.install.

This manual does not appear in src, but is available (in LaTeX and Postscript) in man.tar.gz.

Tutorial: This material appears in a tutorial directory. It includes the libraries and data files used in the tutorial. WARNING: the tutorial postscript was made in FrameMaker and has lots of pictures so it is very, very big --- you may have trouble even printing it. You should be able to view it with ghostview and such.

Also please note that the tutorial has not been updated to reflect changes in the package since it was first written! For instance, the tutorial claims that the data files appear elsewhere, whereas they actually appear in the tutorial directory itself. Basically, the information on actually using Strata is accurate, but references to how the package appears is suspect. In case of conflict, this manual is correct.

Revisions: Revisions to Strata will be available in the same places (ftp and WWW); those important enough will be announced to the strata-users list.

Usually, but not always, a revision will be available both as a complete package to take the place of your old Strata and as a patchfile which can be used to patch your old Strata; there will not always be a patchfile. When there is, to patch your copy of Strata, download (and gunzip and untar, just as for the original source) the patches between your version and the latest. Place the resulting patchfile(s) in src. In that directory,

where | is a vertical bar (``pipe''). This will patch your source. Then and you will have the new executables; of course, they'll need to be reinstalled if you installed the old ones.

Licenses and Copyrights

Strata, a set of sedimentary basin modeling programs.
Copyright (C) 1995 P.B. Flemings, J.P. Grotzinger, and J.E. Morris.

This package is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This package is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program (license.h in the source code); if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

For more information about this package, or to report bugs or be added to the strata-users mailing list, please send email to strata-admin@geosc.psu.edu. You may also wish to contact

Peter B. Flemings
Department of Geosciences
Penn State University
442 Deike Bldg.
University Park, PA 16802
flemings@geosc.psu.edu

John P. Grotzinger
54-816
Department of Earth, Atmospheric, and Planetary Sciences
MIT
Cambridge, MA 02139
grotz@grabau.mit.edu

Jamie Morris
905 Main St. #6
Cambridge, MA 02139
jemorris@mit.edu

Also, the source file license.h contains a copy of the Gnu General Public License, and the source file strata.h contains some excerpts from this manual.

You may wish to note that the xwd capabilities of the program are derived directly from the xwd source (files xwd_dsimple.c, xwd_dsimple.h, and xwd_here.c of plotbasin), which has the following copyright notice:


 XConsortium: copyright.h,v 1.5 89/12/22 16:11:28 rws Exp 

   Copyright 1985, 1986, 1987, 1988, 1989 by the

   Massachusetts Institute of Technology
   

   Permission to use, copy, modify, distribute, and sell this software
and its documentation for any purpose is hereby granted without fee,
provided that the above copyright notice appear in all copies and that
both that copyright notice and this permission notice appear in
supporting documentation, and that the name of M.I.T. not be used in
advertising or publicity pertaining to distribution of the software
without specific, written prior permission.  M.I.T. makes no
representations about the suitability of this software for any
purpose. It is provided "as is" without express or implied warranty.

Similarly, the gif-making code (gif_here.c of plotbasin) is taken from code with the following licensing / copyright notice:

The Graphics Interchange Format(c) is the copyright property of
CompuServe Incorporated. Only CompuServe Incorporated is authorized to
define, redefine, enhance, alter, modify or change in any way the
definition of the format.

CompuServe Incorporated hereby grants a limited, non-exclusive,
royalty-free license for the use of the Graphics Interchange
Format(sm) in computer software; computer software utilizing GIF(sm)
must acknowledge ownership of the Graphics Interchange Format and its
Service Mark by CompuServe Incorporated, in User and Technical
Documentation. [The rest of the notice concerns software lacking such
acknowledgment, so is irrelevant, since here it is.]

GNU General Public License


Version 2, June 1991

 Copyright (C) 1989, 1991 Free Software Foundation, Inc. 675 Mass Ave, 
Cambridge, MA 02139, USA Everyone is permitted to copy and distribute verbatim
copies of this license document, but changing it is not allowed.

			    Preamble

 The licenses for most software are designed to take away your freedom
to share and change it. By contrast, the GNU General Public License is
intended to guarantee your freedom to share and change free software
--- to make sure the software is free for all its users. This General
Public License applies to most of the Free Software Foundation's
software and to any other program whose authors commit to using
it. (Some other Free Software Foundation software is covered by the
GNU Library General Public License instead.) You can apply it to your
programs, too.

When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
this service if you wish), that you receive source code or can get it
if you want it, that you can change the software or use pieces of it
in new free programs; and that you know you can do these things.

To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the
rights. These restrictions translate to certain responsibilities for
you if you distribute copies of the software, or if you modify it.

For example, if you distribute copies of such a program, whether
gratis or for a fee, you must give the recipients all the rights that
you have. You must make sure that they, too, receive or can get the
source code. And you must show them these terms so they know their
rights.

 We protect your rights with two steps: (1) copyright the software,
and (2) offer you this license which gives you legal permission to
copy, distribute and/or modify the software.

 Also, for each author's protection and ours, we want to make certain
that everyone understands that there is no warranty for this free
software. If the software is modified by someone else and passed on,
we want its recipients to know that what they have is not the
original, so that any problems introduced by others will not reflect
on the original authors' reputations.

 Finally, any free program is threatened constantly by software
patents. We wish to avoid the danger that redistributors of a free
program will individually obtain patent licenses, in effect making the
program proprietary.  To prevent this, we have made it clear that any
patent must be licensed for everyone's free use or not licensed at
all.

 The precise terms and conditions for copying, distribution and
modification follow.
                    
	GNU GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, 
	DISTRIBUTION AND MODIFICATION

 0. This License applies to any program or other work which contains a
notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License. The "Program", below,
refers to any such program or work, and a "work based on the Program"
means either the Program or any derivative work under copyright law:
that is to say, a work containing the Program or a portion of it,
either verbatim or with modifications and/or translated into another
language. (Hereinafter, translation is included without limitation in
the term "modification".) Each licensee is addressed as "you".

Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of
running the Program is not restricted, and the output from the Program
is covered only if its contents constitute a work based on the Program
(independent of having been made by running the Program). Whether that
is true depends on what the Program does.

 1. You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty; keep intact all the
notices that refer to this License and to the absence of any warranty;
and give any other recipients of the Program a copy of this License
along with the Program.

You may charge a fee for the physical act of transferring a copy, and
you may at your option offer warranty protection in exchange for a
fee.

 2. You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:

    a) You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.

    b) You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any part
thereof, to be licensed as a whole at no charge to all third parties
under the terms of this License.

    c) If the modified program normally reads commands interactively
when run, you must cause it, when started running for such interactive
use in the most ordinary way, to print or display an announcement
including an appropriate copyright notice and a notice that there is
no warranty (or else, saying that you provide a warranty) and that
users may redistribute the program under these conditions, and telling
the user how to view a copy of this License.  (Exception: if the
Program itself is interactive but does not normally print such an
announcement, your work based on the Program is not required to print
an announcement.)

 These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works. But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote
it.

Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Program.

In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.

 3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:

    a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections1
and 2 above on a medium customarily used for software interchange; or,

    b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your cost of
physically performing source distribution, a complete machine-readable
copy of the corresponding source code, to be distributed under the
terms of Sections 1 and 2 above on a medium customarily used for
software interchange; or,

    c) Accompany it with the information you received as to the offer
to distribute corresponding source code. (This alternative is allowed
only for noncommercial distribution and only if you received the
program in object code or executable form with such an offer, in
accord with Subsection b above.)

The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable. However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.

If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.

   4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt otherwise
to copy, modify, sublicense or distribute the Program is void, and
will automatically terminate your rights under this License. However,
parties who have received copies, or rights, from you under this
License will not have their licenses terminated so long as such
parties remain in full compliance.

 5. You are not required to accept this License, since you have not
signed it.  However, nothing else grants you permission to modify or
distribute the Program or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Program or works based on it.

 6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions.  You may not impose any further
restrictions on the recipients' exercise of the rights granted
herein. You are not responsible for enforcing compliance by third
parties to this License.

 7. If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all.  For example, if a patent
license would not permit royalty-free redistribution of the Program by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Program.

If any portion of this section is held invalid or unenforceable under
any particular circumstance, the balance of the section is intended to
apply and the section as a whole is intended to apply in other
circumstances.

It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of any
such claims; this section has the sole purpose of protecting the
integrity of the free software distribution system, which is
implemented by public license practices. Many people have made
generous contributions to the wide range of software distributed
through that system in reliance on consistent application of that
system; it is up to the author/donor to decide if he or she is willing
to distribute software through any other system and a licensee cannot
impose that choice.

This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.

   8. If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Program under this License
may add an explicit geographical distribution limitation excluding
those countries, so that distribution is permitted only in or among
countries not thus excluded. In such case, this License incorporates
the limitation as if written in the body of this License.

 9. The Free Software Foundation may publish revised and/or new
versions of the General Public License from time to time. Such new
versions will be similar in spirit to the present version, but may
differ in detail to address new problems or concerns.

Each version is given a distinguishing version number. If the Program
specifies a version number of this License which applies to it and
"any later version", you have the option of following the terms and
conditions either of that version or of any later version published by
the Free Software Foundation.  If the Program does not specify a
version number of this License, you may choose any version ever
published by the Free Software Foundation.

 10. If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to the
author to ask for permission. For software which is copyrighted by the
Free Software Foundation, write to the Free Software Foundation; we
sometimes make exceptions for this.  Our decision will be guided by
the two goals of preserving the free status of all derivatives of our
free software and of promoting the sharing and reuse of software
generally.

			    NO WARRANTY

 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO
WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE
LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS
AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF
ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MER- CHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE
OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU
ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY
AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU
FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE
PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING
RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A
FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF
SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGES.

		     END OF TERMS AND CONDITIONS 

User-Visible Changes from Release 2.0

Unimplemented Features

(Release 2.0 listed ``simulate compaction-driven fluid flow in basin'' as a desired feature; that has become a distinct, non-Strata program, xflows.)

Mailing Lists

There are two mailing lists associated with Strata. The list strata-admin@geosc.psu.edu is, as the name implies, for administrative matters. The list strata-users@geosc.psu.edu is for all of you out there who are interested enough in Strata to want to hear about any discussion that may go on. (In practice there isn't much.) To be put on it, send mail to strata-admin@geosc.psu.edu.

Strata-users is the appropriate place for questions about other utilities (like xanim or xv) that might be of use, discussion of what other features would be nice to have in and who wants to pay for them, revelation of clever tricks people have come up with, or anything else having to do with Strata. It is also the main forum in which new releases of Strata will be announced.

As the above implies, adding new features to Strata isn't just a matter of coming up with ideas. The programmer (Jamie Morris), living in Cambridge, MA, would be quite happy to add new things to the package, other commitments permitting, but only if someone has the funding. Send mail to strata-admin or to jemorris@mit.edu if interested.

File Formats

If you have or are interested in creating your own basin simulator, and wish to use plotbasin to display its output, your simulator will need to create the same output files as simbasin and in the same formats.

The librarys.out file must contain the following, in ascii, in order, all numbers being separated by whitespace:

The librarydat.out file must contain the following, in ascii, in order, all numbers being separated by whitespace: Each of the files library1.out... library6.out is to be created as per
int i, j, k;
Boolean have_data[7];
FILE *fp;

have_data[0] = TRUE;        /* elevation                                   */
have_data[1] = compaction;  /* porosity, if compaction is on               */
have_data[2] = TRUE;        /* water depth                                 */
have_data[3] = TRUE;        /* max space from neighboring timeline, meters */
have_data[4] = TRUE;        /* prevailing diffusion constant               */
have_data[5] = did_thermal; /* temperature, if thermal calculations done   */
have_data[6] = did_thermal; /* Sum TTI, if thermal calculations done       */

for (i = 0; i < 7; ++i)  /* loop through the data fields */
  if (have_data[i])      /* skip those not calculated */
    for (j = 0; j < number of timelines in this slice; ++j)
      for (k = 0; k < number of spatial nodes; ++k)
        write out datum of field i on timeline j at node k to fp;
where the data should be written as per:
void write_datum(FILE *fp, double x)
{
  Boolean negmantis, negexpon;   /* mantis / exponent negative? */
  unsigned int mantis, expon;
  unsigned char buf[3];
  double y;

  if (negmantis = (x < 0))
    x = -x;
  else if (!x) {
    fwrite("\0\0\0", 1, 3, fp);
    return;
  }

  y = log(x) / .69314718 - 17;   /* binary log(x) = ln(x) / ln(2)  */
  if ((int)y == y) ++y;
  if (negexpon = (y < 0))
    expon = -y;
  else
    expon = y;

  if (expon > 31) 
    if (negexpon) {
      fwrite("\0\0\0", 1, 3, fp);
      return;
    }
    else {
      printf("Simbasin crashes and burns:  can't handle %g (too big)\n", x);
      exit(1);
    }
  
  if (negexpon)
    mantis = x * (1 << expon);
  else
    mantis = ((int)x) >> expon;

  buf[1] = (mantis & 65280) >> 8;
  buf[2] = mantis & 255;

  buf[0] = expon;
  if (negexpon) buf[0] += 32;
  if (negmantis) buf[0] += 64;
  if (mantis & 65536) buf[0] += 128;

  fwrite(buf, 1, 3, fp);
}
That is: each datum is expressed as and written out in three bytes. The first byte gives the exponent (first five bits), whether the exponent is negative (sixth bit), whether the mantissa is negative (seventh bit), and the highest (seventeenth) bit of the mantissa (eighth bit). The second byte gives the ninth through sixteenth bits of the mantissa, and the third byte gives the first eight bits of the mantissa. Anything smaller than this dynamic range is written as zero; anything larger breaks.

Note that the max-space-between-timelines data field is saved in meters, and converted by plotbasin to mm/yr, because the conversion factor of .001 / (years per timeline) is generally enough to make the numbers small enough that they all turn into zeros.

See also simbasin's settime.c.

Interactions via filmbasin are more complex; you'll have to look at filmbasin's specs.h for that information.


This manual was written as part of Basin Research at Penn State.

This page maintained by Steven E. Nelson.