Gv8 Tutorial Manual-4

PEST and Pilot Points
Introduction
Written by
John Doherty
Watermark Computing
Adapted for Groundwater Vistas by
Jim Rumbaugh
Environmental Simulations, Inc.
This tutorial demonstrates some of the advanced and exciting opportunities for model calibration available
through PEST and supplementary software available through the Groundwater Data Utilities. By the time
you have finished this exercise you will have:
- used pilot points as a means of characterising the spatial distribution of an aquifer hydraulic
property;
- used PEST’s advanced regularisation functionality in conjunction with geostatistically-based
regularisation constraints;
- used Groundwater Vistas to assist in PEST input file preparation.
This exercise is based on the Groundwater Visas (GV) graphical user interface (GUI), which simplifies the
use of PEST and some of the utility programs related to pilot point calibration.
Strategy used in the Present Exercise
In the present exercise MODFLOW will only be run as a “forward model”; ie. it will be run to calculate
outputs - in this case head outputs. Furthermore, spatial interpolation of MODFLOW-generated heads to
the sites of bores will not be undertaken using the MODFLOW-2000 observation process; rather it will be
undertaken using Groundwater Vistas’ targpest program. In some contexts, as is demonstrated below, this
facilitates preparation for a PEST run. Furthermore, the same utilities can be used to interpolate MT3DMS
concentration outputs to the sites of bores. (There is no observation process within MT3DMS to do this, so
the use of such external spatial interpolation software is a necessity.)
In the present exercise the spatial distribution of transmissivity (rather than of hydraulic conductivity)
within the model domain will be estimated on the basis of borehole head and concentration measurements.
Estimation of transmissivity is entirely appropriate in the present case because we will be simulating steady
state water levels in a heterogenous aquifer in which the spatial distribution of bedrock depth is only poorly
known. Because parameter estimation is restricted to transmissivity only, the MODFLOW bcf package will
be used in preference to the MODFLOW-2000 lpf or huf packages. Use of this strategy allows us to set the
MODFLOW LAYCON variable to zero for the single layer comprising the model; this allows MODFLOW
to run quickly (an advantage in the present circumstances), and removes the possibility of any numerical
problems being encountered through the drying and rewetting of cells.
For the present exercise the MODFLOW, rather than MODFLOW-2000, version of MODFLOW is used.
However use of MODFLOW-2000 would be almost identical.
Description of Study Area

Figure 1 shows a MODFLOW grid set up over a (theoretical) study area. Grid cells are 40m wide, except
for a band of cells which cross in the centre of the study area which are 20m wide.
Groundwater Vistas Version 8 Page 176

Figure 1. Map of finite-difference grid, river, source of contamination and
alluvial boundaries. Scale: 1cm=200m.
A river runs along the south-western boundary of the study area, simulated by a line of fixed head cells in
the model; the head in the river is 20m. To the north-east of the river, and running parallel to it, is a broad
band of alluvium. Not many holes have been drilled all of the way through this alluvial material into the
rocks which underlie it; hence information on basement depth is only sporadic. Nevertheless, based on
those holes that have been drilled to date, alluvial thickness seems to average about 30m. An old creek
channel, oriented in a north-easterly direction, exists in the north of the study area. The alluvium in this old
creek channel is not quite as thick, and not quite as hydraulically conductive, as that in the main alluvial
band running parallel to the river. To the east and west of this old creek channel are basaltic rocks. Though
not as permeable as the alluvium, these rocks are nevertheless able to conduct water through fractures and
vesicles, the latter occurring especially at the interface between successive flows.
Because the present study area is actually a figment of my imagination, I am able to disclose to you the
“real” distribution of transmissivity within the geological units which underlie it; see Figure 2. (This was
generated with the help of a stochastic field generator based on Mejia’s algorithm.) Within the main
alluvial unit, transmissivity varies between about 65 m2|day and 140 m2|day, being generally higher
downstream and closer to the river. Within the old creek system, transmissivity varies between 60m2|day
and 80m2|day. Transmissivity is uniformly 20m2|day in the western basalt and uniformly 30m2|day in the
eastern basalt.
Effective porosity of all alluvial material is 0.07.

Figure 2. Transmissivity distribution within the study area. Contour interval is
10m2|day; darker shade indicates greater transmissivity. The site where
contaminant is introduced to the groundwater system is also shown.
The north-west and south-east boundaries of the model domain have been chosen to coincide with
groundwater flow lines. The north and north-eastern boundaries coincide with a groundwater divide.
Recharge to the groundwater system is different within each of the geological units prevailing in the study
area. Within the broad alluvial system associated with the river, recharge is 7×10-4m|day (about 255
mm|yr), while within the smaller alluvial unit comprising the old creek system, recharge is 5×10-4m|day
(about 180 mm|yr). In the basalt unit to the west of this, recharge is 1×10-4m|day (about 36 mm|yr) whereas
in the basalt unit to the east of the old creek system, recharge is 2×10-4m|day (about 72 mm|yr).
The focus of interest in the present study is a site whose dimensions are about 60m ×60m situated within
the main alluvial unit near the place where it is joined by the old creek system; see Figure 2. Drilling and
water sampling within the main alluvial unit to the south-west of that site has revealed a contaminant plume
originating from under the site. A study of management records at the site has revealed that leakage has
probably been occurring for about 1500 days; however as soon as it was detected, measures were
immediately taken to prevent any further leakage. The contaminant leakage rate was such that there was
minimal effect on the overall groundwater recharge rate under the site. However recharge waters entering
the groundwater system under the site over the 1500 days during which leakage took place contained
contaminant at a concentration of 100 units|m3.
Figure 3 shows the steady state piezometric surface within the study area, as well as the disposition of the
contaminant plume at the time its presence was first detected, ie. after 1500 days of continuous leakage. As
is the case for the geological map pictured in Figure 2, when we come to calibrate a model for this study
area shortly, we will not have the luxury of knowing either the head or contaminant distribution in anything
like the detail pictured in Figure 3.

Figure 3. Piezometric and contaminant concentration contours 1500 days after
commencement of leakage. Heads are in metres. In this, and similar diagrams,
a logarithmic contour interval is used for contaminant concentration, the
lowest contour level being 0.05 units|m3.
Figures 4 and 5 depict the fate of the contaminant over time if no remedial action is taken. Over a period of
5000 days, starting at the time of commencement of leakage into the groundwater system, 324112 units of
contaminant will enter the river at the lower end of the groundwater system. Only about 15 of these units
entered the river during the 1500 days of leakage. A total of 378000 units of contaminant actually entered
the groundwater system under the leaking site during the 1500 days over which leakage took place.

cessation of leakage. Heads are in metres. A logarithmic contour interval is
used for concentration, the lowest contour level being 0.05 units|m3.

cessation of leakage. Heads are in metres. A logarithmic contour interval is
used for concentration, the lowest contour level being 0.05 units|m3.

Using a Model
No model should ever be built without a clearly defined purpose in mind. In the present case the reason is
clear. We have been asked to test the efficacy of extracting water from a single location within the
contaminant plume, and of treating the water to remove contaminant from it. The treated water will then be
released elsewhere. For the present purposes it will be assumed that it does not make its way back into the
groundwater system, at least not within the model area. The aim of the remediation system is to intercept
the contaminant before it emerges in the river which crosses the base of the study area. If no remediation
system is in place, all of the 378000 units of contaminant that entered the groundwater system will find
their way into the river; as was explained above, 324112 units will have entered the river by the time 5000
days have elapsed since leakage began. Let us assume that a regulatory requirement has been set specifying
that total contaminant outflow to the river up until this time must not exceed 10000 units.
The location of the single extraction bore is shown in Figure 6 superimposed on the plume when its
presence was first detected 1500 days after leakage into the groundwater system began. The bore will pump
continuously at a rate of 300m3|day (about 3.5 l|sec).
Figure 6. Location of extraction bore.
If we had complete knowledge of the hydraulic properties of the system it would be a simple matter to
simulate the efficacy of the proposed remediation strategy on a computer, and thereby ensure that the
regulatory requirement is met. Unfortunately, many modelling efforts are conducted under the pretence that
such perfect knowledge of the system exists, for they do not take account of the fact that uncertainties in
model parameterisation can lead to large uncertainties in model predictions. For the purposes of the present
practical exercise we will assume that we know a lot about the system - more than we would probably
know in real life; we will assume that our knowledge of recharge, the source concentration of the
contaminant, the disperssivity and effective porosity of the subsurface, and the amount of time over which
the contaminant was leaking, are all perfect. However we will acknowledge that we do not know the details
of the geologically complex medium pictured in Figure 2. Hence we will parameterise our model in a way
that accommodates the existence of such geological heterogeneity, and explore the predictive uncertainty
arising from our lack of knowledge of the details of this heterogeneity.
But before we do any of that, let us find the “answer at the back of the book” by running a
MODFLOW|MT3DMS model on the basis of the “true” geological conditions.

