PEST Utilities for MODFLOW and MT3D Parameter - Extra Materials

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 model-generated 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


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


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.

Example 2.1 A two-dimensional array comprised of four different numbers.

1.2345 1.2345 1.2345 1.2345 1.2345 6.7543 6.7543 6.7543 1.2345 1.2345 1.2345 1.2345 1.2345 6.7543 6.7543 6.7543 1.2345 1.2345 1.2345 9.6521 9.6521 6.7543 6.7543 6.7543 1.2345 1.2345 1.2345 9.6521 9.6521 9.6521 6.7543 6.7543 1.2345 1.2345 1.2345 9.6521 9.6521 9.6521 9.6521 6.7543 8.4352 1.2345 1.2345 9.6521 9.6521 9.6521 9.6521 9.6521 8.4352 8.4352 1.2345 9.6521 9.6521 9.6521 9.6521 9.6521 8.4352 8.4352 8.4352 9.6521 9.6521 9.6521 9.6521 9.6521 8.4352 8.4352 8.4352 8.4352 9.6521 9.6521 9.6521 9.6521


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.)

Example 2.3 Part of the input to MODFLOW's DRN package.

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

# par1 # # par1 # # par1 # # par1 # # par1 # # par2 # # par2 # # par2 # # par1 # # par1 # # par1 # # par1 # # par1 # # par2 # # par2 # # par2 # # par1 # # par1 # # par1 # # par3 # # par3 # # par2 # # par2 # # par2 # # par1 # # par1 # # par1 # # par3 # # par3 # # par3 # # par2 # # par2 # # par1 # # par1 # # par1 # # par3 # # par3 # # par3 # # par3 # # par2 # # par4 # # par1 # # par1 # # par3 # # par3 # # par3 # # par3 # # par3 # # par4 # # par4 # # par1 # # par3 # # par3 # # par3 # # par3 # # par3 # # par4 # # par4 # # par4 # # par3 # # par3 # # par3 # # par3 # # par3 # # par4 # # par4 # # par4 # # par4 # # par3 # # par3 # # par3 # # par3 #

1 19 43 2.000E+01 3.000E+00 1 20 43 2.000E+01 3.000E+00 1 21 43 2.000E+01 3.000E+00 1 22 44 2.000E+01 3.000E+00 1 23 45 2.000E+01 3.000E+00 1 24 46 2.000E+01 5.000E+00 1 25 46 2.000E+01 5.000E+00 1 26 46 2.000E+01 5.000E+00 1 27 46 2.000E+01 5.000E+00 1 28 45 2.000E+01 5.000E+00 1 29 44 2.000E+01 5.000E+00 1 30 43 2.000E+01 5.000E+00 1 31 43 2.000E+01 5.000E+00

1 19 43 2.000E+01 # con1 # 1 20 43 2.000E+01 # con1 # 1 21 43 2.000E+01 # con1 # 1 22 44 2.000E+01 # con1 # 1 23 45 2.000E+01 # con1 # 1 24 46 2.000E+01 # con2 # 1 25 46 2.000E+01 # con2 # 1 26 46 2.000E+01 # con2 # 1 27 46 2.000E+01 # con2 # 1 28 45 2.000E+01 # con2 # 1 29 44 2.000E+01 # con2 # 1 30 43 2.000E+01 # con2 # 1 31 43 2.000E+01 # con2 #


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 easily-prepared "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 easily-acquired 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.


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


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


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


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:


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.

XY

