PEST Utilities
for
MODFLOW and MT3D
Parameter Estimation
Watermark Computing
License Conditions
License Conditions
You have the non-exclusive right to use the enclosed Licensed Programs. You may not
distribute copies of the Licensed Programs or documentation to others. You may not
assign sublicence, or transfer this License without the written permission of Watermark
Computing. You may not rent or lease the Licensed Programs without the prior
permission of Watermark Computing. You may not incorporate all or part of the
Licenced Programs into another product for the use of other than yourself without the
written permission of Watermark Computing.
Term
The Licence is effective until terminated. You may terminate it by destroying the
Licensed Programs and documentation and all copies thereof. The Licence will also
terminate if you fail to comply with any term or condition of the Licence. Upon such
termination you must destroy all copies of the Licensed Programs and documentation.
Disclaimer
The user of this software accepts and uses it at his/her own risk.
The authors do not make any expressed of implied warranty of any kind with regard to
this software. Nor shall the authors be liable for incidental or consequential damages
with or arising out of the furnishing, use or performance of this software.
(C) Copyright Watermark Computing, 1994-1998. All Rights Reserved.
Table of Contents
Table of Contents
1. Introduction....................................................................................................................1
1.1 General ....................................................................................................................1
1.2 Installation ...............................................................................................................1
2. MODFLOW and MT3D Parameters..............................................................................3
2.1 Model Data Preparation ..........................................................................................3
2.2 Selection of Parameters for Optimisation ................................................................3
2.3 Model Input Files and Template Files......................................................................4
2.4 Building Template Files ...........................................................................................6
2.5 Working with a MODFLOW/MT3D Preprocessor.................................................8
2.6 Pasting an Array into a MODFLOW Input File.......................................................9
2.7 Multi-Array Parameters and Tied Parameters..........................................................9
2.8 Fixed and Transformed Parameters .......................................................................10
3. Reading Model Outcomes............................................................................................11
3.1 Interpolating Model Outcomes to Bore Locations ................................................11
3.2 MODFLOW and MT3D Output Timing...............................................................11
3.3 MODBORE and MT3BORE Spatial Interpolation...............................................12
3.4 MODBORE and MT3BORE as an Aid to Contouring.........................................14
3.5 Using MODBORE and MT3BORE with PEST ...................................................14
4. Generating the Instruction Set ......................................................................................17
4.1 Reading the Model Output File .............................................................................17
4.2 The Bore Data File ................................................................................................17
4.3 Building the Instruction Set ...................................................................................18
5. Building the PEST Control File ....................................................................................20
5.1 Program MODGEN ..............................................................................................20
5.2 MODGEN Defaults...............................................................................................21
6. Running PEST..............................................................................................................23
6.1 MODFLOW and MT3D Output Files...................................................................23
6.2 Parameter Transformations and Bounds................................................................23
6.3 Cells Going Dry.....................................................................................................24
6.4 If PEST Does Not Work .......................................................................................25
7. Calculating Derivatives.................................................................................................27
7.1 Model Output Precision.........................................................................................27
7.2 MODFLOW..........................................................................................................27
7.3 MT3D....................................................................................................................29
7.4 Derivative Increments............................................................................................31
8. Joint MODFLOW/MT3D Optimisation.......................................................................33
8.1 Optimising Parameters for MODFLOW and MT3D Together .............................33
9. Compiling MODFLOW and MT3D Yourself ..............................................................35
10. References ..................................................................................................................36
Appendix A: Program Descriptions..................................................................................37
A1. ARRAYREP ........................................................................................................37
A1.1 Function of ARRAYREP ..............................................................................37
Table of Contents
A1.2 Command Line ..............................................................................................37
A1.3 The Array File................................................................................................37
A1.4 Locating an Array on a MODFLOW or MT3D Input File ............................38
A1.5 Running ARRAYREP ...................................................................................39
A1.6 The Replaced Array.......................................................................................39
A2. TEXTREP............................................................................................................41
A2.1 Function of TEXTREP..................................................................................41
A2.2 Command Line ..............................................................................................41
A2.3 Discussion......................................................................................................41
A3. MODBORE..........................................................................................................44
A3.1 Function of MODBORE................................................................................44
A3.2 Command Line ..............................................................................................44
A3.3 The Grid Specification File ............................................................................44
A3.4 The Bore Listing File .....................................................................................46
A3.5 The Bore Coordinates File .............................................................................46
A3.6 The Unformatted MODFLOW Output File...................................................46
A3.7 The MODBORE Output File.........................................................................47
A3.8 Compiling Your Own MODBORE ...............................................................48
A4. MT3BORE...........................................................................................................49
A4.1 Function of MT3BORE.................................................................................49
A4.2 Command Line ..............................................................................................49
A4.3 Discussion......................................................................................................49
A5 MODINS...............................................................................................................50
A5.1 Function of MODINS....................................................................................50
A5.2 Command Line ..............................................................................................50
A5.3 The Bore Data File.........................................................................................50
A5.4 The MODBORE or MT3BORE Output File ................................................51
A5.5 The Instruction File........................................................................................52
A6 MODGEN.............................................................................................................53
A6.1 Function of MODGEN..................................................................................53
A6.2 Command Line ..............................................................................................53
A6.3 Discussion......................................................................................................53
A6.4 The Parameter Value File...............................................................................53
A6.5 The Bore Data File.........................................................................................54
A6.6 MODGEN Default Values for PEST Control Variables................................54
A7. COMPFILE..........................................................................................................56
A7.1 Function of COMPFILE................................................................................56
A7.2 Command Line ..............................................................................................56
A7.3 Description.....................................................................................................56
Appendix B. An Example ................................................................................................57
B1.1 The Model ..........................................................................................................57
B1.2 Interpolation to a Set of User-Specified Points...................................................58
B1.3 Preparing for Parameter Optimisation.................................................................58
B1.4 Running PEST ....................................................................................................60
Introduction
1
1. Introduction
1.1 General
This manual documents a number of programs written to facilitate the use of PEST
with the USGS, modular, three-dimensional, finite-difference groundwater model
known as MODFLOW (MacDonald and Harbaugh, 1988) as well as with MT3D
(Zheng and Wang, 1998), the modular, three-dimensional groundwater contaminant
transport model. Seven programs are documented. Three of them (viz. TEXTREP,
MODINS and MODGEN) are used for the automatic generation of PEST input files,
two (viz. MODBORE and MT3BORE) are used for the interpolation of modelgenerated heads, drawdowns and concentrations to user-specified measurement points,
another (viz. ARRAYREP adds flexibility to MODFLOW preprocessing, while the
seventh (viz. COMPFILE) can be used in the construction of a batch file run by PEST
as a composite MODFLOW-MT3D model.
The programs documented in this manual can be used with either or both of
MODFLOW and MT3D. Used in conjunction with PEST, they can facilitate the often
tedious and frustrating task of model calibration. The programs are of most use where
the observation dataset consists of information gathered from a set of monitoring
bores, eg. piezometric levels and solute concentrations. However, while it is not
documented herein, PEST can also be used in more complex calibration problems, for
example where the observation dataset includes measured river/aquifer water and
solute exchanges.
1.2 Installation
Copy file UNWRAP.EXE (a self-extracting archive file) from the "PEST
MODFLOW/MT3D Utilities" disk into a suitable directory on your hard disk (for
example the PEST directory or to a new directory called C:\MODPEST). Next
transfer to this new directory and run the extractor by typing:unwrap -d
A number of files (including a set of executable programs) will be placed into the
directory. A subdirectory named \EXAMPLE will also be created holding the files that
you will need to run the example problem discussed in Appendix B of this manual. So
too will a subdirectory named \SOURCE; this will hold the source code for programs
MODBORE and MT3BORE.
You should add the name of the directory into which the PEST MODFLOW/MT3D
Utilities were installed to the PATH environment variable.
All of the utilities are extended memory programs. However, to save disk space, the
memory extender is not bound to any of the utility programs. Instead, whenever a
utility is invoked, it looks to a program named EXHLD_2 which loads the extender
into memory so that the utility can be run. EXHLD_2.EXE is supplied with the PEST
MODFLOW/MT3D Utilities. It must be placed into a directory that is cited in the
Introduction
2
PATH environment variable. If, as is suggested above, the directory into which the
utilities are installed is added to the PATH, then all of the utilities will run without
problems from whatever subdirectory they are invoked.
MODFLOW and MT3D Parameters
3
2. MODFLOW and MT3D Parameters
2.1 Model Data Preparation
Model calibration is the process of adjusting system properties or inputs, as
represented in a model, until the model generates numbers which replicate an
observation dataset as closely as possible. For a groundwater model the "system" is
one or a number of hydraulically linked aquifers, while the observation dataset usually
consists of water level or concentration measurements taken at a number of bores
scattered throughout the model domain; such measurements may have been taken once
or many times. Groundwater model calibration is justified by the argument that if a
model is able to accurately reproduce an historical dataset, then its predictions of
future aquifer behaviour under a similar or altered regime will also be a good replicate
of groundwater behaviour. While this assumption is sometimes questionable, the
adjustment of a model's parameters in order that it is able to replicate historical aquifer
behaviour is, nevertheless, an important step in the overall construction process.
PEST was built as a model-independent parameter optimiser. As such it can be used to
optimise parameters for MODFLOW and MT3D; parameters can be estimated for a
model consisting of either one of these programs, or of both of them run one after the
other. (Note however that, as explained below, it is better to calibrate each model
independently.) In either case you should prepare for the running of MODFLOW
and/or MT3D in the way that you normally would (except for the setting of one or two
variables governing solution convergence and transport step size - see later). Hence
you may use whatever version of either of these programs that you presently own, and
prepare model input data using your usual model preprocessor. Because PEST was
designed to interface with a model through the latter's own input and output files, you
do not need to construct the linkages between PEST and either of these models until
all model data has been assembled and input files have been prepared.
2.2 Selection of Parameters for Optimisation
Before discussing how to link PEST to MODFLOW and MT3D using the utilities
documented in this manual, it is important to note that, although nonlinear parameter
estimation is a powerful aid to model calibration, it will not work unless conditions are
right. In particular, you should not ask PEST to estimate more parameters than the
observation dataset has the power to provide. A fundamental rule is that the number of
adjustable parameters must not exceed the number of observations. Another rule is that
you should not attempt a detailed parameterisation at places within the model domain
where borehole information is sparse. In such a case, even though the calibrated model
may replicate borehole measurements well, the uncertainties associated with parameter
estimates will be large and model predictions made on the basis of these estimates may
be greatly in error.
Care should be taken to avoid unduly high correlations between parameters. This
occurs when different combinations of parameter values result in almost the same
model outcomes. The result may be instability in the optimisation process and a
MODFLOW and MT3D Parameters
4
slowing or stalling of PEST convergence. Fortunately, ill-defined parameters or groups
of parameters can be easily identified on the PEST run record file by their high
uncertainty levels, large correlation coefficients and high eigenvalues; see the PEST
manual for further details. Once identified, one or more of the offending parameters
should be held fixed and the optimisation process recommenced. In general, the easiest
way to avoid excessive parameter correlation is to keep the number of adjustable
parameters to a minimum.
You should never try to estimate parameter combinations for which there is no unique
solution. For example, for steady-state MODFLOW modelling, if recharge is uniformly
increased by a certain factor, model-generated heads will remain unchanged if
transmissivity is increased by the same factor. Hence it would be a mistake to attempt a
simultaneous estimation of transmissivity and recharge for a steady-state model using
measured water levels as the only observation dataset.
For a transient model it is theoretically possible to estimate two out of three of
transmissivity (or hydraulic conductivity), storage coefficient (or specific yield) and
recharge over the entire model domain if heads and their variations with time are
known everywhere. In practice, however, because water level information is available
only at discrete points and at discrete times, there may not be sufficient information to
estimate two out of three of these parameter types. Hence if you are attempting to
simultaneously estimate more than one parameter type, you should monitor the
solution process carefully for signs of instability.
Similar considerations apply to estimating multiple parameter types for MT3D; here
the problem is exacerbated by the sometimes high field "uncertainly" levels associated
with solute concentration measurements, this "uncertainty" reflecting the role of
geological heterogeneity in violating common assumptions of uniform, or piecewise
uniform, aquifer properties. Also the precision with which MT3D calculates
concentrations may not be sufficient for accurate derivatives calculation (see later), this
leading to estimation convergence problems even if parameters are only moderately
correlated. In general, be careful when trying to simultaneously estimate more than one
type of parameter (for example dispersivity and source concentration) when calibrating
MT3D.
In summary, the fewer parameter types and the less parameter values that you try to
estimate, the better is PEST (or any other optimiser) likely to perform.
2.3 Model Input Files and Template Files
Aquifer properties that may need adjustment during model calibration include
horizontal hydraulic conductivity (or transmissivity), inter-layer conductance, storage
coefficient, streambed or drain conductance and, in the case of transport models,
dispersivity, the parameters defining adsorption isotherms, and solute decay constants.
In other cases it may be necessary to adjust aquifer inputs such as recharge rates and
concentrations, or the parameters governing evapotranspiration. These values are
supplied to MODFLOW and MT3D either through two-dimensional data arrays (for
example hydraulic conductivity and dispersivity), or as cell-by-cell listings (for example
drain and riverbed conductance). All of these parameters are distributed, ie. a value is
MODFLOW and MT3D Parameters
5
required for many (or all) model cells. As it is both practically infeasible and
mathematically impossible to estimate a parameter value for each model cell using
observations made at a discrete number of boreholes, these distributed parameters
must be "regularised" in some way. The easiest way to do this is to assume that any
such parameter type is "piecewise constant", ie. that it takes on a single value in each
of a number of discrete model sub-areas within the overall model domain.
PEST interfaces with a model through the latter's own ASCII input and output files.
Each time it runs a model it first writes user-specified model input files using the set of
parameter values which it wishes the model to use on that particular run. It knows
where to write parameter values to input files through the use of model input file
templates. For PEST to adjust a distributed parameter supplied to MODFLOW or
MT3D through a two-dimensional array or cell-by-cell listing, a template must be
constructed for the file which holds the array or listing. This is usually done by
modifying a model input file, replacing numbers written by the model preprocessor
with "parameter spaces" (comprising a parameter name enclosed by appropriate
delimiters). Each parameter space denotes a contiguous set of characters on the model
input file as belonging to a particular parameter; it also informs PEST of the number of
digits which it may use to write the number representing the parameter.
For a spatially distributed parameter occupying a two-dimensional array the model
domain must be subdivided into a handful of zones of parameter constancy. If each
number comprising the array is replaced by an appropriate parameter space, the array
of numbers as represented in the model input file becomes an array of parameter
spaces. Each zone of parameter constancy within the array is then identified as having
the same parameter name.
Example 2.1 illustrates a two-dimensional array of numbers subdivided into four zones
while Example 2.2 shows part of a template file constructed from it. Before PEST runs
the model, it replaces the parameter spaces found on the template file by the current
values pertaining to those parameters, thus building an array consisting of four
separate numbers and defining four separate zones of parameter constancy.
1.2345
1.2345
1.2345
1.2345
1.2345
8.4352
8.4352
8.4352
8.4352
1.2345
1.2345
1.2345
1.2345
1.2345
1.2345
8.4352
8.4352
8.4352
1.2345
1.2345
1.2345
1.2345
1.2345
1.2345
1.2345
8.4352
8.4352
1.2345
1.2345
9.6521
9.6521
9.6521
9.6521
9.6521
9.6521
8.4352
1.2345
1.2345
9.6521
9.6521
9.6521
9.6521
9.6521
9.6521
9.6521
6.7543
6.7543
6.7543
9.6521
9.6521
9.6521
9.6521
9.6521
9.6521
6.7543
6.7543
6.7543
6.7543
9.6521
9.6521
9.6521
9.6521
9.6521
6.7543
6.7543
6.7543
6.7543
6.7543
9.6521
9.6521
9.6521
9.6521
Example 2.1 A two-dimensional array comprised of four different numbers.
MODFLOW and MT3D Parameters
#
#
#
#
#
#
#
#
#
par1
par1
par1
par1
par1
par4
par4
par4
par4
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
par1
par1
par1
par1
par1
par1
par4
par4
par4
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
par1
par1
par1
par1
par1
par1
par1
par4
par4
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
6
par1
par1
par3
par3
par3
par3
par3
par3
par4
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
par1
par1
par3
par3
par3
par3
par3
par3
par3
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
par2
par2
par2
par3
par3
par3
par3
par3
par3
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
par2
par2
par2
par2
par3
par3
par3
par3
par3
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
par2
par2
par2
par2
par2
par3
par3
par3
par3
#
#
#
#
#
#
#
#
#
Example 2.2 A two-dimensional array comprised of four different parameter spaces.
For parameters supplied to MODFLOW or MT3D on a cell-by-cell basis a similar
subdivision of the listed cells into groups of cells of parameter constancy may be made.
Example 2.3 shows part of the input file for the MODFLOW drain package while
Example 2.4 shows part of the template file constructed from it. The drain has been
subdivided into two zones in each of which the conductance is assumed uniform. (Note
that this parameterisation scheme for drain conductance can be improved; see Section
2.7.)
1
1
1
1
1
1
1
1
1
1
1
1
1
19
20
21
22
23
24
25
26
27
28
29
30
31
43
43
43
44
45
46
46
46
46
45
44
43
43
2.000E+01
2.000E+01
2.000E+01
2.000E+01
2.000E+01
2.000E+01
2.000E+01
2.000E+01
2.000E+01
2.000E+01
2.000E+01
2.000E+01
2.000E+01
3.000E+00
3.000E+00
3.000E+00
3.000E+00
3.000E+00
5.000E+00
5.000E+00
5.000E+00
5.000E+00
5.000E+00
5.000E+00
5.000E+00
5.000E+00
Example 2.3 Part of the input to MODFLOW's DRN package.
1
1
1
1
1
1
1
1
1
1
1
1
1
19
20
21
22
23
24
25
26
27
28
29
30
31
43
43
43
44
45
46
46
46
46
45
44
43
43
2.000E+01
2.000E+01
2.000E+01
2.000E+01
2.000E+01
2.000E+01
2.000E+01
2.000E+01
2.000E+01
2.000E+01
2.000E+01
2.000E+01
2.000E+01
#
#
#
#
#
#
#
#
#
#
#
#
#
con1
con1
con1
con1
con1
con2
con2
con2
con2
con2
con2
con2
con2
#
#
#
#
#
#
#
#
#
#
#
#
#
Example 2.4 Part of a template file based on Example 2.3
2.4 Building Template Files
To prepare a template for a model input file holding a distributed parameter, you must
MODFLOW and MT3D Parameters
7
first prepare the model input file using your usual MODFLOW or MT3D
preprocessor. When filling an array or cell-by-cell listing for a parameter type to be
optimised, subdivide the parameter domain into a discrete number of zones, assigning a
different parameter value to each zone. When you have finished MODFLOW or
MT3D data input, have the preprocessor write the model input file in the usual way.
Then construct the template file by first copying, and then modifying, the model input
file containing the parameter type to be optimised, replacing each zone-defining
number in the pertinent array or cell-by-cell listing by a corresponding parameter
space, thus building an array or listing consisting of parameter spaces.
For example, suppose that you wish to optimise hydraulic conductivity and that your
preprocessor has written the conductivity array to a file named BCF.DAT as part of
the normal dataset required by the MODFLOW "Block Centred Flow" package. To
prepare a template file named BCF.TPL from BCF.DAT, it is a simple matter to copy
BCF.DAT to BCF.TPL, add a template file header (eg. "ptf &", "&" being the
parameter delimiter) and use the "search and replace" facilities of a text editor to
replace each occurrence of each zone-defining number in the hydraulic conductivity
array by an appropriate parameter space to produce an array like the one shown in
Example 2.2.
Unfortunately this process is not always as simple as it sounds. MODFLOW and
MT3D input files can be very large and your text editor may not be able to read them.
Also, it is sometimes difficult to ensure that the succession of "search and replace"
commands by which an array or listing of numbers is transformed into an array or
listing of parameter spaces does not extend beyond the target area into a section of the
MODFLOW/MT3D input file that should be left untouched. Furthermore, next time
you use your preprocessor to alter an array or cell-by-cell listing, moving zone
boundaries and maybe adding a few more zones, these difficulties will be repeated
when the new template file is constructed from the input file.
Program TEXTREP has been written to circumvent these problems; its use is fully
described in Appendix A2 of this manual. If you supply TEXTREP with an easilyprepared "text replacement file" listing (a) the numbers to look for in a model input
file, (b) the parameter space identifiers with which to replace those numbers, and (c)
the line numbers between which to undertake each such replacement, TEXTREP will
read a model input file and write a corresponding template file by carrying out the
replacements set out in the text replacement file. You should be able to obtain the
relevant line numbers from a text editor or viewer. There are quite a number of easilyacquired editors or viewers (available at very little price) which are capable of reading
extremely large text files. Two such programs are:
LIST by Vernon D. Buerg, 139 White Oak Circle, Petaluma CA 94952.
and
BINGO by Christopher R. S. Schanck, PO Box 279, Hanover MD 21076.
Consult any shareware catalogue to find more.
MODFLOW and MT3D Parameters
8
When building an array or listing of parameter spaces from an array or listing of
numbers, caution must be exercised in handling those parts of the array or listing that
lie wholly within an inactive model region (ie. a region for which MODFLOW
IBOUND array elements or MT3D ICBUND array elements are zero). If a parameter
zone lies wholly within an inactive part of the grid then you may wish to leave it
unaltered when building the model template file, ie. substitute no parameter spaces for
numbers within this zone. Alternatively, hold the pertinent parameter fixed during the
optimisation process, as it will have no effect on model outcomes. (If you forget to do
this, PEST will soon remind you.)
After a template file has been built, you can check its integrity using the PEST utility
TEMPCHEK; see the PEST manual.
2.5 Working with a MODFLOW/MT3D Preprocessor
Sometimes the parameter values that you supply to a model preprocessor are not
actually reproduced on the model input file written by the preprocessor. In some cases
the zonation defined by subsections of parameter constancy within a parameter array
may even be lost. To the unwary, this may cause problems when easily-identified
numbers are supplied to a particular array with the aim of replacing those numbers
later by parameter spaces on the model input file generated by the preprocessor.
MODFLOW defines four different types of model layers using its LAYCON vector. If
the LAYCON element for a layer is 0 or 2, MODFLOW expects a transmissivity array
for that layer. However if the LAYCON element is 1 or 3, MODFLOW expects a
hydraulic conductivity array. Some MODFLOW preprocessors accept only hydraulic
conductivity; if a layer is of type 0 or 2 they multiply the hydraulic conductivity by
layer thickness to obtain transmissivity which is then transferred to the MODFLOW
input file. Hence user-supplied cell hydraulic conductivity values are not replicated on
the MODFLOW input file generated by the preprocessor. Furthermore, if the layer
thickness is irregular, the transmissivity array will not be piecewise constant even if the
hydraulic conductivity was entered in zones of constant value. In such a case it is
better to supply a uniform aquifer thickness to the preprocessor even if the aquifer
thickness is, in fact, variable. For layers of type 0 or 2 this inaccuracy will not degrade
model results as it is the transmissivity, and not the hydraulic conductivity and layer
thickness individually, which determines the flow regime within the aquifer.
A similar problem can occur with layer storage capacity. Some preprocessors request a
volumetric storage coefficient, multiplying the coefficient by the aquifer thickness to
determine the layer storage capacity. In this instance, too, the numbers supplied to a
preprocessor will not be replicated on the model input file generated by the
preprocessor. Similar considerations apply to the "vertical hydraulic conductivity
divided by thickness" array required by MODFLOW for multi-layered models.
Note that only arrays and cell-by-cell parameter value listings containing adjustable
parameters need to be transformed when constructing a template file. Arrays and
listings for which parameter optimisation is not sought should be represented on the
template file unaltered. Similarly, if parameter optimisation is sought for only part of a
model domain, then only part of an array or listing needs to have its elements replaced
MODFLOW and MT3D Parameters
9
by parameter spaces when constructing the template file.
2.6 Pasting an Array into a MODFLOW Input File.
Program ARRAYREP was written to assist in overcoming difficulties outlined in the
preceding section that may arise in constructing PEST template files when using certain
popular MODFLOW and MT3D graphical preprocessors.
Where it is not possible to construct MODFLOW input files that reflect user-intended
parameter zonation ARRAYREP allows a user to replace an array found in a MODFLOW
(or MT3D) input file by another, model-compatible, array stored in a separate file. If the
latter array is zoned according to a user's specifications, TEXTREP can be used to produce
an appropriately zoned PEST template file. ARRAYREP is then run prior to MODFLOW
as part of a composite model encapsulated in a batch file.
As another option, program INT2REAL from the “Groundwater Data Utilities” (Doherty,
1996) can be used to build a real array on the basis of zonation defined in an integer array
using adjustable hydraulic conductivities referenced in an “integer real correspondence file”,
for which a PEST template file is very easily constructed. On each occasion that
MODFLOW is run, the hydraulic conductivity array is constructed anew and pasted into
the MODFLOW BCF package input file using ARRAYREP (which is also run as part of
the composite model). More sophisticated pre-processing may allow an array to be built on
the basis of certain points within the model domain from which values are assigned to grid
cell centres using a spatial interpolation algorithm such as krigging. Parameter values at the
control points can then be estimated using PEST.
2.7 Multi-Array Parameters and Tied Parameters
There is no reason why the occurrence of a particular parameter should be restricted to
a single array or table. For example if a single, vertically homogeneous aquifer is
represented by a number of model layers, the arrays representing the hydraulic
conductivity of each model layer will be identical. In such a case the parameter space
arrays on the corresponding template file will also be identical, each such array
containing the same parameters in the same disposition. The "vertical hydraulic
conductivity over thickness" arrays for model layers within the same aquifer will also
be identical from layer to layer (if the layer thicknesses are the same). The pertinent
parameter values may be estimated separately from hydraulic conductivity, or they may
be tied to the latter (see the PEST manual) if the relationship between vertical and
horizontal hydraulic conductivity is known. In the latter case, only the horizontal
hydraulic conductivity needs to be estimated, the estimates for "vertical hydraulic
conductivity over thickness" tracking the horizontal values as the optimisation process
progresses.
Similarly, for parameter types such as drain conductance illustrated in Example 2.3, it
may be opportune to define a number of parameters over the model domain, the choice
of which parameter pertains to each drain cell being governed by the length of the
drain in that cell. On the assumption that the hydraulic conductivity of the material
connecting the drain to the aquifer is uniform, the conductance in a particular cell will
then be proportional to the length of drain in that cell. Hence, during the optimisation
MODFLOW and MT3D Parameters
10
process, only one conductance parameter needs to be optimised, the others being tied
to it in proportion to the respective length category represented by each parameter.
2.8 Fixed and Transformed Parameters
If a parameter name appears in a template file, that same parameter name must also
appear in the PEST control file; see the PEST manual for details. Through the PEST
control file PEST is informed whether each parameter is adjustable, fixed, or tied to
another parameter, and whether or not a parameter is logarithmically transformed
throughout the parameter estimation process. Information is also supplied on how
observation derivatives with respect to adjustable parameters are to be calculated.
As has already been mentioned, a parameter must be fixed if it lies wholly within the
inactive part of the model grid and hence has no effect on model outcomes. A
parameter should also be fixed if its effect on model outcomes at all observation points
is particularly weak. Likewise, if a group of highly correlated parameters is identified,
then at least one member of this group may need to be fixed in order to enhance
optimisation stability while assisting in the efficient estimation of the remaining
members of the group.
The logarithmic transformation of certain parameter types may have a dramatic effect
on optimisation efficiency. This is discussed in Section 6.2, as is the necessity of
adopting appropriate upper and lower bounds for all adjustable parameters.
Reading Model Outcomes
11
3. Reading Model Outcomes
3.1 Interpolating Model Outcomes to Bore Locations
In many cases of interest the information used for groundwater model calibration
consists of water level or solute concentration measurements made at a number of
boreholes scattered throughout the model domain. The suite of borehole observations
may consist of measurements made at a single time, or of measurements taken over a
considerable time period. In either case model calibration requires the adjustment of
model parameters until the water levels or concentrations generated by the model at
these borehole locations correspond as closely as possible with those actually
observed.
Unfortunately neither MODFLOW nor MT3D interpolates its calculated head or
concentration arrays to user-specified bore locations. Hence two programs were
developed (and are documented herein) to undertake the necessary interpolation, viz.
MODBORE for MODFLOW head and drawdown interpolation, and MT3BORE for
MT3D concentration interpolation. Use of the two programs is almost identical and is
described in Appendix A3.
As is explained in the PEST manual, it is essential for good PEST performance that
model-calculated numbers corresponding to field observations be written to model
output files with the maximum possible precision; this assists in the accurate
calculation of derivatives of these numbers with respect to adjustable parameters. Both
MODBORE and MT3BORE follow this principle, recording interpolated heads and
concentrations using the maximum number of significant figures that single precision
arithmetic allows.
MODBORE and MT3BORE obtain the heads, drawdowns and concentrations
calculated by MODFLOW and MT3D by reading the unformatted head, drawdown or
concentration files produced by these models. (Thus model outcomes are handed to
these interpolation programs with no loss in precision.) These unformatted files contain
a head or drawdown array (for MODFLOW) or a concentration array (for MT3D)
pertaining to at least one model layer for one or a number of user-specified simulation
times.
Hence the "model" run by PEST actually consists of at least two programs. For
MODFLOW calibration the model consists of MODFLOW followed by MODBORE;
for MT3D calibration the model consists of MT3D followed by MT3BORE. For joint
MODFLOW/MT3D calibration the model consists of MODFLOW followed by
MODBORE followed by MT3D followed by MT3BORE. In each case PEST runs a
batch file as the model which runs each of these programs in turn.
3.2 MODFLOW and MT3D Output Timing
Both MODBORE and MT3BORE interpolate all arrays found in the MODFLOW or
MT3D unformatted output file to a set of user-specified bore locations. For the
Reading Model Outcomes
12
purposes of model calibration using borehole measurements, it is important to ensure
that at least some of the arrays generated by MODFLOW or MT3D correspond to
times at which borehole observations were made. Note, however, that for steady-state
MODFLOW modelling heads are written at only one simulation time, viz. at the end of
the steady-state simulation. (Even though steady-state heads are independent of time, a
user is able to specify an elapsed time to which such heads pertain; this may be
important if MT3D is run based on MODFLOW results.) Hence for steady-state model
calibration, only one head or drawdown observation can be used for each borehole.
MODFLOW is able to generate unformatted output at the end of each time step.
Whether it does so or not depends on the settings supplied to its Output Control
package. Settings supplied to this package also determine whether output is provided
for all model layers or only specified layers.
To facilitate use, many MODFLOW preprocessors do not present the user with the full
suite of output options, presenting him/her with a subset of these options instead;
preprocessor-specific default values are then provided for the remaining options. If
these defaults preclude the saving of data at all times for which you have field
measurements, you may need to edit one of the MODFLOW input files generated by
your preprocessor directly. The required alterations must be made to the input file for
the "Output Control" package, the positions at which these alterations are required
being clearly labelled on the MODFLOW input files generated by many preprocessors.
See the MODFLOW manual for details.
The situation is a little different for MT3D which provides three options for the timing
of unformatted concentration output. The appropriate option is selected through the
input variable NPRS. Concentrations can be saved every ABS(NPRS) transport steps
(NPRS<0), at user-specified times (NPRS>0), or at the end of the simulation only
(NPRS=0). When using MT3D in conjunction with PEST, NPRS should be set at
greater than 0, and the set of simulation times provided to MT3D for which
unformatted concentration output is required; at least some of these times must
correspond to borehole measurement times.
Note that new software provided as part of the Groundwater Data Utilities suite
(Doherty, 1996) carries out temporal as well as spatial interpolation. This removes the
necessity for model output times to correspond to observation times.
3.3 MODBORE and MT3BORE Spatial Interpolation
MODBORE and MT3BORE employ the same bilinear interpolation scheme to
calculate values pertaining to user-specified points from those stored in grid-based
arrays. For each user-specified point, the four cell centres surrounding that point are
first determined; the heads, drawdowns or concentrations at those cell centres are then
interpolated to the point. If the four surrounding cell centres have row and column
numbers (i,j), (i+1,j), (i,j+1) and (i+1,j+1), the head at the user-specified point is
calculated as:
Reading Model Outcomes
h=
13
x2 y 2 hi, j + x1 y 2 hi, j+1 + x 2 y1 hi+1, j + x1 y1 hi+1, j+1
XY
where:
hi,j is the head at the centre of cell (i,j),
x1 = xp - xi,j
x2 = xi,j+1 - xp
y1 = yi,j - yp
y2 = yp - yi+1,j
X = xi,j+1 - xi,j
Y = yi,j - yi+1,j
(xp,yp) are the x and y coordinates of the measurement point, and
(xi,j,yi,j) are the x and y coordinates of the centre of cell (i,j).
In the above expression all coordinates are expressed in a Cartesian system where the x
direction corresponds to the positive row direction (ie. the direction of increasing
column index) and the y direction corresponds to the negative column direction (ie. the
direction of decreasing row index). Note that no interpolation takes place in the
vertical (ie. inter-layer) direction.
The above interpolation scheme is slightly modified if a bore falls close to the edge of
the model grid and is thus not surrounded by four cell centres. Similarly, if not all of
the cells surrounding a bore are active, an appropriate modification is introduced to the
interpolation equation. (MODFLOW and MT3BORE know what cells are inactive
because their input dataset includes the values that MODFLOW assigns to inactive
cells [HNOFLO] and dry cells [HDRY], or the value that MT3D assigns to inactive
concentration cells [CINACT].) If a bore lies within an inactive or dry cell, or is
outside the grid altogether, an appropriate descriptor is written to the head or
concentration field of the MODBORE or MT3BORE output file; see Appendix A3.
For spatial interpolation to be possible, the geographic locations of both the bores and
the finite difference grid must be provided. MODBORE and MT3BORE read the
former from a "bore coordinates file" which lists the eastings and northings of all bores
to which interpolation must take place. Also provided is the model layer number to
which each bore pertains. Neither MODBORE nor MT3BORE interpolates a
MODFLOW or MT3D array to a bore that does not tap that array.
Reading Model Outcomes
14
Grid specifications are provided to MODBORE and MT3BORE though a "grid
specification file" whose format is set out in Appendix A3. This file lists the number of
rows and columns in the grid, the disposition of the grid row (ie. the x) direction with
respect to east, and the row and column widths of all cells (ie. the MODFLOW DELR
and DELC vectors). The latter can be pasted straight from the appropriate
MODFLOW input file or, if they are uniform or piecewise uniform, written in
contracted form suitable for FORTRAN list-directed input; see Appendix A3.
3.4 MODBORE and MT3BORE as an Aid to Contouring
MODBORE and MT3BORE read a MODFLOW or MT3D unformatted output file in
its entirety, interpolating each two-dimensional array that they encounter to all bores
which tap that array. For each MODFLOW or MT3D output time there may be many
saved arrays, one corresponding to each model layer. After it has read and interpolated
all the arrays pertaining to a particular output time, MODBORE and MT3BORE
append to their output file a list of all bores provided in a "bore listing file" (a
MODBORE/MT3BORE input file), the eastings and northings of these bores (read
from the bore coordinates file) and the heads, drawdowns or concentrations calculated
for them by array interpolation. At the top of each such list is a header documenting
the stress period, time or transport step, and the elapsed simulation time; see Example
A3.4.
If there is more than one MODFLOW or MT3D output time, the MODBORE or
MT3BORE output file consists of a number of these tables in succession. If you wish
to generate a contour map of model-generated heads or concentrations from one of
these tables, it is a simple matter to extract the table of interest from the MODBORE
or MT3D output file and supply it to a commercial contouring package. Such a
contour map can prove very useful in model calibration. If a contour map generated
from model-calculated heads, drawdowns or concentrations in this manner is compared
with a contour map generated from field data taken at the same bores, a direct
comparison can be made between model and field data in a spatial setting. Because
both sets of contours are based on the same set of points, idiosyncrasies of the
contouring package affect model and field contours in the same manner.
3.5 Using MODBORE and MT3BORE with PEST
When calibrating MODFLOW, it is the MODBORE output file which PEST must
read. This file contains the model-calculated head (or drawdown) interpolated to each
bore cited in the "bore listing file" at each simulation time for which MODFLOW
wrote an unformatted two-dimensional array. Each head is written to that file with the
maximum precision allowed by single-precision arithmetic so that derivatives of these
borehole-interpolated heads with respect to adjustable parameters can be calculated by
PEST with the maximum accuracy. Your observation dataset should consist of heads
measured at some or all of the bores listed in the MODBORE output file at one or
more of the simulation times cited in that file. PEST must then be provided with
instructions on how to find the corresponding model-calculated heads on the
MODBORE output file. As is explained below, this can be done automatically with the
aid of program MODINS, one of the PEST utilities documented in this manual; see the
Reading Model Outcomes
15
next chapter.
Similarly, if you are calibrating MT3D, your observation dataset may consist of
concentrations measured in some or all of the bores listed in the MT3BORE output file
at one or more of the times corresponding to MT3D unformatted output. Once again,
you must provide a set of instructions to read the MT3BORE output file for the
corresponding model-calculated concentrations. This is also easily achieved with the
help of program MODINS.
Unlike the other utilities documented in this manual, neither MODBORE nor
MT3BORE is able to receive its run-time data through the command line. There are
two reasons for this. The first is that the respective command lines would be long and
awkward. The second is that if you are not using a Lahey-compiled version of
MODFLOW or MT3D (many commercial and public domain executable versions of
these programs are, in fact, compiled by a Lahey compiler) MODBORE and
MT3BORE will need to be recompiled. This is because the FORTRAN unformatted
files written by one program are not, in general, readable by another program compiled
by a different compiler. Unfortunately the reading of command line arguments also
differs from compiler to compiler.
MODBORE and MT3BORE receive their input data through user keyboard entry in
response to screen prompts issued by these programs. While this works fine when
MODBORE or MT3BORE is run from the terminal, it is obviously unworkable if
these programs are run by PEST. To overcome this problem you should enter your
answers to the MODBORE or MT3BORE prompts to a file (using any text editor) and
re-direct this file as MODBORE or MT3BORE input using the "<" symbol on the
MODBORE or MT3BORE command line. By way of example, suppose that running
MODBORE from the terminal results in the following screen display as data is entered
through the keyboard:
Enter the names of the following MODBORE input files:grid specification file:
example.spc
bore listing file:
bores.lst
bore coordinates file:
bores.crd
unformatted MODFLOW output file:
heads.dat
how many arrays are expected in this file?
12
enter the value designating an inactive cell:
999.99
enter the value designating a dry cell:
999.99
Provide a name for the MODBORE output file:
heads.tab
Then you (and PEST) can run MODBORE without keyboard data entry using the
command:
modbore < modbore.in
where MODBORE.IN is a file containing the following lines:
example.spc
bores.lst
bores.crd
heads.dat
12
999.99
999.99
heads.tab
Reading Model Outcomes
16
Similar considerations apply to running MT3BORE. A suitable batch file for PEST to
use during MODFLOW calibration is then:
modflow
modbore < modbore.in
assuming that MODFLOW is run using the command “modflow”. If MODFLOW
requires keyboard entry, this too can be written to a file and supplied through
command-line redirection. Thus if MODFLOW's input requirements are written to a
file named MODFLOW.IN the above batch file would become:
modflow < modflow.in
modbore < modbore.in
If you wish that no MODFLOW or MODBORE output be directed to the screen so
that only PEST's screen output will be visible, this file can be further modified to:
@echo off
modflow < modflow.in > nul
modbore < modbore.in > nul
Similarly, PEST can run the composite MT3D model through the batch file:
@echo off
mt3d < mt3d.in > nul
mt3bore < mt3bore.in > nul
These batch files will be improved in Chapter 7.
Generating the Instruction Set
17
4. Generating the Instruction Set
4.1 Reading the Model Output File
A MODBORE output file is shown in Example A3.4; MT3BORE output files are
almost identical. As was discussed in the previous chapter, it is these files which must
be read by PEST in order to obtain those model-generated numbers for which there are
complementary borehole observations. Hence an instruction set must be constructed to
allow PEST to read them. The specifics of the instruction set will depend on the times
at which borehole water level and/or solute concentration measurements were
acquired, and the bores that they were acquired from. It should be noted that it is not
necessary that there be a borehole measurement for every bore and time cited in a
MODBORE or MT3BORE output file; however any borehole water level or
concentration measurement used for calibration must correspond to a bore and elapsed
simulation time cited in a MODBORE or MT3BORE output file. (As mentioned in the
previous chapter, new software supplied with the Groundwater Data Utilities removes
this limitation; contact the author of this manual for more information.)
Because of the simple manner in which data is arranged in these files, they are easy to
read. Heads and concentrations are listed in columns; hence an individual value can be
read as a "fixed" observation (see the PEST manual). Fixed observations can be read
faster than semi-fixed or non-fixed observations as their position is defined exactly in
the instruction by which they are read.
An instruction set for reading a MODBORE or MT3BORE output file in a manner
that is appropriate for the observation dataset to be used in model calibration is most
easily generated using program MODINS. MODINS is fully described in Appendix
A5.
4.2 The Bore Data File
Before MODINS is run, you must prepare one or more "bore data files" containing the
measurement dataset to be used in model calibration; see Example A5.1. If your
borehole information consists simply of water level data or of concentration data then
only one bore data file needs to be prepared. However if you have acquired both head
and concentration data, then two bore data files must be prepared, one for each data
type.
Each line of a bore data file contains a bore identifier followed by an elapsed simulation
time, followed by an observation value (eg. water level or concentration value),
observation weight and observation name. The bore identifier is used to match a bore
with its counterpart in a MODBORE or MT3BORE output file. The elapsed
simulation time is the time at which the measurement was taken relative to the start of
the simulation; this must correspond exactly to an elapsed time appearing in the header
to a MODBORE or MT3BORE output file data section, and thus to a time at which
MODFLOW or MT3D saved unformatted head, drawdown or concentration data.
Through the bore identifier and elapsed simulation time, each measurement recorded in
Generating the Instruction Set
18
a bore data file can be linked to a model-generated number on the MODBORE or
MT3BORE output file. If a match cannot be found, MODINS will be unable to build
an instruction to read the required model-generated number from the MODBORE or
MT3BORE output file and will generate an appropriate error message.
For a steady state simulation there will be only one MODFLOW output time. While
steady state results pertain to no time in particular, there is, in fact, a particular elapsed
time recorded on the MODBORE output file (this elapsed time was supplied as
MODFLOW input data); this same time must be used in the bore data file when
preparing for MODFLOW steady state model calibration.
As mentioned above, the fourth column of a bore data file lists observation weights.
The subject of observation weighting is treated in detail in the PEST manual. In
general, each weight should be inversely proportional to the standard deviation of the
observation to which it pertains; more "believable" observations should be assigned
greater weights.
In cases where all observations are of the same type and carry equal weight, a uniform
weight of 1.0 can be used. Care must be taken, however, where the parameter
estimation process relies on the use of two different types of data. This will occur
where both MODFLOW and MT3D are being run in sequence as a composite model
for which parameters are being estimated using both head and concentration data
simultaneously (not a recommended procedure - see Section 7.3). In this case it may
be advisable to assign all head measurements a certain weight and all concentration
measurements another weight. However care must be taken in deciding on the relative
values of these two weights. One approach is to choose the two weights such that the
contribution of the head residuals to the overall objective function is about the same as
the contribution of the concentration residuals. (If you assign these two observation
sets to two different observation groups, PEST will list the contribution made by each
set to the overall objective function.) However in many cases you may wish to increase
the weight applied to the heads, as concentration measurements may be more subject
to the effects of local geological heterogeneity than head measurements. Furthermore,
for reasons outlined in Section 7.3 of this manual, MT3D may not be able to calculate
concentrations with as much precision as MODFLOW is able to calculate heads when
both are run in sequence. Hence it may be better to give more weight to the heads, as
this will enhance optimisation efficiency.
The final entry on each line of the bore data file is the observation name. As explained
in the PEST manual, each observation must be assigned a unique name of eight
characters or less. This user-supplied name identifies the observation on PEST input
files, instruction files, and on the PEST run record file.
4.3 Building the Instruction Set
If you are calibrating both MODFLOW and MT3D (either in separate PEST runs or in
a single PEST run), a separate bore data file must be used for head (or drawdown)
data and concentration data. This is because two different files need to be generated by
MODINS, one containing the instructions to read the MODBORE output file, the
other containing the instructions to read the MT3BORE output file. However if you
Generating the Instruction Set
19
are calibrating only one of MODFLOW or MT3D, only a single bore data file needs to
be constructed tabulating either your bore-measured water levels or solute
concentrations.
When MODINS is invoked to write an instruction set it must be provided with the
name of a bore data file and a MODBORE or MT3BORE output file. By matching
bores and times on the bore data file to bores and times on the MODBORE or
MT3BORE output file, it generates the instructions by which these latter files can be
read for model-generated heads, drawdowns or concentrations corresponding to the
field observations. If a bore or elapsed time appears in a bore data file which does not
appear on the MODBORE or MT3BORE output file, an error condition will occur and
the instruction set will not be generated.
Once the instruction set has been generated, PEST is able to read the output file
written by the composite MODFLOW/MODBORE or MT3D/MT3BORE model.
Note, however, that you must be very careful not to alter the bore listing file read by
MODBORE and/or MT3BORE before running PEST. If you do alter this file you
must immediately run MODBORE or MT3BORE to generate another output file and
then re-run MODINS to generate a new instruction set. (Remember that all bores cited
in the bore listing file appear on the MODBORE or MT3BORE output file.)
Building the PEST Control File
20
5. Building the PEST Control File
5.1 Program MODGEN
Chapter 2 of this manual described how to construct template files in which parameters
are identified on model input files. Composite MODFLOW/MODBORE and
MT3D/MT3BORE "models" were discussed in Chapter 3, while Chapter 4
documented the means to generate an instruction set to read the outputs of these
models. All that now remains to complete preparation for a PEST run is the
construction of a PEST control file. The role and contents of this file are described in
detail in the PEST manual.
Construction of the PEST control file is normally a three-stage process. It commences
with the use of PESTGEN to generate a PEST control file specific to the current
parameter estimation problem, but with default values assigned to many of the PEST
control variables. This file must then be modified by the user (either directly with a text
editor, or through using the PEST pre-processor PREPEST) so that it is just right for
the case in hand. The final stage of PEST preparation is the running of program
PESTCHEK to verify that the entire PEST input dataset is consistent and correct.
While PESTGEN can be used to generate a PEST control file for MODFLOW and/or
MT3D parameter estimation, it is better to use a modification of PESTGEN named
MODGEN when calibrating these models, for MODGEN is able to construct a PEST
control file slightly more suitable for MODFLOW/MT3D parameter estimation.
MODGEN is described in detail in Appendix A6 of this manual.
Like PESTGEN, MODGEN requires as one of its inputs a parameter value file. This is
a file listing the names, initial values, scales and offsets of all parameters used in the
optimisation process. It is described in detail in the PEST manual. If any parameters
are missing, or if a parameter is listed which does not appear in a template file,
PESTCHEK (or PEST itself) will soon detect the inconsistency.
PESTGEN must also read an observation value file, from which it obtains the names
and measurement values of all observations which form the basis of the parameter
estimation process. However MODGEN reads a bore data file to obtain the same
information. MODGEN is able to read either one or two bore data files. For the usual
case of individual MODFLOW or MT3D parameter estimation it needs to read only
one such file containing observed head or concentration values respectively. However
if a joint MODFLOW/MT3D calibration is attempted, MODGEN should read two
bore data files, one containing measured head values and the other containing
measured concentration values so that it can include the measured values pertaining to
both observation sets on the PEST control file which it builds. Note that MODGEN
must read the same bore data file(s) that were provided to MODINS to generate the
instruction set(s).
Unlike an observation value file, the bore data file contains observation weights; see
Example A5.1. MODGEN includes these weights in the PEST control file.
Building the PEST Control File
21
5.2 MODGEN Defaults
The operation of MODGEN is similar to that of PESTGEN in many respects. In
particular, it assigns each parameter to a parameter group of its own, and most of the
PEST control variables are assigned the same values as PESTGEN does. However it
differs from PESTGEN in the lower bound and transformation settings that it assigns
to the parameters featured in the PEST control file.
PESTGEN assumes that each parameter is untransformed in the estimation process,
10
that its lower bound is -1.0 × 10 , and that the changes it undergoes from iteration to
iteration are relative-limited. MODGEN, on the other hand, takes the point of view
that if an initial parameter value (as supplied in the parameter value file) is positive,
that parameter should be log-transformed during the parameter estimation process,
-10
that its lower bound is 1.0 × 10 , and that its changes are factor-limited. It takes this
view because a number of parameter types of interest in groundwater model calibration
are more efficiently estimated if they are log-transformed (see Section 6.2 below).
The assignment of each parameter to its own group may be inconvenient because, in
general, it is better for parameters of the same type to belong to the same group.
However MODGEN does not know which parameters are of the same type, so it is up
to the user to re-assign parameters to fewer groups as appropriate. This can be
achieved either by directly editing the PEST control file or by using PREPEST. If you
choose the former method you should:
1. delete all unnecessary groups from the "* parameter groups" section of the PEST
control file,
2. assign all parameters in the "* parameter data" section of the PEST control file to
the remaining groups, and
3. reduce the value of the control variable NPARGP to the number of remaining
groups; NPARGP is the third variable on the fourth line of the PEST control file.
PESTGEN's default value for RELPARMAX and FACPARMAX is 3.0; for
MODGEN this is increased to 5.0. If parameter convergence is too slow in the early
stages of the optimisation process because parameter values are prevented from being
adjusted as much as they should be, increase FACPARMAX and/or RELPARMAX.
However if the optimisation process is showing signs of instability due to parameter
over-adjustment, decrease the values of these variables.
Like PESTGEN, MODGEN assumes that only one model input file contains adjustable
parameters. If supplied with the name of only one bore data file it assumes that only
one model output file must be read for comparison with field data; if supplied with the
names of two bore data files it assumes that PEST must read two model output files. If
either of these assumptions is incorrect you must alter the number of files cited in the
"* model input/output" section of the PEST control file accordingly. Once again, this
can be achieved either through direct editing or through the use of PREPEST. In the
former case don't forget to adjust the values of the control variables NPARFILE and
NINSFILE in the "* control data" section of the PEST control file.
Building the PEST Control File
22
In most cases the default model input and output filenames, as well as the
corresponding template and instruction filenames used by MODGEN will differ from
the true names of these files. These are also easily altered, either directly on the PEST
control file or through the use of PREPEST.
After MODGEN has been used to generate a PEST control file, and after that file has
been altered to suite your particular case, PESTCHEK should be run to check all input
data for correctness and consistency. Then, if there are no errors, copy the files that
are required for the optimisation process up to your RAM disk (you may need to make
it large) and run PEST.
Running PEST
23
6. Running PEST
6.1 MODFLOW and MT3D Output Files
Both MODFLOW and MT3D generate a lot of data. As well as the unformatted head,
drawdown and concentration files (which are an essential part of the model-PEST
interface), each of these programs also writes a verbose text file. In the case of
MODFLOW, one or a number of unformatted files recording cell-by-cell flow term
information may also be produced.
When preparing for a MODFLOW or MT3D run you should, though your
preprocessor, assign values to model output control variables which reduce output
(especially text output) to a minimum. Doing this will have the dual effects of
decreasing model execution time, and of reducing the size requirements of the RAM
disk from which you may run PEST. If your preprocessor does not provide some of
the options necessary for you to reduce model output verbosity, you may need to edit
some MODFLOW or MT3D input files directly. For example, if your preprocessor
does not provide you with the ability to prevent MODFLOW or MT3D from echoing
input data arrays to its text output file, you should alter the value of the variable IPRN
to -1 for each array that the model reads. IPRN is the last variable written on the
control line informing MODFLOW or MT3D how to read each array; for the files
produced by many preprocessors, this control line is found immediately above the
array itself.
If you are using a version of MODFLOW with an MT3D interface and you are not
undertaking a simultaneous MT3D optimisation, you should prevent MODFLOW
from writing the large unformatted flow file required by MT3D every time it runs. This
can be accomplished by assigning the appropriate IUNIT element a value of zero on
the input file read by the MODFLOW "Basic" package.
6.2 Parameter Transformations and Bounds
PEST allows for the logarithmic transformation of adjustable parameters during the
parameter estimation process. For some parameters this can hasten the optimisation
process considerably; for others it can slow it down. When calibrating MODFLOW it
has been found that the log transformation of hydraulic conductivity, transmissivity,
inter-layer leakance and storage coefficient can have a positive effect on estimation
speed and stability. However recharge is better left untransformed. While the situation
is not as clear with MT3D, it appears that dispersivity estimates converge faster when
logarithmically transformed. No clear recommendation can be made for other
parameters; however trial and error with your particular problem will soon provide the
answer.
The selection of appropriate parameter upper and lower bounds is also important to
the success of the optimisation process. If a parameter is log-transformed its lower
bound must be greater than zero. (PESTCHEK will soon inform you if it is not.) Also,
realistic bounds should be placed on MODFLOW parameters such as storage
Running PEST
24
coefficient for which there are physical limits to the range of allowable values.
When undertaking parameter estimation using MT3D, the selection of parameter
bounds can be critical. As is explained in Section 7.3, MT3D parameter values can
influence the size of the time step used by MT3D for the solution of the solute
transport equations unless the user specifies that a suitably small transport step be used
regardless of any parameter value; this latter specification results in MT3D using the
same number of transport steps from model run to model run. For a given flow field
this, in turn, enforces accurate derivatives calculation, rapid estimation convergence
and optimisation stability. However if certain estimated parameters are allowed to take
on high enough values and others are allowed to take on low enough values in the
course of the optimisation process, MT3D will override the user-specified transport
step size, choosing an appropriately small step size of its own, thus breaking the step
size consistency between model runs. It is important to prevent this from happening by
restricting parameter variation to a realistic range through the designation of suitable
upper and lower parameter bounds.
6.3 Cells Going Dry
If a layer is unconfined and the water level within that layer falls beneath the layer
bottom elevation, MODFLOW declares that cell as dry. If the BCF1 package is used,
the cell stays dry forever. However the BCF2 package (and later BCF packages)
allows dry cells to be re-wet depending on water levels calculated for neighbouring and
underlying cells.
The occurrence of dry cells in a simulation can sometimes have undesirable
consequences, particularly if the BCF1 package is used. It often leads to a "cascading"
effect in which the drying of one particular cell prevents water inflow to a downstream
cell, which then becomes dry itself. This, in turn, causes the next downstream cell to
dry out and so on.
The drying (and possible re-wetting) of cells can have a disastrous effect on
MODFLOW parameter estimation because, no matter which BCF package is used,
model outcomes are no longer continuous with respect to adjustable parameters. This
is because a small parameter change may result in certain heads crossing a "threshold"
(eg. the aquifer base or re-wetting level) at which a significant and discontinuous
change in local aquifer flow conditions takes place. Furthermore, if an observation
points lies within a dry cell, MODBORE is unable to calculate a head for that
observation point, writing "dry_cell" to the heads column of its output file instead of
the head for that bore; when PEST reads the file, its inability to read a number where it
expects to find one precipitates a run-time error.
There are two ways to ensure that the drying out of cells does not preclude
MODFLOW parameter estimation. The first is the easiest, involving the setting of
parameter upper and lower bounds so tightly that no parameter is allowed to stray into
an area where it causes a model cell to go dry. The second method, suitable for many
models where each aquifer is represented by a single layer, is to make a small
adjustment to the MODFLOW source code and then to re-compile it. If you are using
the BCF2 package change the following lines of subroutine SBCF2H from:
Running PEST
25
C6------CHECK TO SEE IF SATURATED THICKNESS IS GREATER THAN ZERO.
IF(THCK.LE.0.) GO TO 100
to:
C6------CHECK TO SEE IF SATURATED THICKNESS IS GREATER THAN ZERO.
IF(THCK.LE.1.0) THCK=1.0
With the above alteration the calculated head within an unconfined layer is allowed to
drop continuously below the base of the aquifer (the fact that it is below the aquifer
base can be detected for display purposes in later postprocessing software); however
the thickness of water is not allowed to drop below a certain lower limit, in this case
one length unit (adjust this limit to suit yourself). Because the water thickness never
becomes negative, MODFLOW never declares the cell as dry.
For quasi three-dimensional models where a single model layer represents each aquifer,
MODFLOW can work well with the above alteration. It could be argued that this
alteration leads to an impossible situation whereby a cell's water level is below its base
yet the transmissivity of that cell is the same as if the cell contained one length unit's
depth of water. However in many cases this is not such a bad assumption. If model
cells are large it may be unlikely that the entire cell dries out; only those parts of the
cell with higher-than-average bottom elevation dry out, the cell still being able to
transmit water to neighbouring cells, albeit with a reduced capacity. Furthermore,
keeping cells wet in this manner may degrade model performance to a smaller extent
than the more unrealistic cascading of dry cells.
Note that if you recompile MODFLOW with a compiler other than a Lahey compiler,
you will need to recompile MODBORE with the same compiler so that it is able to
read the unformatted files produced by the former program; see Chapter 9.
6.4 If PEST Does Not Work
If PEST fails to work properly for your model, a careful reading of the PEST manual
may prove fruitful. The most common causes of optimisation failure are poor settings
for the PEST variables governing derivatives calculation and inappropriate settings for
the variables RELPARMAX and FACPARMAX. The former will be discussed in
detail in the next chapter; mention has already been made of the latter in Section 5.2 of
this manual.
If PEST terminates execution with a message that it was unable to find a model output
file (ie. a MODBORE or MT3BORE output file), or that it was not able to locate a
certain observation on one of these files, it is almost certain that MODFLOW or
MT3D terminated execution prematurely (unless you forgot to alter the MODGEN
default model output filename on the PEST control file to the name of the file actually
written by MODBORE or MT3BORE). An inspection of the text output file produced
by these models will nearly always reveal the reason for premature MODFLOW or
MT3D cessation. Once you have ascertained the cause you can make the appropriate
adjustment to the model's or PEST's input dataset to prevent it happening again. A
common cause of premature MODFLOW termination in a transient run is SOR, SIP or
PCG2 convergence failure at a certain time step. This problem can be overcome in the
manner described in Section 7.2.
Running PEST
26
Ill-determined parameters and high parameter correlation can lead to optimisation
instability. If you feel that the estimation process is going nowhere, terminate PEST
execution with a statistics printout (hit the <Esc> key and select the fourth menu item).
If an inspection of the run record file reveals that a certain parameter has a huge
uncertainty margin, then perhaps your measurement set cannot provide the basis to
resolve this parameter and it is better held fixed. If a number of parameters have high
uncertainty levels, it is possible that they are so highly correlated that PEST cannot
choose between the infinity of options by which these parameters can be optimised.
Check the parameter correlation coefficient and eigenvector matrices for further signs
of excessive correlation. If it exists, hold one of the offending parameters fixed and
recommence the optimisation process. Alternatively, add some prior information
involving one or more of the offending parameters.
If subsequent optimisation iterations yield no change in the objective function
whatsoever, and PEST finally ceases execution because "phi gradient zero" or
something similar, then it is possible that MODFLOW or MT3D did not actually run,
and that MODBORE or MT3BORE read an old unformatted head, drawdown or
concentration file each time it ran the composite MODFLOW/MODBORE or
MT3D/MT3BORE model. The failure of MODFLOW or MT3D to run may have been
due to an inappropriate PATH environment variable setting or because the memory
requirements of either of these programs were not met (see above).
If you suspect that MODFLOW or MT3D has not run, monitor the screen output
carefully during a PEST run for MODFLOW or MT3D output (if you have not
redirected it to a "nul" file). Alternatively, add a line to the batch file called by PEST as
the model, deleting the MODFLOW or MT3D unformatted output file prior to actually
running MODFLOW or MT3D. This will circumvent the problem by removing any
outdated files of this type. Then, if MODFLOW or MT3D does not run, MODBORE
or MT3BORE will fail in its execution, and the "model output file" expected by PEST
will not be found. PEST will then terminate execution after its first model run with an
appropriate error message.
It may be useful to test PEST settings for a particular model by calibrating it using
model-generated "measurements" prior to using actual field measurements. Under
these circumstances, provided your "measurements" are not insensitive to your
parameters, PEST should be able to optimise MODFLOW parameters to the extent
that the objective function is almost zero (it probably won't be exactly zero because of
round-off errors). The same should apply to MT3D, provided that the theoretical
measurements were generated using the same number of transport steps as MT3D uses
when under the control of PEST when carrying out the optimisation (see Section 7.3).
If the number of steps was different, PEST should still provide an optimal parameter
set. However this set may not be exactly the one that gave rise to the theoretical
dataset in the first place because of slight differences in MT3D-calculated
concentrations with differences in transport step size. PEST will, in fact, obtain a
parameter set for which the concentrations calculated on the basis of the transport step
size used for optimisation agree as closely as possible with those calculated on the
basis of the transport step size used to generate the theoretical data.
Calculating Derivatives
27
7. Calculating Derivatives
7.1 Model Output Precision
As explained in the PEST manual, successful performance of PEST in parameter
optimisation depends, more than just about anything else, on the accurate calculation
of derivatives of model outcomes with respect to adjustable parameters. PEST
calculates derivatives using finite differences, either two-point or three-point. If two
points are used, derivatives are calculated using forward differences. If three points are
used, the user is able to choose between three methods of derivatives calculations, viz.
parabolic interpolation, best-fit linear interpolation or the use of outside points only.
Fundamental to the success of any of these methods is that model outcomes are
calculated with as much precision as possible so that some significant figures remain
when two almost equal numbers are subtracted to form the finite difference.
Unfortunately there are factors in both the MODFLOW and MT3D numerical solution
schemes which can limit output precision. While these are of little consequence when
conducting individual simulation runs (where 3 or 4 significant figures are more than
enough), they can thwart successful PEST operation. However, if a few simple rules
are followed, both MODFLOW and MT3D can be made to calculate their outcomes
with sufficient numerical precision to be used successfully with PEST.
7.2 MODFLOW
A MODFLOW user is able to choose between a number of different solution schemes
to the matrix equations formed from a discretisation of the partial differential equations
describing groundwater movement. In most cases (eg. SOR, SIP and PCG2) the
matrix equations are solved iteratively using a process of successive approximation to
the "true" solution. The process is judged to be complete when the maximum head
change between successive solution attempts is less than a user-defined threshold,
HCLOSE. (The PCG2 method also requires the user to supply a convergence
threshold for its inner iterations, viz. RCLOSE; however it is HCLOSE, not RCLOSE,
that determines solution precision.)
The lower that HCLOSE is set, the higher will be the precision of heads calculated by
MODFLOW. Hence HCLOSE must be set low when using MODFLOW with PEST; a
-4
value of about 1.0 × 10 or less is normally warranted. However, because
MODFLOW then requires more iterations than usual to converge to this tighter
convergence threshold, the SOR, SIP or PCG2 iteration limit (viz. MXITER) must be
set higher than normal. (If the PCG2 package is used, MXITER refers to the maximum
number of outer iterations; inner iterations have no effect on precision.)
With HCLOSE set this low, solution convergence may not always be achieved within
MXITER iterations. In fact, for some parameter sets, solution convergence to within a
very tight HCLOSE may never be achieved (because of slight numerical oscillation)
even with MXITER set very high. Unfortunately, when MODFLOW is undertaking a
transient run and fails to achieve solution convergence within MXITER iterations at a
Calculating Derivatives
28
particular time step, it aborts execution immediately instead of moving on to the next
time step. This can have disastrous consequences when MODFLOW is being used with
PEST. If MODFLOW ceases execution prematurely, all the head or drawdown arrays
expected by MODBORE will not have been written to the unformatted MODFLOW
output file. Then when MODBORE is run immediately following MODFLOW, it will
not write its output file. When PEST then tries to read a MODBORE output file but
cannot find it, it aborts execution with an error message to the effect that it is unable to
find one of the model output files which it has been instructed to read through the
PEST control file.
There are two ways to overcome this problem. The easiest way is to make a slight
alteration to MODFLOW. In the MAIN program unit delete or comment out the line:
IF(ICNVG.EQ.0) STOP
under the comment labelled "C7C6". If you do this MODFLOW will continue onto the
next time step whether solution convergence was achieved or not. (If you recompile
MODFLOW with a compiler other than a Lahey compiler, you will then need to
recompile MODBORE as well; see Chapter 9.)
The second option is to insert a little intelligence into the batch file which MODFLOW
calls as the model. As explained in Appendix A3, MODBORE requires the user to
inform it how many arrays to expect in the unformatted MODFLOW output file which
it must read. If the number of arrays in this file differs from what it expects, it will not
produce an output file of its own, terminating execution instead with a DOS errorlevel
setting of 100. A statement in the batch file (run by PEST as the "model") immediately
following the command to execute MODBORE can detect this errorlevel setting and
take appropriate action. The most appropriate action is to substitute a new
MODFLOW solution package input file for the one which MODFLOW had just read,
and then re-run MODFLOW; in this substitute file, HCLOSE should be set higher. If
this fails another file can be substituted in which HCLOSE is set even higher.
Eventually MODFLOW solution convergence should be successful and MODBORE
will be able to complete its run. It is important to note, however, that this procedure
will not work if any adjustable parameters reside on the solution package input file, for
current parameter values will be lost in the substitution process.
By way of example, suppose that you have prepared for a MODFLOW run using your
usual MODFLOW preprocessor. Your version of MODFLOW is run using the
command:
modflw96 < modflw96.in
where MODFLW96.IN contains the name of the "name file" required by MODFLOW
96. Suppose further that you are using the MODFLOW PCG2 solution package and
that your preprocessor has written PCG2 input data to a file named PCG2.DAT. After
the preprocessor has prepared all its MODFLOW input files you should copy
PCG2.DAT to PCG2.H1, PCG2.H2, PCG2.H3, PCG2.H4 and PCG2.H5. If, while
-5
using the preprocessor, you had entered HCLOSE as 1.0 × 10 , this will be the
HCLOSE value written to PCG2.DAT. You should alter this value in PCG2.H2 to 2.0
-5
-5
-5
× 10 ; in PCG2.H3 it should be altered to 4.0 × 10 , in PCG2.H4 to 8.0 × 10 , and in
-4
PCG2.H5 to 2.0 × 10 . (Make sure that you adhere strictly to the correct input file
Calculating Derivatives
29
protocol so that MODFLOW can read these files without error.) If, prior to PEST
execution, all of these files are copied to the RAM disk from which you will run PEST,
the batch file illustrated in Example 7.1, run by PEST as the model, will ensure that if
ever MODFLOW fails to converge while being run by PEST, further attempts at
MODFLOW execution will be made using looser convergence criteria. Note, however,
that the initial attempt to run MODFLOW always uses the tightest solution
convergence criterion.
The batch program of Example 7.1 directs all MODFLOW and MODBORE screen
output away from the screen so that PEST's screen output is not scrolled away. This is
not essential and you may, in fact, prefer to see MODFLOW output so that you can be
assured that it is running correctly (especially if you are using WPEST or Parallel
PEST rather than SPEST). Remember that the status of the optimisation process can
be checked at any time by perusing the PEST run record file; hit the <Esc> key and
PEST will display a menu at the completion of the next model run.
@echo off
@copy pcg2.h1 pcg2.dat > nul
modflw96 < modflw96.in > nul
modbore < modbore.in > nul
if not errorlevel 100 goto end
@copy pcg2.h2 pcg2.dat > nul
modflw96 < modflw96.in > nul
modbore < modbore.in > nul
if not errorlevel 100 goto end
@copy pcg2.h3 pcg2.dat > nul
modflw96 < modflw96.in > nul
modbore < modbore.in > nul
if not errorlevel 100 goto end
@copy pcg2.h4 pcg2.dat > nul
modflw96 < modflw96.in > nul
modbore < modbore.in > nul
if not errorlevel 100 goto end
@copy pcg2.h5 pcg2.dat > nul
modflw96 < modflw96.in > nul
modbore < modbore.in > nul
if not errorlevel 100 goto end
:end
Example 7.1 A batch file run by PEST which circumvents problems caused by
premature MODFLOW termination.
7.3 MT3D
MT3D may or may not use an iterative matrix equation solver to generate solute
concentrations at its grid cells, depending on whether or not the user requests implicit
(rather than explicit) solution of the solute transport equations. If the MOD, MMOC
or HMOC schemes are employed, MT3D moves particles through the model domain in
order to solve the advection component of the solute transport problem, while it solves
the dispersion, source-sink mixing and chemical reaction components using either an
Calculating Derivatives
30
explicit or implicit finite difference technique. Whereas the explicit solution scheme
presents no problems for solution precision, the movement of particles between cells
can seriously degrade precision, and with it the accuracy of derivatives calculation with
respect to adjustable parameters. While solute concentrations calculated by MT3D will
be more than precise enough for ordinary usage in a forward modelling capacity, a
significant loss of precision will occur when the outcomes of subsequent runs,
calculated on the basis of slightly altered parameter values, are subtracted from each
other in order to calculate derivatives.
The problem with the use of moving particles to calculate the advection term is that
the particles are only finite in number. This introduces "thresholds" throughout the
model domain. For example the number of particles within a certain cell at the end of a
particular time step will depend on the flow regime as supplied by MODFLOW. Thus a
slight change in, for example, the transmissivity of a certain cell, can alter the number
of particles in that cell from, say, 9 to 10. This, in turn, will result in a discontinuous
change in the solute concentration calculated for that cell as its transmissivity is slightly
varied. Hence it will not be possible to accurately calculate the derivative of the
concentration in that cell with respect to its transmissivity if the latter is an adjustable
parameter.
The obvious repercussion of the above discussion is that MODFLOW and MT3D
should not be calibrated together if a MOC scheme is used to simulate the advective
component of solute transport. If MODFLOW is first calibrated using borehole head
or drawdown information, and then MT3D is calibrated separately using measured
borehole concentrations, the flow regime presented to MT3D by MODFLOW will not
vary from run to run during the calibration process. Unfortunately, however, while
adherence to this principal is a step in the right direction, it is still not sufficient to
circumvent the problem of MT3D output "granularity" when using particles to track
solutes.
MT3D updates solute concentrations over time intervals known as "transport steps".
When using the explicit finite difference or TVD schemes, each transport step must be
small enough such that none of the stability criteria pertaining to the different
components of the overall transport equation are violated. There is a stability criterion
associated with the advection term, the dispersion term, the source-sink mixing term,
and the chemical reaction term. All these criteria depend on system properties. Hence
if one or more of these properties is being estimated by PEST, and thus changes from
run to run, so too will one or more of the stability criteria. If MT3D is allowed to
select the transport step size itself based on the tightest of the various stability criteria
which it must meet (as it does when the input variable DT0 is set to zero or negative),
then the transport step size may vary from run to run as adjustable parameters are
varied. This, in turn, will introduce model output "granularity" as it again becomes
possible for the number of particles within a certain cell to vary slightly at a certain
simulation time from one model run to the next.
Fortunately this problem is easily overcome. MT3D allows the user to select the
transport step size him/herself through the input variable DT0 (if it is set positive).
However MT3D overrides this choice if it fails to fulfil all of the model stability
criteria. Hence, for consistency between model runs, DT0 must be chosen low enough
Calculating Derivatives
31
that it will not be "undercut" at any stage of the optimisation process as PEST varies
MT3D parameter values from run to run as it attempts to optimise them. While setting
DT0 low in this manner results in an increased MT3D execution time, it does
guarantee good PEST performance.
As a complementary measure, it is important to place suitable bounds on adjustable
MT3D parameters. For example, if you are estimating dispersivity and, in the course of
the parameter estimation process, a dispersivity value becomes too high, the stability
criterion associated with the dispersion term could necessitate a transport step size
lower than your chosen DT0 value. In such a case MT3D will undercut DT0 in
assigning the transport step size, with the result that the number of transport steps will
vary between subsequent MT3D runs.
A further important rule to follow in order to maintain consistency in the movement of
particles between cells from model run to model run, is that particles must be placed in
a fixed pattern within a model cell rather than in a random pattern. Hence NPLANE
and NLSINK must be greater than zero. (You may then need to employ more particles
than normal to reduce mass balance discrepancies in diverging/converging flow fields.)
Similarly, if solute source concentration is being estimated, care must be taken in
assigning values to the variables NPL and NPH. In some cases it may be advisable to
set NPL equal to NPH.
Another "threshold" involved in the operation of MT3D that has the potential to
introduce inconsistency between model runs involves the use of the MT3D input
variable DHMOC to switch between usage of the MOC and MMOC schemes in the
solution of the advection term of the transport equation. Experience has shown,
however, that this does not cause too many problems, as borehole measurements used
for model calibration tend to be in areas where solute concentrations are high and
where the MOC, rather than the MMOC, scheme is operating. Conversely, in areas
where the MMOC scheme is in operation, the solute concentration is generally low;
thus the contribution of a measurement residual from a bore sited within this area to
the overall objective function is low (as long as the observation weight is not high)
further diminishing the potential for instability. Nevertheless, if PEST is having
difficulty in optimising MT3D parameters, it may be worth attempting a calibration
using the MOC scheme only, dispensing with the MMOC scheme altogether. To
achieve this, set MIXELM to 1.
Alternatively, dispense with particle-based schemes altogether, using the TVD or
finite-difference methods to solve the advective component of the solute transport
equation.
7.4 Derivative Increments
There is much discussion in the PEST manual on how to select a suitable increment
(ie. DERINC) for derivatives calculation. Indeed the value for DERINC can have a
pronounced effect on both MODFLOW and MT3D optimisation performance. Recall
that if DERINC is too large derivatives will be inaccurate, as finite differences fail to
approximate infinitesimal increments; however if DERINC is too small numerical
errors incurred through subtracting numbers of similar size result in poor derivatives
Calculating Derivatives
32
calculation.
Experience in calibrating MODFLOW has shown that it is best to calculate derivatives
using relative rather than absolute increments (ie. the PEST derivative control variable
INCTYP is set to "relative"), and that a value of between 0.01 and 0.05 is suitable for
DERINC. However, for safety's sake, it is wise to back this up with an appropriate
value for DERINCLB, ie. the absolute increment lower bound. For MT3D calibration
DERINC is best set to 0.05 or higher if using a MOC scheme. For both MODFLOW
and MT3D, FORCEN should be set to "switch" while values of 2.0 and "parabolic" are
suitable for DERINCMUL and DERMTHD in most cases. If you undertake a dummy
run using model-generated "field data", the best values for these variables for your
particular case will soon become apparent.
The estimation of recharge is a special case. Recharge can vary greatly over a model
domain; also, for some models, it may take on negative values. It has been found that
an INCTYP setting of "rel_to_max" is often suitable for recharge parameters, and that
a suitable value for DERINC is, again, 0.01 to 0.05. As was mentioned in Section 6.2,
recharge parameters should not be log-transformed.
For further information on the function of PEST derivative control variables see the
PEST manual.
Joint MODFLOW/MT3D Optimisation
33
8. Joint MODFLOW/MT3D Optimisation
8.1 Optimising Parameters for MODFLOW and MT3D Together
The pitfalls of simultaneous MODFLOW/MT3D optimisation have been explained in
Section 7.3. Nevertheless, if you think that this would assist the calibration of your
particular model, a PEST run can easily be set up to do it. Using MODINS, instruction
files can be individually built for reading MODBORE and MT3BORE output files,
while two bore data files (one listing water level measurements, the other listing
concentration measurements) can be read by MODGEN to produce a single PEST
control file which includes all borehole measurements. The assignment of a suitable
weighting between water level and concentration measurements has already been
discussed in Section 4.2 of this manual.
The "model" called by PEST should run MODFLOW and MODBORE followed by
MT3D and MT3BORE. However the use of this simple model can lead to unnecessary
MODFLOW runs in the derivatives calculation phase of each optimisation iteration,
for while an increment to a MODFLOW parameter value will have an effect on
concentrations calculated by MT3D, the inverse is not true; an alteration to a MT3D
parameter will have no effect on MODFLOW-calculated heads or drawdowns. Hence
when an MT3D parameter is incrementally varied there is no need to run MODFLOW
prior to running MT3D.
Included in the PEST MODFLOW/MT3D utilities suite is a program called
COMPFILE. This program reads two text files (nominated on the COMPFILE
command line), terminating execution with an errorlevel setting of 100 as soon as it
encounters a difference between them. However if the files are identical it terminates
execution with an errorlevel of zero. Using COMPFILE, the batch file shown in
Example 8.1 could be run by PEST as the joint MODFLOW/MT3D model.
Let us assume that in Example 8.1 PEST is optimising transmissivity for MODFLOW
simultaneously with dispersivity for MT3D. The transmissivity array is located in the
MODFLOW input file BCF.DAT. Accordingly a template named BCF.TPL is
constructed for that file. However PEST is informed that the model input file
corresponding to BCF.TPL is, in fact, a file named BCF.HLD, a temporary "holding"
file. Prior to running the model, PEST writes the model input files BCF.HLD and
DSP.DAT, the latter holding the MT3D dispersivity array. If BCF.HLD differs from
the previous MODFLOW input file BCF.DAT, then BCF.HLD is copied to BCF.DAT
and MODFLOW is run (with appropriate safeguards against MODFLOW convergence
problems). However if BCF.DAT and BCF.HLD are identical, there is no use in
running MODFLOW. In this case execution of the batch process is taken to label1
where MODBORE is run. (The running of MODBORE is necessary because, prior to
actually running the model, PEST deletes any model output files that it must later read.
In this way PEST will know if, for any reason, the model failed to run; it also obviates
the possibility of inadvertently reading a model output file produced on a previous
model run.) MT3D, followed by MT3BORE, is then run irrespective of whether
MODFLOW has been run or not.
Joint MODFLOW/MT3D Optimisation
rem Test whether the input to the BCF package has changed.
compfile bcf.hld bcf.dat
rem If it has not changed skip MODFLOW execution.
if not errorlevel 100 goto label1
rem Run MODFLOW protecting
copy bcf.hld bcf.dat
copy pcg2.h1 pcg2.dat
modf < modffile
modbore < modbore.in
if not errorlevel 100 goto
copy pcg2.h2 pcg2.dat
modf < modffile
modbore < modbore.in
if not errorlevel 100 goto
copy pcg2.h3 pcg2.dat
modf < modffile
modbore < modbore.in
if not errorlevel 100 goto
copy pcg2.h4 pcg2.dat
modf < modffile
modbore < modbore.in
if not errorlevel 100 goto
copy pcg2.h5 pcg2.dat
modf < modffile
modbore < modbore.in
if not errorlevel 100 goto
against premature termination.
label2
label2
label2
label2
label2
:label1
modbore < modbore.in
rem Run MT3D.
:label2
mt3d < mt3dfile
mt3bore < mt3bore.in
Example 8.1 A batch file for joint MODFLOW/MT3D parameter estimation.
34
Compiling MODFLOW and MT3D Yourself
35
9. Compiling MODFLOW and MT3D Yourself
As has been mentioned a number of times in this manual, it may be advantageous to
make a slight alteration to the MODFLOW or MT3D source code and recompile it
prior to using it with PEST for calibration purposes. However if you recompile
MODFLOW with a compiler other than a Lahey compiler, MODBORE will not work
properly. Similarly, if you recompile MT3D with a compiler other than a Lahey
compiler, MT3BORE will not work. The reason for this is that the protocol for storing
unformatted files differs from compiler to compiler. As was explained in Chapter 3 of
this manual, MODBORE and MT3BORE read unformatted files written by
MODFLOW and MT3D respectively.
The solution to this problem is simply to recompile MODBORE and MT3BORE with
the same compiler that you use to recompile MODFLOW and MT3D. The source
code for each of these programs can be found on the distribution disk.
As an alternative, a MODBORE executable named MODBORE1.EXE, compiled with
the WATCOM compiler, is provided with the PEST MODFLOW/MT3D Utility suite.
This is can be used with the Visual MODFLOW version of MODFLOW.
References
36
10. References
Doherty, 1996. Groundwater Data Utilities. Queensland Department of Natural
Resources (available from the author of this report).
McDonald, M. G. and Harbaugh A. W., 1988. MODFLOW, A Modular Three
Dimensional Finite Difference Ground Water Flow Model. US Geological Survey,
Tech. Water-Resources Inv. Bk 6, Washington D. C.
Zheng, C. and Wang, P. 1998. MT3DMS Documentation and User’s Guide.
University of Alabama Technical Report.
ARRAYREP
37
Appendix A: Program Descriptions
A1. ARRAYREP
A1.1 Function of ARRAYREP
Program ARRAYREP was written to overcome difficulties that may arise in constructing
PEST template files when using certain popular MODFLOW and MT3D graphical
preprocessors.
Under some circumstances it is not possible when using these preprocessors to construct
MODFLOW input files that reflect user-intended parameter zonation. This is because they
multiply user-supplied intrinsic aquifer properties by layer thickness to obtain thicknessintegrated properties to record on MODFLOW input files. Thus, for example, specific
storage may be multiplied by layer thickness to obtain layer storage capacity. Also,
depending on a layer's LAYCON setting, hydraulic conductivity may be multiplied by layer
thickness to obtain transmissivity. If layer top and bottom elevations are irregular (having
been obtained, perhaps, by interpolation from borehole measurements), any zonation of the
intrinsic properties supplied to the preprocessor by the user is lost on the MODFLOW
input files which it generates. As a result, program TEXTREP cannot be used to generate
zoned template files as a prerequisite to estimating vertically-integrated properties for these
layers.
To assist in overcoming this difficulty, program ARRAYREP allows a user to replace an
array found in a MODFLOW (or MT3D) input file by another, model-compatible, array
stored in a separate file. If the latter array is zoned according to a user's specifications,
TEXTREP can then be used to produce an appropriately zoned PEST template file.
A1.2 Command Line
ARRAYREP is run using the command:
ARRAYREP modfile1 arrayfile modfile2
where:
modfile1
arrayfile
modfile2
is a MODFLOW or MT3D input file,
is a file containing a MODFLOW-compatible data array, and
is a MODFLOW or MT3D input file generated by replacing a userspecified array within modfile1 by the array found in file arrayfile.
A1.3 The Array File
Example A1.1 shows the contents a small array file.
ARRAYREP
38
14
10
0.010 0.010 0.010 0.010 0.013 0.013 0.013 0.013 0.013 0.006 0.006 0.006 0.006 0.006
0.010 0.010 0.010 0.010 0.013 0.013 0.013 0.013 0.013 0.013 0.006 0.006 0.006 0.006
0.010 0.010 0.010 0.010 0.013 0.013 0.013 0.013 0.013 0.006 0.006 0.006 0.006 0.006
0.010 0.010 0.010 0.010 0.010 0.013 0.013 0.013 0.006 0.006 0.006 0.006 0.006 0.006
0.010 0.010 0.010 0.010 0.010 0.010 0.013 0.006 0.006 0.006 0.006 0.006 0.006 0.006
0.010 0.010 0.010 0.010 0.010 0.010 0.010 0.006 0.006 0.006 0.006 0.006 0.006 0.006
0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.006 0.006 0.006 0.006 0.006 0.006 0.006
0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.006 0.006 0.006 0.006 0.006 0.006
0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.004 0.006 0.006 0.006 0.006 0.006 0.006
0.004 0.004 0.004 0.004 0.004 0.006 0.006 0.006 0.006 0.006 0.006 0.006 0.006 0.006
Example A1.1 An array file.
The first line of an array file must record the number of columns and rows, respectively, in
the model grid. Subsequent lines pertain to each row of the grid. Note that if the grid is
large, data can be wrapped so that not all of the elements pertaining to any one row need to
appear on only one line. However the data pertaining to each new row must begin on a
new line.
The easiest way to produce a file like that shown in Example A1.1 may be to generate
an appropriately zoned array within the graphical MODFLOW preprocessor (under the
guise, perhaps, of another aquifer property) and then write it to a file using the
preprocessor’s export facility; for some preprocessors the “number of columns,
number of rows” array header may need to be added manually using a text editor. Thus
an array can be built within the chosen MODFLOW interface package to a user's
specifications and stored in a separate file for later use. After pre-processing, zonation
can be restored to a MODFLOW input file generated by the preprocessor by replacing
arrays located in that file by previously-exported arrays with the zonation intact.
A1.4 Locating an Array on a MODFLOW or MT3D Input File
On a MODFLOW or MT3D input file each data array is preceded by a header line
informing MODFLOW or MT3D how to read the array. Four items comprise this header.
The first, an integer, informs MODFLOW or MT3D whether the array is constant-valued
and/or from which file (and, in the case of MT3D, according to which protocol) the array
is to be read. If this variable is zero no array follows and, on reading the file, MODFLOW
or MT3D sets the entire array to the value of the second variable on the header line. On the
other hand, if the first variable is non-zero, MODFLOW and MT3D multiply the entire
array by the value of the second variable once the array has been read. The third item is a
format string informing MODFLOW or MT3D how to read the array. The fourth item is
used to indicate whether the array should be echoed on the MODFLOW or MT3D output
file and, if so, according to what format. When writing MODFLOW or MT3D input files,
some preprocessors then add a text string describing the function of the array. This is
illustrated in Example A1.2.
11
1(86G12.0)
1
transmissivity of layer 1
Example A1.2 Header line to an array on a MODFLOW input file; the array
descriptor is optional.
ARRAYREP
39
With three exceptions, unless its first variable is zero-valued, a header line on a
MODFLOW input file such as that illustrated in Example A1.2 will be followed by a twodimensional array of numbers. The three exceptions are the row and column cell widths and
layer anisotropies. In these cases a one-dimensional array, rather than a two-dimensional
array, follows the header.
A1.5 Running ARRAYREP
Upon commencement of execution, ARRAYREP prompts:
Locate array using text or line number [t/l]:
to which the user should respond with “t” or “l” as appropriate. In the former case
ARRAYREP then prompts:
Enter text:
Here supply up to 100 characters of text. ARRAYREP then searches the MODFLOW or
MT3D input file whose name was provided on the ARRAYREP command line for the
supplied text; note that the search is case-insensitive. If it finds the text it assumes that it has
found an array header. It then reads both this header and the ensuing array, replacing the
latter with an array read from the command-line-nominated array file.
Care must be exercised in your choice of search text, for it must be comprised of sufficient
characters to ensure that the appropriate array header is uniquely identified. Thus for a
single layer model the string “trans” would be sufficient to uniquely locate the header
shown in Example A1.2. However for a multilayer model the user should supply the string
“transmissivity of layer 1” in response to the above prompt unless he/she wishes to replace
the transmissivity array for the second layer as well as that for the first.
If array descriptors are not recorded on a MODFLOW input file, they must be located by
line number. Thus if a user responds with “1” to the first prompt above, ARRAYREP
prompts:
Enter line number:
Here the user should enter the file line number on which an array header is located.
ARRAYREP then attempts to read a header from this line. If successful, it then reads the
ensuing array, replacing it with the array contained in the command-line-nominated array
file.
An important difference should be noted between the two alternative means of searching
for an array header. If the user chooses to supply text as a basis for locating an array header
on a MODFLOW or MT3D input file, ARRAYREP will replace all arrays whose header
line contains the supplied text. However if a line number is used to locate an array header,
then only one array will be replaced. In either case ARRAYREP will inform the user if the
array header was located, if subsequent array replacement was successful, and how many
arrays were thus replaced.
A1.6 The Replaced Array
Once ARRAYREP has carried out array replacement, the original MODFLOW/MT3D
ARRAYREP
40
input file should be replaced by the newly-created one (make a copy of the original first).
Then MODFLOW or MT3D should be run to make sure that the new input file is correct.
Do not be disturbed if the appearance of the replaced array on the ARRAYREP-created
MODFLOW/MT3D input file is different from the appearance of the array on the original
MODFLOW/MT3D input file. ARRAYREP writes seven array values to a line, using 14
characters for each element. While this differs from the conventions used by some
commercial preprocessors, MODFLOW or MT3D is, nevertheless, able to read the new
array without any trouble as ARRAYREP also rewrites the array header line, including an
appropriate format specifier as the third item in this header.
It should also be noted that ARRAYREP ignores the multiplier supplied as the second
element of the array header in the existing MODFLOW/MT3D input file. It supplies a
multiplier value of unity for the replacement array. However the first element of the array
header of the existing MODFLOW/MT3D input file is not altered by ARRAYREP.
It is also important to note that the column and row numbers constituting the first line of
the replacement array file must accurately reflect the dimensions of the finite-difference
grid. ARRAYREP relies on these values to read and rewrite the array correctly.
TEXTREP
41
A2. TEXTREP
A2.1 Function of TEXTREP
TEXTREP builds a PEST template file by replacing user-nominated strings on a model
input file by other user-nominated strings of identical length. The replaced strings are
usually numbers (including surrounding blank characters if necessary); the replacement
strings are usually parameter space identifiers, including parameter names and
delimiters.
A2.2 Command Line
TEXTREP is run using the command:
TEXTREP infile repfile tempfile [/char]
where:
infile
is a model input file,
repfile
contains a list of replacement text strings,
tempfile
is a template file to be built from the model input file, and
char
is the parameter delimiter (optional).
A2.3 Discussion
TEXTREP was designed to assist in the preparation of template files from model input
files. It facilitates the replacement of numeric fields within an input file by parameter
spaces. TEXTREP is particularly useful when constructing a template file from a
model input file which includes one or a number of arrays or tables of numbers which
need to be replaced by arrays or tables of parameter spaces.
A text replacement file is shown in Example A2.1. Each line consists of four entries.
The first entry is the text to be replaced, the second entry is the replacement text, while
the third and fourth entries list the line numbers between which each replacement is to
be active. These line numbers can be obtained from a text editor or viewer. If a
particular replacement is to be active throughout the entire model input file, the first
line number should be set to 1 while the second line number should be set very high (it
does not matter if it is set to a number greater than the number of lines in the input
file). Alternatively, the two line numbers can be omitted altogether.
TEXTREP
"
1.200"
"
4.345"
" 4.54E+04"
" 5.00E+04"
"
7.600"
"
1.200"
42
"#
"#
"#
"#
"#
"#
p1
p2
p3
p4
p5
p6
#"
#"
#"
#"
#"
#"
29
29
57
57
78
78
56
56
92
92
102
102
Example A2.1 A text replacement file.
The strings defining the first two entries on each line of a text replacement file must be
quote-delimited and of the same length. Any number of spaces (or a tab) may separate
each item on a line.
Care must be taken in identifying strings to be replaced by parameter spaces on a
model input file; remember that the parameter space with which TEXTREP replaces
the string will itself be replaced by a number when PEST is run. The parameter space
should be large enough for all numbers within the allowed parameter range to be
represented with as many significant digits as possible; hence if the parameter values in
the model input file upon which the template file is based do not occupy their full input
fieldwidth, the first entry in each line of the text replacement file will include a number
plus some spaces. Remember also that the definition of the parameter space must take
strict account of the format with which the model reads its input file; in particular, the
parameter space must not be larger than the model's input fieldwidth for that
parameter.
Example A2.2 shows part of a model input file, while Example A2.3 shows the
corresponding fragment of a template file built from this model input file using the text
replacement file of Example A2.1. In this example the model (MODFLOW or MT3D)
reads each number within each array using the format specifier '(F10.0)'; hence the
parameter space can occupy up to the full ten spaces (but no more) allowed for each
number within the input array. Refer to the PEST manual for a full discussion of the
design of parameter spaces. Note that parameter estimates are not being sought for all
zones within the array represented in Example A2.2.
1.200
1.200
1.200
1.200
1.200
1.200
1.200
1.200
1.200
1.200
1.200
1.200
1.200
1.200
1.200
4.345
1.200
1.200
1.200
1.200
4.345
4.345
4.345
4.345
6.593
6.593
6.593
4.345
4.345
4.345
4.345
4.345
6.593
6.593
6.593
4.345
4.345
4.345
4.345
4.345
Example A2.2 Lines 29 to 36 of a model input file.
6.593
6.593
6.593
4.345
4.345
4.345
4.345
4.345
6.593
6.593
6.593
4.345
4.345
4.345
4.345
4.345
TEXTREP
#
#
#
#
#
#
#
#
p1
p1
p1
p1
p1
p1
p1
p1
43
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
p1
p1
p1
p1
p1
p1
p1
p2
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
p1
p1
p1
p1
p2
p2
p2
p2
#
#
#
#
#
#
#
#
#
#
#
#
#
6.593
6.593
6.593
p2
#
p2
#
p2
#
p2
#
p2
#
#
#
#
#
#
6.593
6.593
6.593
p2
#
p2
#
p2
#
p2
#
p2
#
#
#
#
#
#
6.593
6.593
6.593
p2
#
p2
#
p2
#
p2
#
p2
#
#
#
#
#
#
6.593
6.593
6.593
p2
#
p2
#
p2
#
p2
#
p2
#
Example A2.3 Part of the template file constructed from the model input file of
Example A2.2
If the TEXTREP command line includes the optional parameter delimiter, TEXTREP
adds the template file header to the top of the template file which it creates. Thus if the
parameter delimiter is supplied as "#", the template file will begin with the line:
ptf #
TEXTREP will then also check that each text replacement string begins and ends with
this same parameter delimiter.
TEXTREP can read model input files of any length. However there is a limit to the
width of any line within the model input file; at present that width is set at 2000
characters. If that is not sufficient for your application, contact Watermark Computing
and we will send you a copy of TEXTREP with this limit increased.
MODBORE
44
A3. MODBORE
A3.1 Function of MODBORE
MODBORE reads an unformatted MODFLOW head or drawdown output file,
interpolating the arrays contained therein to a set of points (normally borehole
locations) whose coordinates are supplied by the user.
A3.2 Command Line
MODBORE is run using the command:
modbore
The names of its input files are supplied to it either through direct terminal input or
through file redirection.
A3.3 The Grid Specification File
MODBORE begins execution by requesting the names of its input files.
Enter the names of the following MODBORE input files:grid specification file:
bore listing file:
bore coordinates file:
unformatted MODFLOW output file:
The grid specification file provides MODBORE with grid geometry and location
details. An example is provided in Example A3.1. The corresponding grid is pictured in
Fig. A3.1.
8 10
300000.00
7800000.00
30.0
2*100, 6*50, 2*100
50.0 50.0 50.0 50.0 50.0 50.0 50.0 50.0
Example A3.1 A grid specification file.
MODBORE
45
(300000E, 7800000N)
30 degrees
Figure A3.1 The finite-difference grid whose grid specification file is shown in
Example A3.1
The first line of a grid specification file must contain the number of rows and columns,
respectively in the finite-difference grid. The second line contains three numbers. The
first two are the easting and northing of the top left corner of the grid; the cell whose
row and column numbers are each 1 occupies this top left corner. The third number on
the second line is the rotation angle (in degrees) of the grid row direction (ie. the
direction of increasing column number) with respect to east. This number is positive if
the row direction is north of east, and negative if the row direction is south of east (ie.
anticlockwise rotation is positive and clockwise rotation is negative). Note that the
angle provided here must never be greater than 90 degrees or less than -90 degrees.
The third line of the grid specification file lists the width of cells in the grid row
direction (this is the MODFLOW DELR vector). These widths can be listed either
individually or in the manner shown in Example A3.1 suitable for FORTRAN listdirected input. If you choose the former alternative it is not necessary for all of its
elements to be confined to a single line. If MODBORE does not find all elements of
the DELR vector on the third line of the grid specification file (the number of elements
is equal to the number of columns of the finite difference grid) it will start reading
numbers on the next line. Note, however, that the listing of cell column widths (ie. the
DELC vector), which must follow the listing of the DELR vector in the grid
specification file, must begin on a new line. There are as many elements in the DELC
vector as there are rows in the finite difference grid.
An easy way to write the DELR and DELC vectors to the grid specification file is to
copy them (using, for example, the Microsoft WINDOWS clipboard) from the
MODFLOW BCF package input file prepared by your preprocessor. Alternatively,
they can be copied from the MODFLOW text output file. The latter alternative may
MODBORE
46
sometimes prove more convenient as MODFLOW's text output file is never more than
132 characters in width; hence if the DELR and DELC vectors are long they are
continued to the next line, and the next, and so on until all elements are listed. As was
mentioned in the above paragraph, such a vector can be read without any trouble by
MODBORE.
A3.4 The Bore Listing File
The bore listing file contains a list of all bores to be represented in the MODBORE
output file (and hence to which head or drawdown interpolation must take place).
These bores must be listed one to a line as is demonstrated in Example A3.2.
RN134532
RN3492
RN5590
RN75832A
RN75832B
Example A3.2 A bore listing file.
Bore identifiers can consist of any ASCII characters; their length is limited to 10 such
characters. Their identification is case-insensitive (they are converted to upper case
internally by MODBORE and other programs documented in this manual). Any bore
listed in a bore listing file must also appear in a bore coordinates file; see below.
A3.5 The Bore Coordinates File
The bore coordinates file provides bore eastings, northings and layer numbers. While
every bore listed in the bore listing file must also be listed in the bore coordinates file,
the reverse is not true. This allows you to vary the bores to which you would like
MODFLOW head or drawdown interpolation carried out simply by varying the entries
in the bore listing file; the more complex bore coordinates file may remain unaltered.
As shown in Example A3.3, each line of a bore coordinates file consists of 4 entries;
these are the bore identifier, the bore east and north coordinates, and the MODFLOW
layer number tapped by that bore.
RN134532
RN3492
RN5590
RN75832A
RN75832B
RN4334
332456.456
335487.481
331849.493
332901.301
332901.301
331904.398
7854234.938
7855028.891
7803290.492
7849015.091
7849015.091
7830455.392
1
2
1
1
2
1
Example A3.3 A bore coordinates file.
A3.6 The Unformatted MODFLOW Output File
After you provide MODBORE with the name of a MODFLOW unformatted head or
drawdown output file, MODBORE prompts:
MODBORE
47
how many arrays are expected in this file?
enter the value designating an inactive cell:
enter the value designating a dry cell:
MODBORE needs to know how many arrays are in this file so that it can take
appropriate action if all arrays are not present. This will occur if MODFLOW
terminated execution prematurely due to an error condition or because it failed to
achieve heads solution convergence at a particular time step of a transient run. In such
circumstances MODBORE will not write an output file, terminating execution instead
with an errorlevel setting of 100. This allows intelligence to be built into the batch file
which PEST runs as the model; see Section 7.2 of this manual.
You must take account of the number of layers in your model when informing
MODBORE how many arrays to expect in the unformatted MODFLOW output file.
For example, if you have requested MODFLOW unformatted output at 4 different
time steps, your model has 3 layers and a heads array is to be written for each such
layer, the number of expected arrays is 12.
As explained in Section 3.3 of this manual, MODBORE interpolates MODFLOW twodimensional arrays using a bilinear interpolation scheme which takes account of the
location of grid boundaries as well as of inactive and dry cells. If a measurement point
falls outside the grid, or within an inactive or dry cell, this is recorded on the
MODBORE output file; see below. However, if a measurement point lies in a cell to
which the grid boundary or an inactive or dry cell is a neighbour, the interpolation
scheme is adjusted accordingly. MODBORE recognises such inactive or dry cells
through the value that MODFLOW assigns to them (viz. HNOFLO for inactive cells
and HDRY for dry cells); hence values for these MODFLOW variables must be
provided as part of the MODBORE input dataset.
Note that MODBORE looks for inactive cells before it looks for dry cells. Thus if
HNOFLO and HDRY have the same value, MODFLOW will declare bores falling in
dry cells as inactive. Note also that MODBORE only interpolates an array to a given
borehole if that borehole taps the array (bore layer numbers are listed in the bore
coordinates file). If, at a certain time step for which there is at least some MODFLOW
unformatted head or drawdown output, MODFLOW writes no array for the layer
tapped by a certain bore, this fact will be recorded on the MODBORE output file; see
below.
A3.7 The MODBORE Output File
MODBORE's final screen prompt is:
Provide a name for the MODBORE output file:
Example A3.4 shows a MODBORE output file. The information contained in the
header lines to each section of the MODBORE output file is taken from array header
lines in the MODFLOW unformatted head or drawdown file. As was explained in
Section 3.4, the coordinates of each bore are written to the MODBORE output file so
that the head or drawdown data for any time step can serve as input to a contouring
package.
MODBORE
48
INTERPOLATED HEAD ARRAY FOR TIME STEP 2 OF STRESS PERIOD 1 ----->
ELAPSED TIME SINCE START OF STRESS PERIOD = 200.000
ELAPSED TIME SINCE START OF SIMULATION
= 200.000
RN134532
332456.456
7854234.938
39.58739
RN3492
335487.481
7855028.891
45.96882
RN5590
331849.493
7803290.492
34.59821
RN75832A
332901.301
7849015.091
56.39821
RN75832B
332901.301
7849015.091
37.59832
INTERPOLATED HEAD ARRAY FOR TIME STEP 2 OF STRESS PERIOD 2 ----->
ELAPSED TIME SINCE START OF STRESS PERIOD = 200.000
ELAPSED TIME SINCE START OF SIMULATION
= 400.000
RN134532
332456.456
7854234.938
36.48934
RN3492
335487.481
7855028.891
45.93847
RN5590
331849.493
7803290.492
37.83109
RN75832A
332901.301
7849015.091
59.48489
RN75832B
332901.301
7849015.091
33.49302
INTERPOLATED HEAD ARRAY FOR TIME STEP 2 OF STRESS PERIOD 3 ----->
ELAPSED TIME SINCE START OF STRESS PERIOD = 200.000
ELAPSED TIME SINCE START OF SIMULATION
= 600.000
RN134532
332456.456
7854234.938
42.94821
RN3492
335487.481
7855028.891
48.18942
RN5590
331849.493
7803290.492
37.93281
RN75832A
332901.301
7849015.091
58.94420
RN75832B
332901.301
7849015.091
38.94821
Example A3.4 A MODBORE output file.
In certain cases the numbers in the final column of a MODBORE output file are
replaced by alphanumeric strings denoting an error condition. Thus if a bore falls
outside the grid, its head is written as "outside_grid", if it falls within an inactive cell its
head is denoted as "inactive_cell", if it falls within a dry cell, the head is provided as
"dry_cell", and if no array pertaining to the bore's layer number was found in the
MODFLOW output file for a given output time, the bore's head is written as
"no_layer_data".
A3.8 Compiling Your Own MODBORE
As was discussed in Chapter 9 of this manual, the compiler used to generate
MODBORE and MT3BORE executables must match that used to generate your
MODFLOW and MT3D executables so that the unformatted files written by the latter
programs can be read by the former programs. The executables provided with the
PEST MODBORE/MT3D utilities suite were compiled with a Lahey compiler.
However source code is provided for MODBORE and MT3BORE so that you can
recompile them with the compiler of your choice if you wish.
An executable version of MODBORE named MODBORE1.EXE is also supplied. This
has been compiled with the WATCOM compiler and can be used with the Visual
MODFLOW version of MODFLOW.
MT3BORE
49
A4. MT3BORE
A4.1 Function of MT3BORE
MT3BORE reads an unformatted MT3D concentration file, interpolating the arrays
contained therein to a set of points (normally borehole locations) whose coordinates
are supplied by the user.
A4.2 Command Line
MT3BORE is run using the command:
mt3bore
The names of its input files are supplied to it either through direct terminal input or
through file redirection.
A4.3 Discussion
The operation of MT3BORE is almost identical to that of MODBORE. Note,
however, that instead of requesting values for the MODFLOW variables HNOFLO
and HDRY, MT3BORE asks the user for the concentration value that MT3D assigns
to inactive concentration cells, ie. the MT3D variable CINACT. As with MODBORE,
such inactive cells are taken into account as arrays are interpolated to borehole
locations.
MODINS
50
A5 MODINS
A5.1 Function of MODINS
MODINS writes a PEST instruction file which is able to read a MODBORE or
MT3BORE output file to obtain model-calculated heads, drawdowns or
concentrations at a set of user-nominated points for which there are complementary
field measurements.
A5.2 Command Line
MODINS is run using the command:
MODINS boredatfile modborefile insfile
where:
boredatfile
is a bore data file,
modborefile
is a MODBORE or MT3BORE output file, and
insfile
is a PEST instruction file to be built using the bore data file.
A5.3 The Bore Data File
When PEST is used for MODFLOW or MT3D parameter optimisation, the "model"
which it runs is MODFLOW or MT3D followed by MODBORE or MT3BORE
respectively. The "model output file" is thus a MODBORE or MT3BORE output file
listing model-calculated heads, drawdowns or concentrations at a set of borehole
locations supplied by the user. The role of MODINS is to automatically generate a set
of instructions which can read those model-calculated numbers from the MODBORE
or MT3BORE output file for which there are corresponding borehole measurements.
The field-acquired borehole measurements must be supplied to MODINS in a userprepared "bore data file".
A bore data file is illustrated in Example A5.1. Its first column contains bore
identifiers. A given bore must be identified by the same character string (of 10
characters or less) in the bore coordinates file, the bore listing file and the bore data
file. Note, however, that the bore identifier is case-insensitive; MODINS translates it
internally to upper case.
MODINS
RN134532
RN134532
RN134532
RN3492
RN3492
RN75832B
RN75832B
RN75832B
51
200.0
400.0
600.0
200.0
600.0
200.0
400.0
600.0
39.58
36.63
43.05
46.63
48.01
37.98
33.65
39.34
1.0
1.0
1.0
1.0
1.0
1.0
1.0
1.0
h3
h4
h5
h6
h7
h8
h9
h10
Example A5.1 A bore data file.
The second item on each line of the bore data file is the model simulation time. This is
the time, measured from the start of the model simulation, to which the measured
head, drawdown or concentration value (ie. item 3) pertains. This time must
correspond to one of the simulation times at which MODFLOW or MT3D writes one
or a number (depending on the number of layers in the model) of head, drawdown or
concentration arrays to its unformatted output file, and hence at which MODBORE or
MT3BORE writes data to its text output file. If it does not correspond to such a time,
MODINS will be unable to generate an instruction to read the corresponding modelcalculated quantity.
The third item on each line is the borehole-measured head, drawdown or
concentration. This number is not used by MODINS; however it is used by MODGEN
(which reads the same file) in the construction of a PEST control file. The fourth item
on the line is the weight pertaining to the measurement; this is also ignored by
MODINS.
The fifth item on each line of a bore data file is the observation name. This name is
used to reference an observation in an instruction file, in the PEST control file and in
the PEST run record file. Each observation name must be unique and of eight
characters or less in length. It is case-insensitive; MODINS translates it internally to
lower case. MODINS uses the observation name to build the instruction by which the
corresponding model-generated number is read from a MODBORE or MT3BORE
output file.
If there are many borehole water level measurements to be used for model calibration,
construction of the bore data file may be tedious. However it may be helpful to note
that the fourth and fifth columns can be easily filled using the auto-copy and autoincrement functionality of a spreadsheet. Note also that programs within the
Groundwater Data Utilities suite (Doherty, 1996) automate construction of bore data
files on the basis of data easily downloaded from a typical groundwater database.
A5.4 The MODBORE or MT3BORE Output File
Through its command line, MODINS is supplied with the name of both a bore data file
and a MODBORE or MT3BORE output file. After reading the bore data file and
checking it for errors, MODINS reads the MODBORE or MT3BORE output file. It
searches this file for the bores and elapsed model simulation times referenced in the
bore data file. If MODINS is unable to find a certain bore or elapsed simulation time it
generates an appropriate error message. Note that not all bores and times cited in the
MODINS
52
MODBORE or MT3BORE output file need to be referenced in the bore data file.
It is important to note that once MODINS has generated an instruction set by which
the MODBORE or MT3BORE output file can be read for model-calculated numbers
corresponding to the measurements cited in a bore data file, the bore listing file read by
MODBORE and MT3BORE must remain unchanged prior to running PEST. Recall
that PEST runs MODBORE or MT3BORE each time it runs the model; if the bore
listing file is altered, so too will be the MODBORE or MT3BORE output file,
invalidating the instruction set which MODINS built to read this file.
A5.5 The Instruction File
MODINS writes its instruction set to an instruction file nominated on the MODINS
command line. Example A5.2 shows such a file.
pif #
#SIMULATION
l1 [h3]48:65
l1 [h6]48:65
l3 [h8]48:65
#SIMULATION
l1 [h4]48:65
l4 [h9]48:65
#SIMULATION
l1 [h5]48:65
l1 [h7]48:65
l3 [h10]48:65
= 200.000#
= 400.000#
= 600.000#
Example A5.2 An instruction file generated by MODINS.
The instruction set contains only primary markers, line advance items and fixed
observations. The primary markers instruct PEST to search for a header on the
MODBORE or MT3BORE output file corresponding to a particular elapsed model
simulation time. Then follow a series of instruction lines, each containing a line
advance item and an observation. In each case PEST is instructed to advance a certain
number of lines and then read the required head, drawdown or concentration as a fixed
observation.
Note that in spite of some small differences between MODBORE and MT3BORE
output files, the instruction set generated by MODINS is capable of reading both types
of file.
MODGEN
53
A6 MODGEN
A6.1 Function of MODGEN
MODGEN fulfils a similar role to the PEST utility PESTGEN in that it writes a PEST
control file based on a set of user-supplied parameter names and initial values as well
as observation names and values. However, unlike PESTGEN, it obtains the latter
from a bore data file - the same bore data file that MODINS uses to build an
instruction set. Also, default values for certain PEST variables written by MODGEN
to the PEST control file are more suited to MODFLOW and MT3D model calibration
than those supplied by PESTGEN.
A6.2 Command Line
MODGEN is run using the command:
MODGEN case parfile borefile1 [borefile2]
where:
case
is the PEST casename (no extension),
parfile
is the name of a parameter value file,
borefile1
is the name of a bore data file, and
borefile2
is the (optional) name of another bore data file.
A6.3 Discussion
The use of MODGEN is very similar to that of PESTGEN. Like PESTGEN,
MODGEN requires a list of parameter names, initial parameter values, scaling factors
and offsets, as well as a list of observation names and values. Whereas PESTGEN
reads the latter from an observation value file, MODGEN reads them from either one
or two bore data files (the same file(s) used by MODINS to build the instruction set(s)
by which the MODBORE/MT3BORE output file(s) are read). If you wish MODGEN
to include the observations from only one bore data file in the PEST control file (ie. for
individual MODFLOW or MT3D calibration), provide the name of only one such file.
However if you wish MODGEN to use measurements from two bore data files, supply
it with the names of both of these files. The ability to read two bore data files facilitates
its use in cases where a simultaneous MODFLOW/MT3D calibration is undertaken.
One bore data file will then pertain to borehole-measured heads or drawdowns
whereas the other will list borehole-measured concentrations.
The casename is the filename base assigned by MODGEN to the PEST control file
which it generates; an extension of ".PST" is added automatically.
A6.4 The Parameter Value File
Example A6.1 shows a parameter value file. The header line provides values for the
MODGEN
54
PEST variables PRECIS and DPOINT. In most cases the values shown in Example
A6.1 (viz. "single" and "point") are suitable. Then follow a number of lines containing
parameter data; there must be one such line for each parameter involved in the
estimation process. Each line contains a parameter name, initial value, scale and offset
(in that order). Values of 1.0 and 0.0 are normally suitable for the last two quantities.
single point
hc1 3.4
1.0
hc2 2.9
1.0
hc3 7.4
1.0
hc4 0.4
1.0
d1
20.0 1.0
d2
10.0 1.0
0.0
0.0
0.0
0.0
0.0
0.0
Example A6.1 A parameter value file.
A6.5 The Bore Data File
The bore data file was discussed in Section A5.3. MODGEN reads the observation
values, observation weights and observation names from the third, fourth and fifth
columns respectively of the bore data file, transferring this data to the "* observation
data" section of the PEST control file.
A6.6 MODGEN Default Values for PEST Control Variables
When writing the PEST control file, MODGEN uses the same default values as
PESTGEN for most of the PEST control variables cited in this file; see the PEST
manual. However the following differences should be noted.
•
RELPARMAX and FACPARMAX are assigned values of 5.0 instead of 3.0.
•
If a parameter value is positive in the parameter value file, MODGEN assumes that
it should be log-transformed throughout the parameter estimation process. Its
-10
lower bound is assigned a value of 1.0 × 10 and the PARCHGLIM variable for
that parameter is denoted as "factor". MODGEN adopts this convention because
many of the parameters occurring in a groundwater model are more efficiently
estimated if they are log-transformed. In contrast, PESTGEN assigns to all
parameters a transformation type of "none", a change limit of "relative", and a
10
lower bound of -1.0 × 10 .
•
For all parameter groups the increment type is "relative" and is set to 0.02; for
PESTGEN the increment is 0.01. Note that, particularly when calibrating MT3D,
this relative increment (ie. DERINC) may need to be increased to 0.05, and
an absolute lower increment bound (ie. DERINCLB) added.
•
If two bore data files are supplied on the MODGEN command line, two instruction
files and two model output files are listed in the "* model input/output" section of
the PEST control file. Don't forget to alter the default filenames to the correct
filenames before running PEST.
MODGEN
55
Like PESTGEN, MODGEN assigns each parameter to a group of its own. Before
running PEST, it will probably prove more convenient if all parameters of the one type
are assigned to the one group. If you do this, don't forget to adjust the value of
NPARGP on the fourth line of the PEST control file (unless you use PREPEST, in
which case this will be done automatically).
COMPFILE
56
A7. COMPFILE
A7.1 Function of COMPFILE
COMPFILE reads two user-nominated files. As soon as it encounters a difference
between them it writes an appropriate message to the screen and terminates execution
with an errorlevel setting of 100. Its use can save unnecessary MODFLOW runs when
composite MODFLOW/MT3D calibration is undertaken.
A7.2 Command Line
COMPFILE is run using the command:
COMPFILE file1 file2
where:
file1 and file2 are the two files to be compared.
A7.3 Description
If, on reading the files file1 and file2, COMPFILE encounters a difference, it
terminates execution with a message such as:
File FILE1 differs from file FILE2: first difference
line 23.
encountered at
Otherwise, after reading both files in their entirety, COMPFILE prints:
- files FILE1 and FILE2 are identical.
For the use of COMPFILE in increasing PEST optimisation efficiency see Chapter 8.
An Example
57
Appendix B. An Example
The files discussed in this Appendix can be found in the \EXAMPLE subdirectory of
the PEST MODFLOW/MT3D Utilities directory after installation.
B1.1 The Model
Files BAS.DAT, BCF.DAT, RCH.DAT, WEL.DAT, PCG2.DAT, OC.DAT and
NAMEFILE are the input files for a small MODFLOW 96 transient model.
The model grid is rectangular, consisting of 10 rows and 12 columns with a uniform
row and column width of 1000m. The long dimension of the model (ie. the row
direction or direction of increasing column index) is oriented east-west; see Fig B1.1.
Only a single aquifer (comprised of one model layer) is simulated. All cells along the
eastern side of the model are designated as fixed head with an assigned head of 20.0
metres.
Figure B1.1 The model finite-difference grid showing an injection well (hatched) and
fixed-head cells (shaded).
Two stress periods are simulated, each being of 90 days duration. Each stress period is
subdivided into 3 equal time steps of 30 days each. During the first stress period the
-3
regional recharge rate is uniformly 2.5 × 10 m/day; during the second stress period it
is zero. For both stress periods the cell whose row number is 5 and whose column
number is 4 contains a point source of recharge (simulated by a well) supplying water
to the aquifer at a rate of 10 cubic metres per day. Initial heads over the model domain
are everywhere the same as the fixed head at its eastern end, viz. 20m.
The aquifer is confined. It is subdivided into three zones of uniform transmissivity, the
2
transmissivities pertaining to these zones being 1000, 250 and 100 m /day. The
disposition of these zones within the model domain can be easily gleaned from an
inspection of file BCF.DAT; see also Fig. B1.2. The layer storage factor is uniformly
-3
1.0 × 10 .
An Example
58
250
1000
100
Figure B1.2 The model transmissivity zonation (transmissivities in m2/day).
MODFLOW has been instructed to write two output files, viz. a formatted text file
named OUTPUT.DAT, and an unformatted heads file named HEADS.DAT (see the
MODFLOW 96 name file NAMEFILE. Unformatted heads output has been requested
at the end of every time step. Thus 6 heads arrays should reside in file HEADS.DAT at
the end of a MODFLOW simulation run. Files OUTPUT.DAT and HEADS.DAT can
be found in the \EXAMPLE subdirectory of the PEST MODFLOW/MT3D Utilities
directory after installation.
B1.2 Interpolation to a Set of User-Specified Points
File BORES.CRD is a bore coordinates file listing the eastings, northings and layer
numbers (the latter are all equal to 1) of 12 bores spread throughout the model
domain. The identifiers for all twelve of these bores are also listed in a bore listing file,
BORES.LST. A grid specification file, EXAMPLE.SPC, is also provided.
MODBORE can be used to interpolate the heads arrays found in file HEADS.DAT to
the bores listed in file BORES.LST. MODBORE's screen prompts can be answered
either through the keyboard or through file redirection. File MODBORE.IN contains
appropriate responses to MODBORE's prompts. Hence MODBORE can be run using
the command:
modbore < modbore.in
The results are found in the MODBORE output file HEADS.TAB; see the
\EXAMPLE subdirectory. Notice that this file contains a table of heads for each time
step at which MODFLOW unformatted heads output was delivered.
B1.3 Preparing for Parameter Optimisation
Let us now use the model-calculated heads listed in file HEADS.TAB as a set of
measurement heads; PEST will then be used to estimate aquifer transmissivities on the
assumption that all other model parameters are known. File BORES.WL is a bore data
file listing the heads calculated at the bores cited in file HEADS.TAB as though they
were actually measured. It is assumed that water levels at these bores were available at
times corresponding to every model output time ie. every thirty days.
An Example
59
Using program MODINS an instruction file, HEADS.INS, can be generated to read
the MODBORE output file HEADS.TAB in order to obtain model-generated numbers
complementing the "measurements" listed in file BORES.WL. The command is:
modins bores.wl heads.tab heads.ins
HEADS.INS can be found in the \EXAMPLE subdirectory. You can verify for
yourself that the instructions found in HEADS.INS can read the heads listed in
HEADS.TAB by running the PEST utility INSCHEK. Type:
inschek heads.ins heads.tab
Next a template file must be built informing PEST how to write parameter values to
the appropriate MODFLOW input file. In the present instance there are only three
parameters, viz. the transmissivity values in each of the three zones of parameter
constancy comprising the model domain. The MODFLOW transmissivity array resides
in file BCF.DAT between lines 21 and 30.
To generate the template file for BCF.DAT, TEXTREP is used together with the text
replacement file BCF.REP found in the \EXAMPLE subdirectory of the PEST
MODFLOW/MT3D Utilities directory after installation. Through BCF.REP the three
transmissivity parameters are named "t1", "t2", and "t3"; a parameter space for
substitution into the transmissivity array is defined in each case. The character "@" is
selected as the parameter delimiter as it occurs nowhere in file BCF.DAT. To build a
template file named BCF.TPL type the command:
textrep bcf.dat bcf.rep bcf.tpl /@
File BCF.TPL can be found in the \EXAMPLE subdirectory.
At this stage a parameter value file should be constructed listing the parameter names
along with their initial values. File BCF.PAR is such a file; in BCF.PAR all initial
transmissivity values are set to 200.0. The integrity of the template file BCF.TPL can
now be checked using the PEST utility TEMPCHEK. Type
tempchek bcf.tpl test.dat bcf.par
If all is correct, file TEST.DAT should be a valid input file for the MODFLOW BCF
package. You can verify this by inspection, or copy it to BCF.DAT and run
MODFLOW.
To generate the PEST control file, type the command:
modgen trans bcf.par bores.wl
A PEST control file named TRANS.PST is constructed using default values for the
PEST control variables. Although we accept most of these defaults for the present
example, a number of alterations to this file are necessary before PEST can run. So
edit TRANS.PST using your usual text editor. (Alternatively, use the user-friendly
PEST preprocessor PREPEST to make the following alterations to the PEST control
file.) In the "* model input/output" section of this file change the lines:
model.tpl
model.ins
to:
model.inp
model.out
An Example
bcf.tpl
heads.ins
60
bcf.dat
heads.tab
These alterations inform PEST that file BCF.TPL is a template file for the model input
file BCF.DAT and that HEADS.INS is an instruction file for the model output file
HEADS.TAB. Note that both BCF.DAT and HEADS.TAB will be overwritten each
time the model is run during the optimisation process. You must also change the model
command line in the "* model command line" section of the PEST control file from
"model" to "model1". After you have made these changes store the PEST control file
as TRANS_1.PST so as not to overwrite TRANS.PST. Both TRANS.PST and
TRANS_1.PST are provided in the \EXAMPLE subdirectory of the PEST
MODFLOW/MT3D Utilities directory.
To check that all PEST input data is now present and consistent, run PESTCHEK
using the command:
pestchek trans_1
All that now remains is to write the batch file that PEST calls as the model. According
to TRANS_1.PST the model is run using the command "model1"; hence our batch file
must be named MODEL1.BAT. You can use a different name if you wish, as long as
you alter the model command line in TRANS_1.PST.
The MODEL1.BAT file provided in the \EXAMPLE subdirectory incorporates
protection against premature MODFLOW cessation due to solution non-convergence
using the technique illustrated in Example 7.1. The PCG2 package input file (ie. file
-5
PCG2.DAT) supplies a HCLOSE value of 1.0 × 10 . However, five other PCG2 input
files have been prepared, one using this same HCLOSE value (ie. PCG2.H1) and the
others using successively higher HCLOSE values (files PCG2.H2 to PCG2.H5). These
were prepared simply by copying PCG2.DAT and making the necessary alteration
(except for PCG2.H1 where no alteration was required).
As a preventative measure against MODBORE reading an old unformatted
MODFLOW output file (ie. HEADS.DAT) if MODFLOW fails to run altogether (for
example if its directory is not cited in the PATH environment variable, or its X vector
is too large to fit into memory), MODEL1.BAT deletes HEADS.DAT prior to running
MODFLOW. Thus if MODFLOW fails to run, MODBORE will be unable to find the
unformatted heads file and will not produce its own output file tabulating borehole
heads. PEST will then terminate execution with an appropriate error message.
MODEL1.BAT runs MODFLOW using the command:
modflw96 < modflw96.in > nul
This command runs MODFLOW 96 which you should download from the USGS web
site; file MODFLW96.IN provides MODFLOW 96 with its only required terminal
input, viz. "namefile".
B1.4 Running PEST
Now all is ready to run PEST. As explained in the PEST manual, it is best to do this
from a RAM disk. If you do not already have a RAM disk, you should edit your
CONFIG.SYS file to create one and then reboot your machine. If you are using
An Example
61
WINDOWS 95 or WINDOWS 98 and the file RAMDRIVE.SYS is stored in
subdirectory C:\WINDOWS, the following line added to your CONFIG.SYS file
creates a 4Mb RAM disk:
devicehigh=c:\windows\ramdrive.sys 4096 /E
Now, copy all the files from your working directory up to the RAM disk and run
PEST using the command:
spest trans_1
If all is well, PEST will run the model again and again until the objective function (ie.
phi) is reduced to a minimum. If you wish, you can enable MODFLOW and
MODBORE screen output by deleting the characters "> nul" from the commands
listed in file MODEL1.BAT; this will be more appropriate if using WPEST or Parallel
PEST instead of SPEST.
As explained in the PEST manual, PEST execution can be interrupted at any time to
inspect the run record history up to that time by pressing the <Esc> key, selecting the
first menu item, and scrolling through the run record file (named TRANS_1.REC in
the present case). When you have finished this inspection, hit the <Esc> key again,
select the second menu item and PEST execution will resume immediately. At the end
of the optimisation process all run details, including optimised parameter values and
their confidence intervals, can be found in file TRANS_1.REC which you can inspect
at your leisure with any text editor or viewer. This file is supplied in the \EXAMPLE
subdirectory.
Note that PEST execution can be halted completely at any time (hit <Esc> and then
select "Immediate stop" or "Stop with statistics" from the menu). You can resume
execution at a later date by typing the command:
spest trans_1 /r
or
spest trans_1 /j
Note, however, that PEST needs to read certain files which it created during its
interrupted run in order to recommence execution at the right place. Hence make sure
to copy the contents of your RAM disk back to your hard drive before switching your
machine off if you have suspended PEST execution with the intention of
recommencing it at a later date.