Running the Model
The “true” model is provided in Groundwater Vistas format as ex1.gwv. Launch Groundwater Vistas and
open this file. You should see the following on your screen:
The model is run over two stress periods, the first of 1500 days duration and the second of 3500 days
duration; during the second stress period the extraction bore operates continuously. Steady state conditions
are assumed to prevail over both stress periods. (This is a slight violation of reality as some time must
elapse before water levels adjust to the introduction of pumping; however as the adjustment time is not
large in comparison to the length of the stress period, the errors incurred by this assumption are likely to be
minimal. Use of this strategy has the beneficial effect that file transfer between MODFLOW and MT3D is
minimised, for only a steady state flow field needs to be passed between the two models during every stress
period.)
The model possesses only a single layer, three-dimensional aspects of the flow and transport processes
being neglected for the present purposes.
Run the model now from Groundwater Vistas by pressing the calculator button on the toolbar.
Create datasets when prompted.
Import the results of the simulation for the first stress period and first time step. The default stress period is
2 when you are prompted to import the results. You must change it to 1 in order to have your plot look like
the one below.
Your contours should be the same as those shown below:

Now, close the ex1.gwv model. We will start with another version for the calibration exercise. Open the
file ex1a.gwv and use that model for the remaining sections.
Calibrating the Model using Water Level Data Only

As a first step in the calibration process we will attempt to estimate the distribution of transmissivity within
the model domain using borehole water level data only. It will be shown that, even where there is a
relatively high borehole density, the use of water level data alone in the calibration process does not
provide sufficient information to resolve geological fine detail through the calibration process. In many
cases of model deployment, such as water supply applications, this fine detail does not matter. However it
is often of crucial importance when predicting the movement of a contaminant through the subsurface.
When carrying out the model runs documented above, “true” hydraulic properties of the model domain
were used in the model. However in the present instance our task is to attempt to infer hydraulic properties
of the system by calibrating the model, and then to use the properties determined during this calibration
process to make predictions using the model. As mentioned above, we will assume that recharge is
perfectly known; we will also assume that the boundaries between the alluvial material and the basalt, and
between the river and creek alluvia, are well mapped. So the aim of the calibration process is to infer the
distribution of transmissivity within each of the four different zones within our study area, these being:-
- the river alluvium (referred to as “zone 1”);
- the creek alluvium (referred to as “zone 2”);
- the western basalt (referred to as “zone 3”); and
- the eastern basalt (referred to as “zone 4”).
Figure 7 depicts the zonation of our model domain.

Zone 3
Zone 2
Zone 1 Zone 4
Figure 7. Zonation of the model domain.
You can see these zones by opening the Groundwater Vistas model called ex1a.gwv. Select
Props|Hydraulic Conductivity and your screen should look like the one below:

Pilot Points
Using conventional model calibration technology, the calibration process would probably proceed by
defining four parameters, (viz. the transmissivity associated with each of the above zones), and adjusting
these parameters until the fit between model outcomes and field observations is as good as possible. If the
goodness of fit obtained on the basis of these four zones was not acceptable, then extra zones would be
introduced into the model domain at locations where the modeller felt that they would “do the most good”;
the parameterisation process would then be repeated with the new parameters included. If a good fit was
still not obtained, more zones would then be introduced. The process would continue until the fit between
model outcomes and field observations was acceptable.
There are a number of shortcomings associated with this approach. These include the following:
- The procedure is quite laborious and slow.
- In a case such as the present one, geological mapping provides no guidance on where to put extra
zones; hence the final distribution of zones that the modeller achieves using this process is likely
to be subjective and non-unique.
- Characterisation of geological heterogeneity in the present study area by zones of piecewise
uniformity is not in harmony with the nature of the alluvial material; therefore any zonation
pattern that is finally decided upon will not “look right”; it will be defensible only on the basis that
it is better to employ such a zonation scheme than to ignore geological heterogeneity altogether.
- Piecewise constancy as a method of characterising geological heterogeneity lacks the flexibility
required to explore the effects of small scale geological variability on model predictive
uncertainty.
To overcome these problems, the distribution of transmissivity within the model domain will be described
by a set of pilot points. A number of these pilot points will be introduced to the model domain and PEST
will be asked to estimate the transmissivity of the aquifer at each such point. These “point-transmissivities”
will then be spatially interpolated to all of the active cells within the model domain using kriging. Hence in
estimating transmissivity values at pilot points, PEST will effectively be assigning parameter values to the
whole of the model domain.
Individual pilot points can be assigned to different zones within the model domain. Only those points
assigned to a particular zone can be used in calculating transmissivity values throughout that zone using the
kriging interpolation procedure. Furthermore, the variogram upon which kriging is based can be different in
each zone, reflecting differences in the geology, or in the level of heterogeneity, expected within each
geological unit. Note that if only one pilot point is assigned to a particular zone, then that zone is
characterised as being uniform. This will be done for zones 3 and 4 in our present study.
The locations of pilot point used in the present calibration exercise are plotted in Figure 8. The pilot points
are provided to you in a text file called c:\gwv8\tutorial\pilots.dat. Import this file into GV as described
below:
Select AE|Import|Target Text File (GV uses calibration targets to store pilot point information – pilot
points are a type of target in GV). Locate the file called c:\gwv8\tutorial\pilots.dat.
Change the Target Type at the top from “Head” to “Pilot Point (Kx)” by selecting from the drop-down list
of types. Enter a zero (0) for number of lines to skip.
Enter a value of 0 next to Layer.
Enter a value of 5 next to Target value (this means that the initial Transmissivity is in column 5).
Enter a 6 next to Minimum K and 7 next to Maximum K
Leave the other numbers on the dialog at default values.
Fill out the dialog in GV as shown below:

After clicking OK, GV should report that 35 targets (pilot points) were imported. Just to make sure that
you imported these pilot points correctly, double-click on one of the target symbols (a circle inside a cross).
(Note: You will need to push down the A button on the toolbar in order to edit pilot points) You
should see a target dialog like the one below. Make sure the target value is 30 and the target type is Pilot
Point (Kx).

Now we will import another set of targets that are our water level calibration targets. These data are
provided in a file called c:\gwv8\tutorial\Pesttargets.dat.
Select AE|Import|Target Text File and located the file called c:\gwv8\tutorial\Pesttargets.dat.
These targets are transient, representing the end of the first stress period (elapsed simulation time = 1500
days). Check the option that says File Contains Transient Targets and change the target type to Head (GV
remembers you imported pilot points before so you have to change it to Head). Before you change the type
to Head also enter zero in the fields next to Minimum Bound and Maximum Bound.
Also check the option that says Read One Target Value for Transient Targets.
Enter a value of 1500 for the target time value.
Enter a value of 4 next to Target Value.

GV should report that 21 targets were imported.

Figure 8. Locations of pilot points (open diamonds); observation bore
locations are shown as closed circles.
The placement of pilot points at the locations shown in Figure 8 is somewhat subjective. Nevertheless a
strategy was followed in choosing their locations:-
- One point was assigned to each of zones 3 and 4 to make them effectively uniform, as described
above.
- Where more than one point was assigned to a zone, the points were distributed pervasively
through the zone, including right up to the zone boundaries (especially the downstream boundary,
as this gives PEST the chance to implant continuous geological structures in the subsurface which
may have a pronounced effect on the movement of contaminants within it).
- Pilot point density was increased where there is greater density of observation points.
Conventional wisdom dictates that the number of parameters involved in a parameter estimation exercise
should be kept to a minium. However when using pilot points in conjunction with PEST’s new
“regularisation” mode, the opposite is often true. PEST’s regularisation functionality prevents the onset of
numerical instability, which often accompanies attempts to solve over-parameterised inverse problems.
Furthermore, a superfluity of pilot points allows PEST to achieve a much better fit between model
outcomes and field observations. PEST’s regularisation functionality will be discussed shortly. For the
moment, we will use pilot points without regularisation in parameterising our model.
Spatial Interpolation using Pilot Points
The use of pilot points in characterising the spatial distribution of a hydraulic property must be
accompanied by a mechanism whereby hydraulic property values assigned to pilot points are spatially
interpolated to the cells of the finite difference grid. If using programs provided with the Groundwater Data
Utilities, spatial interpolation is accomplished using the kriging algorithm. Kriging is a method of spatial