hyx+hyx+hyx+hyx=h 1+j,1+i11j,1+i121+ji,21ji,22


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


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


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


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


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.


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, that its lower bound is -1.0 × 1010, 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, that its lower bound is 1.0 × 10-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.


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 value of about 1.0 × 10-4 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


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 using the preprocessor, you had entered HCLOSE as 1.0 × 10-5, this will be the HCLOSE value written to PCG2.DAT. You should alter this value in PCG2.H2 to 2.0 × 10-5; in PCG2.H3 it should be altered to 4.0 × 10-5, in PCG2.H4 to 8.0 × 10-5, and in PCG2.H5 to 2.0 × 10-4. (Make sure that you adhere strictly to the correct input file


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.

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

@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


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


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


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 34

Example 8.1 A batch file for joint MODFLOW/MT3D parameter estimation.

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 against premature termination. copy bcf.hld bcf.dat copy pcg2.h1 pcg2.dat modf < modffile modbore < modbore.in if not errorlevel 100 goto label2 copy pcg2.h2 pcg2.dat modf < modffile modbore < modbore.in if not errorlevel 100 goto label2 copy pcg2.h3 pcg2.dat modf < modffile modbore < modbore.in if not errorlevel 100 goto label2 copy pcg2.h4 pcg2.dat modf < modffile modbore < modbore.in if not errorlevel 100 goto label2 copy pcg2.h5 pcg2.dat modf < modffile modbore < modbore.in if not errorlevel 100 goto label2 :label1 modbore < modbore.in rem Run MT3D. :label2 mt3d < mt3dfile mt3bore < mt3bore.in

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 thickness-integrated 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 is a MODFLOW or MT3D input file, arrayfile is a file containing a MODFLOW-compatible data array, and modfile2 is a MODFLOW or MT3D input file generated by replacing a user-

specified 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

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.

Example A1.2 Header line to an array on a MODFLOW input file; the array descriptor is optional.

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

11 1(86G12.0) 1 transmissivity of layer 1

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 two-dimensional 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 42

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.

Example A2.2 Lines 29 to 36 of a model input file.

" 1.200" "# p1 #" 29 56 " 4.345" "# p2 #" 29 56 " 4.54E+04" "# p3 #" 57 92 " 5.00E+04" "# p4 #" 57 92 " 7.600" "# p5 #" 78 102 " 1.200" "# p6 #" 78 102

1.200 1.200 1.200 6.593 6.593 6.593 6.593 1.200 1.200 1.200 6.593 6.593 6.593 6.593 1.200 1.200 1.200 6.593 6.593 6.593 6.593 1.200 1.200 1.200 4.345 4.345 4.345 4.345 1.200 1.200 4.345 4.345 4.345 4.345 4.345 1.200 1.200 4.345 4.345 4.345 4.345 4.345 1.200 1.200 4.345 4.345 4.345 4.345 4.345 1.200 4.345 4.345 4.345 4.345 4.345 4.345

TEXTREP 43

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.

# p1 # # p1 # # p1 # 6.593 6.593 6.593 6.593 # p1 # # p1 # # p1 # 6.593 6.593 6.593 6.593 # p1 # # p1 # # p1 # 6.593 6.593 6.593 6.593 # p1 # # p1 # # p1 # # p2 # # p2 # # p2 # # p2 # # p1 # # p1 # # p2 # # p2 # # p2 # # p2 # # p2 # # p1 # # p1 # # p2 # # p2 # # p2 # # p2 # # p2 # # p1 # # p1 # # p2 # # p2 # # p2 # # p2 # # p2 # # p1 # # p2 # # p2 # # p2 # # p2 # # p2 # # p2 #

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.

Example A3.1 A grid specification file.

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

MODBORE 45

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 list-directed 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

30 degrees

(300000E, 7800000N)

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.

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.

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:

RN134532 RN3492 RN5590 RN75832A RN75832B

RN134532 332456.456 7854234.938 1 RN3492 335487.481 7855028.891 2 RN5590 331849.493 7803290.492 1 RN75832A 332901.301 7849015.091 1 RN75832B 332901.301 7849015.091 2 RN4334 331904.398 7830455.392 1

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 two-dimensional 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

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.

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

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 user-prepared "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 51

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 model-calculated 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 auto-increment 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

RN134532 200.0 39.58 1.0 h3 RN134532 400.0 36.63 1.0 h4 RN134532 600.0 43.05 1.0 h5 RN3492 200.0 46.63 1.0 h6 RN3492 600.0 48.01 1.0 h7 RN75832B 200.0 37.98 1.0 h8 RN75832B 400.0 33.65 1.0 h9 RN75832B 600.0 39.34 1.0 h10

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.

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.

pif # #SIMULATION = 200.000# l1 [h3]48:65 l1 [h6]48:65 l3 [h8]48:65 #SIMULATION = 400.000# l1 [h4]48:65 l4 [h9]48:65 #SIMULATION = 600.000# l1 [h5]48:65 l1 [h7]48:65 l3 [h10]48:65

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.

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 lower bound is assigned a value of 1.0 × 10-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 lower bound of -1.0 × 1010.

• 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.

single point hc1 3.4 1.0 0.0 hc2 2.9 1.0 0.0 hc3 7.4 1.0 0.0 hc4 0.4 1.0 0.0 d1 20.0 1.0 0.0 d2 10.0 1.0 0.0

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 encountered at line 23.

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 regional recharge rate is uniformly 2.5 × 10-3 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 transmissivities pertaining to these zones being 1000, 250 and 100 m2/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 1.0 × 10-3.

An Example 58

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.

250

1000 100

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.inp model.ins model.out

to:

An Example 60 bcf.tpl bcf.dat heads.ins 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 PCG2.DAT) supplies a HCLOSE value of 1.0 × 10-5. 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.

PEST Utilities for MODFLOW and MT3D Parameter - Extra Materials

Documents