interpolation based on geostatistics. The cornerstone of geostatistics is the variogram; a variogram
describes the extent to which hydraulic property values (or any other type of data) pertaining to any two
points are likely to be different from each other as a function of the distance between those points. See
Section 5 of Part A of the Groundwater Data Utilities manual, or any standard text on geostatistics, for
more details.
One of the benefits of using kriging as a basis for spatial interpolation is that the factors by which hydraulic
properties at pilot points are multiplied before summation to obtain the hydraulic property value at a
particular grid cell are independent of the actual hydraulic property values at the pilot points. Hence a set of
“kriging factors” pertaining to each of the cells of the finite difference grid can be calculated in advance of
the actual interpolation process. As the latter is undertaken again and again as the model is run repeatedly
by PEST, the fact that it is not necessary to repeat calculation of the kriging factors on each occasion that
the model is run can result in large savings in the time required to complete the overall parameter
estimation process.
Calculation of kriging factors is undertaken by program PPK2FAC, which is run automatically from GV
when you use pilot points. GV will create the necessary files for PPK2FAC and run the program. In some
cases, though, it may be necessary to run the program from the command line. We will show you how to
do that below.
Variograms upon which these kriging factors are based are supplied to PPK2FAC in a “structure file”. For
full details of the specifications of this file, see the documentation to the Groundwater Data Utilities. GV
can create the structure file by first selecting Model|PEST|Options – Structures Tab. There are next and
previous buttons at the bottom of the dialog to allow you to scroll through each structure definition.
Three geostatistical structures are defined for the present example. Each of these structures cites one
variogram (though it could cite up to five). “Structure1” will be used to characterise zone 1 of our model
domain (ie. the river alluvium), “structure2” will be used to characterise zone 2 (ie. the creek alluvium)
whereas “structure3” will be used to characterise zones 3 and 4. Note that the variogram assigned to these
latter zones is quite unimportant; because there is only one pilot point assigned to each of them, all cells
within these zones will be assigned the one interpolated value (same as the respective pilot point)
irrespective of the variogram.
The variogram assigned to “structure1” represents the river alluvium. This is an exponential variogram
(VARTYPE=2) with a range of about 1500m (three times the value of the “A” variable appearing in the
variogram specification). In contrast to variogram2, which is assigned to “structure2” (representing the
creek alluvium), there is no anisotropy associated with “vario1”. However for “vario2” the anisotropy value
is 2.0, with the direction of anisotropy coinciding with the direction of the creek. Alignment in the direction
of the creek is based on the premise that channel structures within this old creek valley will make it more
likely for hydraulic property similarity to prevail in this direction than in a direction at right angles to it.
These structures have been defined for you in the ex1a.gwv model. Select Model|PEST|Options -
Structures Tab and look at each of the three structures. The first is shown below.

Note: When filling out this dialog for your own model, the key items are the following:
- Use Exponential variogram
- The anisotropy should be 1
- The Alpha parameter should be about 20% of the maximum length or width of your model domain
- Search radius should be high enough that you will find several pilot points from any point within
the area being estimated.
- Set contribution to 1.
- All other fields can be left at default levels.
Note also that for all of the structures the TRANSFORM variable is set to “log”. Thus any variogram cited
in each of these structures must pertain to the spatial distribution of the logarithm of the pertinent hydraulic
property. This is in accord with the fact that most studies cited in the groundwater literature which treat
transmissivity and|or hydraulic conductivity as a regionalised variable, indicate that its distribution is better
described by a log variogram, rather than a variogram based on native property values.
To implement pilot points in GV, you just need to define the pilot point locations as we did above.
Select Model|PEST|Options - Basic Options tab

Check the option to include pilot points as shown below.
You also need to check the option to write arrays as external files. This is necessary to allow the use of
some of PEST’s utility software to generate the transmissivity arrays. If you forget, GV will set this
automatically when you create the PEST datasets.
Also check the option to run the models without screen output. This allows you to see the Pest output on
the screen.
It is always a good idea to create a new set of MODFLOW input files after making changes to PEST
options. Select Model|MODFLOW|Create Datasets now. Confirm that these settings have been turned on
and then select Model|PEST|Create Data Sets. You should see some DOS windows come up as GV runs
the PEST utility software.
Program PPK2FAC will now be run in order to generate a set of kriging factors by which the transmissivity
at each cell centre can be calculated from the transmissivities assigned to the pilot points.
After PKKFAC has run to completion three new files will exist in your working directory. Factors1.dat
contains kriging factors for all active cells in the model domain. Sd1.ref contains a MODFLOW-compatible

array in which the square root of the “kriging variance” is recorded for every active cell. This is a measure
of the uncertainty associated with the spatial interpolation process, calculated from the geostatistical
structure assigned to each zone. Finally, file reg1.dat contains information that will allow program
PPKREG to add a series of “regularisation prior information equations” to the parameter estimation process
later; see below.
Figure 9 shows that the “kriging uncertainty” increases with distance from the nearest pilot point; if a pilot
point falls exactly at the location of a cell centre, then the kriging uncertainty at that cell centre is zero.
Also, the uncertainties in zone 2 are elongated along the direction of the creek in accordance with the
anisotropic nature of the geostatistical structure assigned to that zone. The kriging uncertainty pattern for
zones 3 and 4 is circular due to the fact that there is only one pilot point assigned to each of these zones.
Fig. 9 “Kriging uncertainty” calculated by PPK2FAC on the basis of the

geostatistical structures contained in file struct.dat. Darker colours indicate
higher uncertainty.
Interpolation of hydraulic property values assigned to pilot points to the centres of cells comprising the
finite difference grid is undertaken using program FAC2REAL. In a pilot point file, the value assigned to
each point comprises the fifth element of each line. GV creates this file and calls it points#.dat where # is
the layer number. In this example, there is only one layer so the file is called points1.dat.
FAC2REAL writes a MODFLOW-compatible array of real numbers to a file named root#._kx where # is
the layer number and root is your root file name for the MODFLOW run (ex1a in this example). The
elements of this array are comprised of numbers interpolated from the sites of pilot points to the centres of
finite-difference cells comprising zones 1, 2, 3 and 4 of the model domain. Spatial interpolation is carried
out by applying the kriging factors calculated by PPK2FAC to the pilot point values supplied in the fifth
column of the pilot points file. It is important to note the following aspects of the interpolation process
carried out by FAC2REAL.
FAC2REAL can apply upper and lower limits to interpolated values at cell centres. This can be very useful,
for interpolated values can sometimes be higher or lower (even negative) than any of the values assigned to
the pilot points; this is more likely to happen when pilot points are close together and when the Gaussian
variogram is used. In the present instance the lower interpolation limit is set uniformly at 10-6 and the upper

interpolation limit is set uniformly at 106. However you can supply these limits on a cell-by-cell basis (this
is not supported by GV).
If any of the geostatistical structures cited in the structure file supplied to program PPK2FAC have a
TRANSFORM value of “log”, this information is recorded in the kriging factor file written by PPK2FAC.
FAC2REAL, when calculating a spatially interpolated value on the basis of pilot points to which such a
geostatistical structure applies, takes the log of each pilot point value before applying the respective kriging
factor. After the log of the interpolated hydraulic property value is calculated by summation of kriging
factors times respective log-transformed pilot point values, the resultant value is raised to the power of 10
to “untransform” it before it is recorded in FAC2REAL’s output file.
If there are any cells to which interpolation does not take place (either because they lie within a zone for
which no kriging factors were calculated, or because they are located at a greater distance from any pilot
point than the search radius supplied to PPK2FAC), then FAC2REAL records a user-supplied dummy
value for these cells. In the present case this dummy value is 1035. Since MODFLOW would probably
object to a K or T value of 1035, Groundwater Vistas runs a program called kmakr.exe after FAC2REAL
runs. The kmakr program substitutes K or T values into the matrix when it finds a 1035 number. The K or
T value is the default value in your model for the zone containing that cell.
GV creates the necessary information for FAC2REAL and creates a new model batch file called pestgv.bat
which will run the FAC2REAL program before running MODFLOW. As stated in the last bullet above,
GV also runs a program called kmakr right after the FAC2REAL program.
Preparing for a PEST Run

Initially our model will be calibrated on the basis of water levels only. PEST input file preparation will be
carried out with assistance Groundwater Vistas. Files prepared in this way will then be amended in order to
carry out more advanced analysis of the measurement dataset using PEST in the following sections.
When using pilot points to parameterise a groundwater model, the parameters to be estimated are the values
(in this case transmissivity values) assigned to the pilot points. Pilot points are assigned values in a pilot
points file; so our first task in preparing for a PEST run is to build a template file based on a pilot points
file. GV does this automatically, however, when you created Pest input files above.
MODFLOW produces a plethora of output data in many different files. However from the point of view of
calibrating the current model, the only output quantities that are important to us are MODFLOW-generated
heads spatially interpolated to the sites of the observation bores depicted if Figure 6. The task of spatially
interpolating MODFLOW outputs to discrete points within the model domain is carried out by a program
called targpest.exe supplied with Groundwater Vistas. Groundwater Vistas creates a file called
targpest.dat that supplies the necessary target information to targpest.exe. The advantage of using targpest
is that it reads the MODFLOW head-save binary file directly which means that you get maximum precision
in the computed head values. If you inspect the file pestgv.bat in a text editor, you will see that the targpest
command immediately follows the MODFLOW run.
Just so to make sure that we have all of the files we need, select Model|MODFLOW|Create Datasets.
That makes the MODFLOW input files for a single run.
Now select Model|PEST|Create Datasets which writes all of the PEST input files and runs some of the
PEST utility programs.
PEST requires three types of input file, viz. one or more template files, one or more instruction files and a
PEST control file. Groundwater Vistas builds all of these files for you so there is little effort in running
PEST from GV. The GV approach, though, assumes that you will be using the targpest program to
interpret MODFLOW output. If you want to use the Groundwater Data Utilities that come with PEST, then
you would need to do a lot of editing of the PEST files in a text editor.
Even though GV takes care of your PEST files, there can sometimes be problems that will cause the input
files to be incorrectly formatted. For this reason, it is usually a good idea to run the PEST checking utility
called pestchek. To do this, select Model|Pest|Run Pestchek.
PESTCHEK should report no errors or inconsistencies.

Running PEST
You should now run PEST directly from GV by selecting Model|PEST|Run PEST. If nothing happens
then the PEST software is not in the current path for your computer. See the Introduction chapter of the
main User’s Guide (gv8maual.pdf) for information on how to add the gwv8 folder to the system path.
After a few iterations you will notice that PEST has lowered the objective function to an incredibly low
value. You can either stop PEST then, or let it run to completion. To stop PEST, select Model|PEST|Stop
Pest. It is apparent from an inspection of the run record file hcal.rec that PEST is able to match every
model output to every field observation almost exactly. Thus, in spite of the fact that there are often serious
numerical problems encountered in cases where observations outnumber parameters, PEST was able to
achieve a perfect solution to the present inverse problem.
After a PEST run is complete, optimised parameter values are listed in the run record file (in this case
ex1a.rec). They are also recorded in a “parameter value file”, in this case ex1a.par. You can look at these
files from GV by selecting Model|PEST|View Main Output File or Model|PEST|View Parameter
Estimates. GV launches a text editor (notepad by default) to show these output files.
As usual, MODFLOW-generated heads are to be found in ex1a.hds. You can select Plot|Import Results
and click OK to view the calibrated heads. Select Plot|Calibration|Stats-Plots to see the calibration
statistics. If you click the button to plot observed versus simulated heads, your plot should look similar to
the following:

This is remarkably good!
Also, the transmissivity distribution used by MODFLOW (spatially interpolated from the locations of the
pilot points) is found in file ex1a1._kx. If you imported this array into GV for graphical display you would
see that the optimised transmissivity distribution is as shown in Figure 10.
You can import the estimated transmissivities by selecting Props|Leakance (we don’t need this array and
can use it to view the estimated T’s – If you wanted to actually incorporate these values into your model,
you would use the Hydraulic Conductivity property). At this point many of you will be confused as to why
we are importing transmissivity into the leakance property. Essentially we are just using the leakance
property to view the transmissivity values. Leakance is not used in this model so that importing T values
into Leakance does not change the MODFLOW run in any way. Thus it is just a convenient way of
inspecting the calibrated T values without accepting them at this point. To import these T values, select
Props|Import|Matrix. Click the browse button and find the file c:\gwv8\tutorial\work\ex1a1._kx. Next,
select Props|Property Values|Reset Matrix Bounds to reset the colors used to color flood the data.

Figure 10. Transmissivity distribution within study area determined through
calibration against heads. Contour interval is 10m2|day; darker shade
indicates greater transmissivity.
A comparison of Figure 10 with Figure 2 (which shows the “true” transmissivity distribution) reveals that
although the “calibrated” transmissivity field has certain things in common with the true field (for example,
the tendency of transmissivities to increase toward the eastern end of the river alluvium), there are
nevertheless significant differences between the two transmissivity fields. Remember, however, that both
transmissivity fields result in a perfect fit between model-generated heads at boreholes and their respective
field-measured counterparts.
The difference between the “true” and calibrated transmissivity fields is depicted in Figure 11. Differences
as high as ±40m2|day can be seen within the river alluvium. It is thus apparent that the transmissivity
distribution within the river alluvium cannot be uniquely determined through calibrating the model against
water levels measured in available bores. In fact, the transmissivity distribution shown in Figure 10 is just
one of an infinite number of transmissivity fields that would also have resulted in a perfect, or near-perfect,
fit between model outcomes and field measurements. The big question is, given the uncertainty in the
transmissivity field determined through the calibration process, what is the uncertainty in model predictions
of contaminant movement, and hence in its predictions regarding the efficacy of the remediation system?

Figure 11. Difference between calibrated and true transmissivities. Contour
interval is 10m2|day.
If MT3DMS is now run on the basis of the transmissivity field shown in Figure 10 in order to evaluate the
efficacy of the remediation system, it is found that the amount of contaminant entering the river over the
5000 day simulation time is 2167 units.
Regularisation with Pilot Points

It has now become abundantly obvious that it is beyond our capacity to uniquely determine the
transmissivity distribution of our model domain by calibrating the model on the basis of water level
measurements taken in a number of bores distributed through that domain. Unfortunately, when simulating
transport processes, it is often the “geological fine detail” that will determine the outcome of these
processes. However the introduction of fine detail means the introduction of many parameters into the
parameter estimation problem. This brings with it nonuniqueness, and, more often than not, numerical
instability. We were lucky to get away with what we did in our previous calibration exercise in which we
estimated 14 more parameters than there were observations (thus breaking one of the "golden rules" of
parameter estimation). However, as mentioned above, one of the great advantages of using pilot points is
that we can distribute a superfluity of those points throughout the model domain and then ask PEST to find
for itself those regions within the study area where transmissivity must be greater or less than average in
order to ensure that there is good agreement between model outputs and field measurements. If we had
based our parameterisation of the model domain solely on zones, we might not have placed those zones in
the correct position for the calibration process to properly infer the existence or extent of such
heterogeneity.
The introduction of regularisation into the calibration process serves two purposes. Firstly it brings a high
degree of numerical stability to a parameter estimation problem which would otherwise be highly
susceptible to the deleterious effects of a singular normal matrix (you might have noticed when inspecting
ex1a.rec that PEST was not able to calculate any parameter statistics due to singularity of the normal
matrix.) Secondly, if regularisation constraints are appropriately defined, model calibration can proceed
with a “homogeneous unless proven otherwise” philosophy; that is, in spite of the number of parameters at
its disposal, PEST will make each zone within the model domain as uniform as it can in terms of the
distribution of the estimated hydraulic property, introducing heterogeneity into a zone only where this is
necessary in order to allow a good of fit between model outputs and field data to be achieved. Hence any

heterogeneity which is introduced as an outcome of the calibration process is “there because it has to be
there”. In many modelling contexts this philosophy of model calibration has a large intuitive appeal,
allowing a modeller to use zones to characterise the distribution of some hydraulic property within a model
domain while, at the same time, removing the inflexibility that accompanies the characterisation of a model
domain by areas of piecewise parameter constancy.
In the present case we will use the same geostatistical information that was used by program PPK2FAC in
calculating kriging factors, to introduce regularisation constraints pertaining to the relationships between
different pairs of parameters into the inverse problem solved by PEST. If the “default condition” for each
of our hydrogeological zones is one of hydraulic property uniformity then, for any two pilot points lying
within the same zone, the preferred value for the difference between transmissivity values is zero.
Relationships between pairs of parameter values can be introduced into the calibration process as prior
information equations. The weight assigned to each of these prior information equations can be the same.
Alternatively, if the weight is proportional to the inverse of the square root of the variogram calculated for
the distance between the respective pilot points, then it can be shown that this is in harmony with the
geostatistical characterisation of the area as encapsulated in the variogram. What this characterisation says,
in short, is that “the closer are two points together, the more likely are the hydraulic properties at those
points to be the same”. By calculating weights on the basis of the inverse of the variogram, we are
enforcing the “zero difference” condition more strongly for points which are closer together than for those
which are farther apart.
The PPKREG Utility introduces regularisation prior information to a PEST control file. It does this on the
basis of information written to a “regularisation information file” by program PPF2FAC; PPK2FAC writes
this file (it was called reg1.dat in our case) when calculating kriging factors. It contains a matrix of
variogram values calculated between pairs of pilot points. PPKREG uses this information to calculate the
weights assigned to the regularisation prior information equations. However PPKREG does not formulate
prior information equations which link parameter values pertaining to pilot points assigned to different
zones; thus the role of zone boundaries in identifying preferred locations of hydraulic property
discontinuity remains intact. Also, PPKREG does not link pilot points which are “too far apart” in terms of
the search radius supplied to PPK2FAC when it calculated kriging factors.
Groundwater Vistas can now run PPKREG directly. To do this, select Model|Pest|Options - Basic
Options tab and put a check next to Regularize Parameters

Now, you can select from the regularization options by clicking on the Regularisation tab. Fill out the
dialog as below:

You should change PHIMACCEPT to be 1.1 (slightly higher than PHIMLIM) and WFMAX to 100,000.
Now create Pest datasets and run Pest as before.
When writing the new PEST control file, PPKREG sets the PESTMODE variable to “regularisation”, ie. it
informs PEST that it must run in “regularisation” mode. When run in this mode, a number of control
variables are required in the PEST control file, in addition to those required when PEST is run in
“parameter estimation” mode. One of these variables is PHIMLIM. This specifies the degree of model-to-
measurement misfit that is allowed to occur in the present optimisation process. Because the attainment of a
good model-to-measurement fit, and the simultaneous enforcement of homogeneity constraints, may place
conflicting requirements on parameter values, a compromise between the two must be reached. The user
determines the “compromise level” by setting a maximum model-to-measurement misfit that he|she will
tolerate, this misfit being expressed in terms of the “measurement objective function”. The maximum
permissible value of the measurement objective function (ie. PHIMLIM) should be set a little higher than
the objective function that it is possible to achieve without any regularisation constraints being enforced.
From our previous run we know that we can obtain an objective function of almost zero without
regularisation. In the present case we set PHIMLIM at 0.1, thus informing PEST that we will tolerate an
rms model-to-measurement misfit of 7 cm. (Divide 0.1 by the number of observations, then take the square
root to obtain this figure.)

Each prior information equation included in the parameter estimation process must be assigned a weight.
As was discussed above, weights are calculated on the basis of geostatistical information available (or
assumed) for the model area. If an observation or prior information equation is used for regularisation
purposes, then it is assigned to the observation group “regul”. As part of its regularisation functionality,
PEST adjusts the weights assigned to all members of this group during each iteration of the optimisation
process; however the relative weight values within this group remain the same. The “regularisation weight
factor” by which the initial weights of all members of the group “regul” are multiplied during each
optimisation iteration, is calculated in such a way as to respect the PHIMLIM value provided by the user as
the maximum tolerable model-to-measurement misfit for the current case. An initial regularisation weight
factor needs to be supplied by the user. In the present case this factor is supplied as 1.0. Similarly PEST
needs to be informed of the upper and lower limits that it is allowed to use for the regularisation weight
factor; default values offered by PPKREG are 106 and 10-6 times the initial regularisation weight factor.
Inspect file ex1ar.rec. The indicator of model-to-measurement misfit when PEST runs in “regularisation”
mode is the “measurement objective function”. You will notice that PEST does not lower the measurement
objective function to as low a value as it did during the previous PEST run when PEST was run in
“parameter estimation” mode (where it was referred to simply as the “objective function” or “phi”). In fact
it lowers it only to the value that you supplied for PHIMLIM. This gives PEST “room to move” in
satisfying the other objective of the optimisation process, viz. the imposition of a homogeneity condition
over the model domain.
Notice also that PEST runs for only 3 optimisation iterations before it stops because the objective function
reached the PHIMLIM value of 1.0 after that 3rd iteration. If you import results from this run and select
Plot|Calibration|Statistics/Plots, you will see that the sum of squared errors is just slightly lower than 1.0.
At this stage you would normally import the MODFLOW-compatible real array ex1a1._kx into
Groundwater Vistas for graphical display. If you did, you would find that the optimised parameter
transmissivity distribution was as depicted in Figure 12.
Figure 12. Transmissivity distribution within study area determined through

calibration against heads with regularisation applied. Contour interval is
10m2|day; darker shade indicates greater transmissivity.
A comparison between Figure 12 and Figure 2 indicates that the calibrated transmissivity distribution
depicted in Figure 12 does indeed replicate the general rise in transmissivity to the south-east that is present

in the “true” transmissivity distribution. However the transmissivity field of Figure 12 is a lot smoother
than that of Figure 2. (It is of interest to note that if PHIMLIM had been set to 0.3 - which still indicates a
very good fit between model outputs and field data, but gives PEST a little more “room to move” in terms
of its capacity to apply regularisation constraints - PEST would have calculated a uniform transmissivity
field in each of the model zones.)
When running MT3D on this version of the model, the cumulative mass budget shows 12,038 units of
contaminant find their way to the river over the model simulation time.
You can probably see where pilot points can save a lot of time in coming up with a calibrated K field.
Even if you do not agree with the philosophy behind the technique, you can use it to determine how K
should vary to produce a good calibration. You can then take the continuous K field computed by PEST
and use it to guide placement of zones in your model.

3D Pilot Point Example with SVD
One of the most powerful new features of Pest is called Singular Value Decomposition or SVD-Assist.
SVD-Assist significantly reduces the number of runs you need to make when using pilot points. SVD-
Assist also can better handle different parameter types that have very different sensitivities. A good
example is horizontal and vertical K values. Prior to SVD, Pest often had a difficult time calibrating both
Kx and Kz simultaneously. SVD seems to have solved that problem. The only down-side to SVD is that it
is a more complex procedure to follow.
You use SVD-Assist with Pest by starting with a normal pilot point setup as in the first example with the
one-layer model. Assign the calibration targets and pilot point locations. The SVD-Assist procedure then
uses the following steps:
Create Sensitivity Run. This is a normal Pest run but with only 1 iteration. Pest uses this run to
determine the sensitivities of each parameter (pilot point). To create this run, set the number of iterations to
1, initial lambda value to zero, and number of lambda values to 1.
Launch Sensitivity Run. After creating the Pest input files for the sensitivity run, launch Pest. It will run
one model run for each parameter.
Launch SVDAPREP. SVDAPREP is one of the many utility programs that comes with Pest. The most
important part of using SVDAPREP is to determine the number of “super” parameters for the next stage.
Super parameters are combinations of your complete set of parameters. Usually the number of super
parameters will be 10 to 20 percent of the total number. I have found that 15% generally works best. This
means that if you have 400 pilot points, the number of super parameters should be 60. The practical
implication of super parameters is that instead of making 400 runs per iteration, you only make 60 runs per
iteration.
Launch SVD Pest Run. SVDAPREP creates a new Pest file based on your original Pest input files and
the results of the sensitivity run. Run Pest using this new set of input files.
Create Final Pest Run. The results of the SVD Pest run are not useful in and of themselves. You need to
run a program called PARREP to make sense of the SVD results. PARREP creates a new Pest file, which
we will call the “final” Pest file. After running PARREP, change the number of iterations to zero and run
Pest using this file. Pest will run the model only 1 time using the final parameters values.
Now, considering that most of the tasks in 1 through 5 above need to be done at the command line, this
makes SVD a bit difficult to implement in practice (unless you are over 40 and still remember DOS).
Recognizing this problem, we have created a special menu in Vistas that duplicates the steps above. All
you have to do is execute the menu commands from top to bottom without skipping a step and it is
relatively easy to use SVD. This new menu is under Model|Pest|SVD Assist|… as shown below:

When using the SVD Assist menu in Groundwater Vistas, you do not need to make any changes to a
normal Pest run. Just set up Pest as described in the previous examples. Once the Pest run is configured,
simply start at the top of the SVD Assist menu and work your way down. Do not go to the next menu item
until all of the steps above it have been accomplished. We will now work through an example using a
simple 3D model to illustrate the SVD technique.
If your SVD Assist menu is grayed out and not accessible, it means you have the Standard version of
Groundwater Vistas. Only the Advanced version and above can access this menu.
Setting Up Pest
This example is a variation on the basic Groundwater Vistas tutorial model. We created a heterogeneous
hydraulic conductivity field, ran this hypothetical model, and extracted water level targets. You will start
with a homogeneous model, add calibration targets, add pilot points, and then use SVD to calibrate the
model. Start by opening the GV file called New_GV8_tutorial_pilotstart.gwv (NOTE: there are several
files with similar names – be sure to get the right one). After opening this model, your screen should look
like the one below:

The model is complete with the exception of calibration targets and pilot points. The calibration targets
will be imported from an external text file. Select AE|Import|Target Text File and browse to find the file
c:\gwv8\tutorial\Targets_newpilot.dat. The file looks like this. Skip 1 line, name is in column 1, etc.
Your dialog should look like the one on the next page.

GV should report 42 targets imported and your screen should look like the following:

Now we are going to add pilot points. The biggest problem with pilot points is that you need a lot of them.
That makes them tedious to add manually. We have created a simple way to add pilot points by placing
them evenly spaced on a rectangular array. Start this process by selecting AE|Pilot Points|Quick Pilots.
The following dialog is displayed:

Change the minimum pilot point value to 1 and the maximum to 10000.
Change the distance from 100 to 1000.
One key thing about pilot points is that the names all have to be unique. Using this quick pilot point
technique, GV will add the pilot points using a root name of “Kx” followed by a sequence number.
The starting sequence number is listed at the top of the dialog called “Starting Pilot Point Number for
Name”. It is best to start with 1 for the first set, as shown above. However, it is very important that in
subsequent layers (or any time you add more points), you not duplicate a previous number.
Each pilot point is given a default starting K value, in this case 100 ft|d. Before clicking the OK button,
carefully compare your dialog to the one above. There are several fields that are all multiples of 10 so
getting the number of zeroes correct is important. Click OK and your screen should look like the
following:

The red target symbols are the pilot points that you just added. Now repeat this for layers 2 and 3. Right
now you are in layer 1. Press Ctrl-D to go down one layer or increment the layer number on the left side of
your screen above the 3D cube. You know you are in the next layer because the red pilot points will
disappear. After entering pilot points for layer 2, move to layer 3 and repeat.
You will note that the quick pilot points dialog automatically resets the starting sequence number (“Starting
Pilot Point Number for Name”) at the top of the dialog to track how many you have added. Do not change
this value. That will assure that all pilot point names are unique.
After you have entered pilot points for layers 2 and 3, we will now add Kz pilot points using the same
technique.
Go back to layer 1 and select Add|Quick Pilot Points again.
Change the sequence number (“Starting Pilot Point Number for Name”) to 1.
Change the type of pilot point from Kx to Kz.
Change the pilot point prefix to Kz.
Change the default Kz value from 100 to 10.
Change the distance to 1000.
Change the minimum value to 0.1 and the maximum value to 1000. Kz values with thus range from 0.1 to
1,000 ft|d.

Repeat adding Kz pilot points to layers 2 and 3. You will note that after adding the Kz pilot points, your
pilot points may disappear entirely! This is because they are drawn over top of each other and essentially
“white out” each other. In order to avoid confusion, it is best to only display one type of pilot point at a
time. Select Plot|What to Display and turn off the display of one of the pilot point types.
This is a good time to save your work! You might want to use File|Save As to rename the Vistas file.
The next step is to set the Pest options for using pilot points. Select Model|Pest|Options. On the Basic
Options tab (the default one that is displayed), turn on regularization, use of pilot points, run the model
without screen output, use command-line versions, use regularization, and write BCF arrays to external
files. When using pilot points, get in the habit of always checking these options, as shown below:

Now, click on the Structures tab. GV now does a pretty good job of setting reasonable default settings for
these structures, which control the kriging of the pilot points. The only thing that we will change here is
the maximum number of points to use in the kriging. Change that from 50 to 12. With gridded pilot
points, 12 should be plenty for a smooth interpolation.

Now save your work again. The model is setup for pilot points. No other changes need to be made.
Using SVD Assist

To start the calibration, create the MODFLOW datasets using Model|MODFLOW|Create Datasets.
If this were a normal Pest run, you would select Model|Pest|Create Datasets. However, when using SVD
with Pest, you use the Model|Pest|SVD Assist|Create Sensitivity Run instead. Use that command now.
You should see lots of DOS windows flashing on your screen as GV runs PPK2FAC and FAC2REAL for
each layer and for each pilot point type. GV will then run PPKREG for each layer and pilot point type.
Thus a total of 18 DOS windows will flash – much too fast to count. GV also automatically changed the
number of iterations to -1, set the initial lambda to 0.0, and set the number of lambda values to 1. You
should see a message that the Pest file was successfully created. GV will automatically run Pestchek.

You should see some warnings but they are not serious. You can ignore them.
Now, run this initial sensitivity run. If you followed the steps for adding the pilot points, GV should run
the model 402 times during the sensitivity run. This will take a couple of minutes. Select Model|Pest|SVD
Assist|Launch Sensitivity Run and take a break.
You will note when Pest runs that the starting phi (sum of squared residuals) is 3,829. ft2.
After the run finishes, we need to run SVDAPREP to reconfigure the Pest control file to use a set of super
parameters. A super parameter is a linear combination of the base parameters (pilot points in our case).
The question that is always asked is how many super parameters should you use? A new utility called
SUPCALC estimates the minimum and maximum number of super parameters for a calibration. To run
SUPCALC, first select Model|Pest|Options and select the Regularization tab. The value of PHIMLIM is
the objective function (sum of squared residuals) you think is reasonable to attain. Since this is a synthetic

case, leave the value at its default value of 1.0. In a real-world calibration, you would have to make a more
realistic guess as to what phi is attainable. Now run SUPCALC using Model|Pest|SVD Assist|Launch
SUPCALC. You should see the following in notepad:
The important thing to note is the minimum and maximum number of super parameters which in this case
should be around 15 to 42. We will use 40 but you might also try a lower value to see if it makes a
difference.
To continue the calibration, select Model|Pest|SVD Assist|Launch SVDAPREP. A dialog is displayed
with 3 options. Change the number of super parameters to 40 (between the range shown above from
SUPCALC) and make sure the super parameter calculation option is set to 1. Click OK and GV will run
the SVDAPREP utility to create a new Pest file (called t2p_svd.pst).
Next, select Model|Pest|SVD Assist|Launch SVD Run. You should now see that Pest is running the
model 40 times per iteration (80 times after the first iteration when it switches to central differencing). Let
it go 10 iterations. If you get tired of waiting, use Model|Pest|Stop Pest Run to kill the run. Pest always
ends gracefully though so you can still use the results even if you end the run prematurely.
In order to have the right results for the next session on Null Space Monte Carlo, allow the run the go for
10 iterations. After it starts on the 10th iteration, select Model|Pest|Stop Pest Run. The last step is to use
Model|Pest|SVD Assist|Create Final Run. This tells GV to run PARREP to assemble the final set of
parameters, modify the Pest file to make only one model run, and run Pest with that final dataset.
To view the results of that final calibration run, use Plot|Import Results and click OK. Your screen
should look like the following (the following is based on 10 iterations – you will also have to change the
contouring parameters a bit):

If you check the calibration statistics, you should see that Pest reduced the sum of squared residuals from
the initial value of 3,830 down to about 31 (as long as you let it go at least 10 iterations). The plot of
observed vs simulated head values is also quite good:

Please save your Groundwater Vistas file now! Use File|Save As and name the file
New_GV8_tutorial_pilotsetup.gwv.
We are going to bring in the new parameter values from the Pest run. It is very important that you use
File|Save As now to create a new Vistas file (name it New_GV8_tutorial_pilot_answer.gwv) where these
results will be stored. The reason we do this is that once you reset the hydraulic conductivities, you can no
longer make a Pest pilot point calibration run with this version of the model. This model will be your final
answer. However, if you want to go back, make changes to the calibration run, and recalibrate with Pest,
then you need to use the one you saved previously.
To see the final hydraulic conductivity distribution for this run, select Model|Pest|Update Parameters.
Answer Yes to reset the parameters and Yes to reset hydraulic conductivity values. The K values should
look like the following:
Save this as your final calibrated model using a new file name.
Now, open your previous Groundwater Vistas file (New_GV8_tutorial_pilotsetup.gwv) that contained the
setup for this calibration. Select Model|Pest|Update Parameters. Answer Yes to reset the parameters and
NO to reset hydraulic conductivity values. This will update our pilot points to the final calibrated values
but not import the final Kx and Kz matrices. This will serve as the starting point for the next session where
we explore the new Null Space Monte Carlo procedure.
Select File|Save As and name the file New_GV5_tutorial_NullSpace.gwv which we will use in the next
session.

Using Beopest with SVD Assist
We will now repeat the previous SVD Assist example with Beopest to show how to use distributed
computing to speed up the process. Beopest is a special version of Pest designed to run multiple
simultaneous simulations. In the previous example, Pest first had to make 402 simulations to compute the
Jacobian matrix (the Sensitivity run). Even on this small model, that takes time. We will show you how to
do the same calibration, but in about a quarter the time by using four simultaneous runs.
Start by opening the model you used in the last example, but prior to updating the model with the results of
the Pest calibration. If you did not save it, you can use the one called
New_gv8_tutorial_pilotstart_setup.gwv provided for you in the GWV8\Tutorial folder.
This model should be ready to run Pest to compute the sensitivity run. All of the preparation for using
Beopest is exactly the same as for a normal Pest run. You can use it for non-SVD Assist calibrations as
well. We are showing the SVD Assist example because it is more complicated than a normal calibration
run.
Start by creating 4 new folders where the “agent” simulations will be run. An agent is the version of pest
that will actually make the individual model runs. The “manager” is the version of pest that does the actual
calibraiton and directs the agents to make model runs. Note that in previous versions of Groundwater
Vistas and Pest, these terms were Master and Slave. However, those terms are not politically correct so
they have been changed.
Create the 4 new folders under the c:\gwv8\models directory. Call them run1, run2, run3, and run4. In File
Explorer your models folder should look like the following:

Now, change the working directory to be c:\gwv8\models by selecting Models|Paths to Models:
Create a new set of MODFLOW files and run MODFLOW to make sure that all of the input files exist for
this simulation.

To set up a Beopest or Pest_HP calibration, you start by selecting Model|Pest|BeoPest/Pest_HP/Options.
One of the important fields on this dialog is the IP address of the Manager computer. This can be found by
opening a console window and typing the command IPCONFIG. Look for the IP v4 address, which should
be 4 numbers separated by a dot. In the example below, this computer has an IP address of 10.0.0.191.

Enter this IPv4 address in the Beopest options dialog, as shown below. Also turn on the option to use the 64
bit version of BeoPest.

The next step is to define the directories we will use for the agent simulations (run1, run2, etc). Select
Model|Pest|Beopest/Pest_HP|Directories. Type in the path or use the browse button to find the four that
you created. Also tic the box under “Use” to tell GV8 to use that directory in the next Beopest run.
Note that the directory names above should be on the same computer as the main beopest manager run.
You are not limited to this, though. You can also have use other computers as long as they have internet
access so they can access the IP address of the manager computer. In this case, though, you will have to
copy the contents of the manager working directory to those other computers manually.
The Beopest set up is now complete. Select Model|Pest|SVD Assist|Create Sensitivity Run. This sets up
the sensivity Pest run in the main working directory (c:\gwv8\models) where the manager for Beopest will
operate. Now copy the contents of this directory to each of the agent directories. GV will do this for you
by selecting Model|Pest|Beopest/Pest_HP/Setup Beopest/Pest_HP. Console windows will flash on your
screen as GV8 uses DOS commands to copy the directory contents. It will then display some information
in Notepad to show you what was done:

The next step in SVD-Assist would be to launch the sensitivity run. When using Beopest, though, you do
this manually from console windows. Start by opening a console window in the main working directory
(c:\gwv8\models). An easy way to do this is to view that directory in File Manager. Highlight the path
name at the top of the window and type cmd and hit the enter key. This will open a console in that
directory like the following:
Type RunManager and hit the enter key. This runs a batch file that GV8 created for you.

The manager run will sit there until you start at least one of the agents (slaves in old terminology). Now
open a console in each of the agent directories and type RunAgent and hit the enter key. You will do this
four times. You should now have 5 windows on your screen.
You should see the same sort of Pest result in the manager window and each agent should be making lots of
model runs. When the manager run is finished with the 402 sensitivity simulations, return to the SVD
Assist menu and select Model|Pest|SVD Assist|Launch SVDAPREP.

The next step would normally be to use the Launch SVD Run. However, since we are using Beopest, you
must first copy the contents of the main directory to each of the agent directories again. This time the copy
will include the SVD information. Select Model|Pest|Beopest/Pest_HP/Setup Beopest/Pest_HP. Console
windows will flash on your screen again as GV8 uses DOS commands to recopy the directory contents. It
will then display some information in Notepad like before.
In the manager window, type RunManagerSVD, which is a batch file for the SVD run. In each of the agent
windows, type RunAgentSVD and hit the enter key.
After about 10 iterations have been completed, use Model|Pest|Stop Pest Run. Now you have to use the
Model|Pest|SVD Assist|Create Final Run, to complete the calibration.

You can tell from this simple example that is not too difficult to use Beopest and it can greatly decrease the
time to use Pest when there are lots of parameters. Here are some additional things to consider when using
Beopest:
• You can use either PEST_HP or PEST++ using this same procedure
• If you have a multi-core CPU on your computer, you can generally use as many console windows
as you have cores. In some cases, you can use even more than the number of cores. However you
may need to experiment as the more simultaneous runs you have, the more interference you will
have been runs. Thus, individual run times will be longer as you add more consoles.
• You should cut down on unnecessary output from MODFLOW as writing to disk will slow each
of the simulations.

PEST and Null Space Monte Carlo
Introduction
Another powerful new feature in Pest is called Null Space Monte Carlo. In this procedure, you can create
any number of calibrated versions (called realizations) of your model. You saw in the last session that
Singular Value Decomposition or SVD can dramatically reduce the time needed to calibrate very complex
models. The Null Space Monte Carlo technique is designed to work on a model calibrated using SVD
Assist with many parameters, as in a pilot point calibration. While pilot points are not required for Null
Space Monte Carlo, a large number of parameters is a requirement.
Null Space Monte Carlo would be used after finalizing a calibration using SVD Assist. The procedure then
uses the following steps:
Set Options. There are some options to set prior to running the Null Space Monte Carlo simulation. You
need to reset the number of super parameters to be the same as you used in the previous SVD Assist run,
for example.
Get Covariance Matrices. This step is only needed when you are using the random method for generating
new pilot point values or if you have non-pilot point parameters in the calibration. If neither of these two
situations are true, then GV will gray out this menu selection.
Update Jacobian Matrix. Remember that the Jacobian matrix is the matrix of sensitivities where the
change in residual at each observation is divided by the change in the parameter value. When you run SVD
Assist, the Jacobian Matrix is based on the initial parameter values. Pest needs to update this matrix using
the final parameter values after the calibration is finished. Thus, this step will require one model run per
parameter.
Generate Realizations. A realization is a set of parameters based on the original calibration but modified
using either a random number generator or a geostatistical field generator. It is not clear which is better as
this technique is so new.
Calibrate Realizations. The realizations generated in step 4 will generally result in a degradation in model
calibration. Pest is now run through a large batch file to tweak each realization back into calibration. Only
a couple of iterations are allowed to keep run time to a reasonable level so that some realizations might not
be accepted in the end.
Now, considering that most of the tasks in 1 through 5 above need to be done at the command line, this
makes Null Space Monte Carlo even more difficult to implement than SVD Assist. As with SVD Assist,
however, Groundwater Vistas has been configured to make this as simple as possible. This new menu is
under Model|Pest|Null Space Monte Carlo|… as shown below:

When using the Null Space Monte Carlo, you first calibrate your model using SVD Assist as in the last
chapter. Then you update parameters so that the pilot points and|or other parameters are set to the
calibrated values. Next, use the Null Space Monte Carlo menu and start at the top, executing each menu
item in turn as you work your way down. We will now work through an example using the model
calibration from the last chapter.
Reset Pilot Point Bounds

Start by opening the model you created from the last session (New_GV8_tutorial_NullSpace.gwv). If you
did not finish or your results were not good, there should be a file of the same name already in the
c:\gwv8\tutorial directory that has already been prepared.
One important thing to keep in mind is that the bounds on the pilot point values are used to sample new
pilot point values for each realization. That means that the wider the bounds, the more the initial
realization will be out of calibration potentially and thus the more model runs to tweak the calibration back
into an acceptable level. So, to start, we will make the bounds on our final pilot points +|- a factor of 5.
Select AE|Modify|Pilot Points|Bounds and enter 5 for maximum and 0.2 for minimum and then check the
box at the bottom to indicate these are multipliers on current pilot point values

Repeat this for Kz pilot points.
Null Space Monte Carlo Options

Run the model to make sure that all files have been created for the MODFLOW simulation. Then select
Model|Pest|Null Space Monte Carlo|Options.
Set the number of realizations to 10 (just to keep the run time down).
Change the number of super parameters at the top to 40.
Set the option for generating parameter sets to “Stochastic Fields Using Fieldgen”
Change the Objective Function Threshold to 50.
Change the Abandonment Threshold to 1000.

The Objective Function Threshold is the value of the sum of squared residuals that signifies an acceptable
calibration. If the objective function falls to this level during the recalibration of a realization, Pest will
stop and move on. On the other hand, if the objective function is above the abandonment threshold at any
time, Pest will quit and move to the next realization. These values are designed to make the procedure
more efficient by avoiding too much calibration or runs that are so poorly calibrated that time is not wasted
on them.
Update Jacobian Matrix

The next step is to recomputed the Jacobian Matrix using calibrated parameter values. This will require
one model simulation for each parameter. In this case, that would be 402 model runs.
Select Model|Pest|Null Space Monte Carlo|Update Jacobian Matrix
Groundwater Vistas will create a new Pest control file (t2.pst). Note that regularization is turned off for
this Pest run. After the new Pest control file is created, GV will display the following message:

Click OK to continue. Groundwater Vistas will now run Pestchek on the new Pest control file and display
the errors and warnings:
GV now asks if you want to continue. If there were errors, you should say NO. If there are only warnings,
as shown above, then say YES.
Pest will run. Note that the initial objective function (phi) should be the same as for your final calibration.
If you ran 10 iterations of SVD, then it should be near 31:

Generate Realizations
After the new Jacobian Matrix is created, it is time to create the parameter values for each realization.
During this step, the program Fieldgen is run to create noisy Kx and Kz fields based on the variogram
(structure) we used in the original calibration. Next, a program called PPSAMP samples pilot point values
from these noisy fields and PNULPAR creates a final set of parameter files that Pest will use as starting
guesses for parameters during recalibration of each realization.
Select Model|Pest|Null Space Monte Carlo|Generate Realizations.
You should see lots of DOS windows flashing as these utility programs generate the various files needed
for the rest of the analysis.
Run SVDAPREP
Now, SVDAPREP must be run again to generate a revised SVD Pest control file that will be used to
recalibrate each realization. GV will regenerate a main Pest control file, run SVDAPREP, and finally
revise the SVDAPREP-generated Pest control file to reset some variables.
Select Model|Pest|Null Space Monte Carlo|Run SVDAPREP
Groundwater Vistas will first ask if you want to turn off regularization. It is probably best to answer YES.
Without regularization, you get the first optimization iteration of each realization free (that is, no model
runs). That can be quite a time savings. Probably the best approach is to try it the first time without
regularization and then if it does not yield good results, run another set of runs with regularization.
Answer YES to this prompt:

Groundwater Vistas now alerts you to the fact that it is going to regenerate a new Pest control file. This
will contain no regularization and will be used by SVDAPREP in a subsequent step.
Click OK to continue.
The new Pest control file was created.

Click OK to run Pestcheck:
Hopefully Pestchek found no errors and only a few warnings as shown below. Close notepad after viewing
the file.

Groundwater Vistas is now ready to run SVDAPREP.
Click OK to continue:
The SVDAPREP options should be filled out for you already. You should just confirm that the number of
super parameters is correct (40 in our example). Note that the flag labeled “Automatically Calculate
Derivatives” in ON. This tells Pest to run no model simulations in the first iteration.
Click OK to continue:
We should now have all of the many files we need to run Null Space Monte Carlo. If you go into Windows
Explorer and browse to the c:\gwv8\tutorial\work directory and sort by date, you should see the most
recently modified file is t2_svd.pst which is the final product of this whole sequence of commands.

Calibrate Each Realization
You are ready to calibrate each realization. To do this, select Model|Pest|Null Space Monte
Carlo|Calibrate Realizations.
You will see a DOS window open like in a normal Pest run. Instead of running just one Pest simulation,
however, it will be running 10 of them. The first iteration will be done without any model runs (except for
Lambda testing). If it can reach a sum of squares of 50, it will then move to the next one. If not, it will try
one more iteration before giving up. The file c:\gwv8\tutorial\work\Record.dat contains a summary of the
results of each realization. You can open this file periodically to see how far it has progressed.
After each realization has been calibrated, GV will display the Record.dat file as shown below. You will
see below that all realizations achieved the desired sum of squared residuals of 50. Note, however, that
your results may vary depending on where you stopped the previous SVD Assist calibration. Do not be
concerned if your results do not match this exactly.

Gv8 Tutorial Manual-4

Uploaded by

Copyright:

Available Formats

Gv8 Tutorial Manual-4

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Gv8 Tutorial Manual-4

Uploaded by

Copyright:

Available Formats

What is the overall goal of the presented exercise?

What is the overall goal of the presented exercise?

How is the spatial distribution of transmissivity estimated in the model domain?

How is the spatial distribution of transmissivity estimated in the model domain?

PEST and Pilot Points

Adapted for Groundwater Vistas by

Description of Study Area

Groundwater Vistas Version 8 Page 176

Groundwater Vistas Version 8 Page 177

Groundwater Vistas Version 8 Page 178

Groundwater Vistas Version 8 Page 179

Figure 5. Piezometric and contaminant concentration contours 3500 days after

Groundwater Vistas Version 8 Page 180

Figure 6. Location of extraction bore.

Groundwater Vistas Version 8 Page 181

Groundwater Vistas Version 8 Page 182

Calibrating the Model using Water Level Data Only

Groundwater Vistas Version 8 Page 183

Figure 7. Zonation of the model domain.

Groundwater Vistas Version 8 Page 184

Groundwater Vistas Version 8 Page 185

Groundwater Vistas Version 8 Page 186

Groundwater Vistas Version 8 Page 187

Groundwater Vistas Version 8 Page 188

Groundwater Vistas Version 8 Page 189

Groundwater Vistas Version 8 Page 190

Groundwater Vistas Version 8 Page 191

Groundwater Vistas Version 8 Page 192

Fig. 9 “Kriging uncertainty” calculated by PPK2FAC on the basis of the

Groundwater Vistas Version 8 Page 193

Preparing for a PEST Run

Groundwater Vistas Version 8 Page 194

Groundwater Vistas Version 8 Page 195

Groundwater Vistas Version 8 Page 196

Groundwater Vistas Version 8 Page 197

Regularisation with Pilot Points

Groundwater Vistas Version 8 Page 198

Groundwater Vistas Version 8 Page 199

Groundwater Vistas Version 8 Page 200

Now create Pest datasets and run Pest as before.

Groundwater Vistas Version 8 Page 201

Figure 12. Transmissivity distribution within study area determined through

Groundwater Vistas Version 8 Page 202

Groundwater Vistas Version 8 Page 203

Groundwater Vistas Version 8 Page 204

Groundwater Vistas Version 8 Page 205

Groundwater Vistas Version 8 Page 206

Groundwater Vistas Version 8 Page 207

Groundwater Vistas Version 8 Page 208

Groundwater Vistas Version 8 Page 209

Groundwater Vistas Version 8 Page 210

Groundwater Vistas Version 8 Page 211

Groundwater Vistas Version 8 Page 212

Using SVD Assist

Groundwater Vistas Version 8 Page 213

Groundwater Vistas Version 8 Page 214

Groundwater Vistas Version 8 Page 215

Groundwater Vistas Version 8 Page 216

Groundwater Vistas Version 8 Page 217