Post-Processing of Monte Carlo Results

So now you have 10 different model calibrations for this example. What do we do with this stuff? That is
a good question. The final parameters for each realization can be found in the files called t2.bpa.# where #
is the realization number. The Pest summary output file for each realization can be found in the files called
t2_svd.rec.# where # is the realization number.
Post-processing of the realizations will be an ongoing development exercise in Groundwater Vistas. For
now, there are a couple of things you can do. First, select Model|Pest|Null Space Monte
Carlo|Summarize Parameters. Groundwater Vistas reads the file record.dat shown above along with the
parameter files and summarizes the results for you. Two text files will be displayed. The first is called
NullSpaceSummary.txt as shown below.

This file just summarizes the number of realizations, the number that met the phi threshold, and then the
phi (sum of squared residuals) for each realization.
The second file is called NullSpaceParameters.txt and shows the mean, log mean, standard deviation,
minimum value, and maximum value for each parameter. You can see from the example below that the
range in parameter values can be quite extreme and yet each realization is well calibrated.
.

Groundwater Vistas Version 8 Page 236

You can begin to see the degree of non-uniqueness in our models!
The next post-processing step is to assemble a file of parameters and heads from each realization so that we
can start to analyze the results. Select Model|Pest|Null Space Monte Carlo|Combine Results. This
creates another batch file with a loop that will run the model once per realization. The batch file finds the
parameters from that realization, sets up a Pest run with zero iterations (so it runs the model once), and then
takes the Kx arrays, Kz arrays, and heads and assembles three large binary files containing all of this
information.
You can see the contents of the heads file using Plot|File Operations|View Contents. Browse to find the
file called t2_nsmc.hds. Then click the View button.

Groundwater Vistas Version 8 Page 237

What you see is one set of heads and the name in the matrix is coded with the realization number “REAL
1”. Similarly the Kx values are in a file called t2_kx.gst. If you view the contents of this file, you will see
the following:

Note that this file also has the realization coded in the description of the matrix but also the time step
number is the realization number. This allows you to import the results of a *.gst file to contour like it was
a head file. We don’t do this for the head file shown above because this information is processed in a
different way.
We can now use some of the stochastic post-processing built into Groundwater Vistas to look at the 10
realizations we just combined into the one head file called t2_nsmc.hds.
Before we begin processing the stochastic output, we need to import results into Vistas. This sets up
memory for the following procedures. Select Plot|Import Results and click ok.
First, select Plot|Stochastic|Import Target Data. Browse to find the file t2_nsmc.hds and click OK. It
should report 10 realizations were imported.

Groundwater Vistas Version 8 Page 238

We can now create graphs for this information. One is a scatter plot of sum of squared residuals for each
realization. Choose Plot|Stochastic|Graph|Calibration Statistics. The following dialog is displayed.

Click on the Scatter Plot for All Realizations button and the following graph should appear. This is just a
visual summary of the text file you created earlier.

To see how heads vary at calibration targets, use Plot|Stochastic|Graph|Target CDF and just choose the
first target on the list.

Groundwater Vistas Version 8 Page 239

This graph shows that the range in head at this target is about a foot over all realizations.
You can view the hydraulic conductivity values for each iteration using Plot|Import Results. Change the
normal head save file name from t2.hds to t2_kx.gst and click browse at the top to see the realizations that
have been saved as different time step numbers:

Groundwater Vistas Version 8 Page 240

Choose realization 5 (time step 5). The screen looks very odd because GV thinks these values are head.
The purple areas are “dry”.

It is usually best to color flood these values instead of contours. Choose Plot|What to Dislay. Turn off
display of dry cells and turn off contours. Turn on the color flood of “head”.
To change the scale on the color flood, use Plot|Color Flood|Color Flood options. Change to log color
flood and also change the minimum and maximum values, as shown below:

Groundwater Vistas Version 8 Page 241

Now you can better see the variability in Kx for this realization.

Now you can quickly scan through each realization using the Plot|Next Time Step and Plot|Previous Time
step to see how variable the Kx values are. This illustrates the extreme nature of model nonuniqueness in
groundwater models. This is a synthetic model and should match exactly to the original distribution.
Perhaps if we had sampled a head target in all model grid cells the variability would be much less.
However, the sparcity of head data in real models makes this example more realistic.

Groundwater Vistas Version 8 Page 242

PEST++ Iterative Ensemble Smoother (IES)

Introduction
This tutorial illustrates use of the PESTPP-IES iterative ensemble smoother to generate a suite of parameter
fields which calibrate a model. It is designed to complement Groundwater Vistas (GV) tutorials entitled
“3D Pilot Point Example with SVD” and “PEST and Null Space Monte Carlo” presented in the last two
chapters. This tutorial was developed by John Doherty (author of PEST) and has been adapted to show the
new Pestpp-IES options in Groundwater Vistas version 8.
Use of PESTPP-IES for generation of a suite of calibration-constrained random parameter fields has some
advantages and some disadvantages compared with calibration followed by use of the null space Monte
Carlo methodology. Advantages are:
• History-matching and uncertainty analysis are implemented through the same parameter
adjustment process using an algorithm that combines gradient-based inversion with the use of random
parameter fields.
• The number of model runs required to generate a suite of calibration-constrained random
parameter fields may be smaller than that required by PEST to obtain a single calibrated parameter field.
Use of an iterative ensemble smoother can be extremely computationally efficient, especially where the
dimensionality of the calibration null space is high.
• The number of model runs required to achieve a good fit between model outputs and a calibration
dataset does not rise with the number of adjustable parameters. Hence spatial parameterization can take
place on a cell-by-cell basis, this resulting in millions of adjustable parameters. These parameters can
describe any aspect of a system that is unknown, including historical pumping rates at individual wells for
which assumptions of incorrect values can promulgate erroneous, compensatory estimates of calibrated
parameter values.
• Since PESTPP-IES does not rely on strict local gradient information, it has a high tolerance for
nonlinearities in relationships between model parameters and model outputs. These can arise from the
intrinsic nature of these relationships, or they can be a numerical artefact arising from model solution
convergence difficulties.
Disadvantages include the following:
• Use of random parameter fields can sometimes raise the ire of a numerically unstable model which
is pre-disposed to numerical grumpiness.
• Fits between model outputs and a calibration dataset may not be as good as those achieved using a
traditional Jacobian matrix as a basis for parameter adjustment when using the same number of parameters.
However this is of little consequence if measurements comprising a calibration dataset are noisy, or if
model structural defects make a significant contribution to model-to-measurement misfit.
• Sometimes pursuit of a “minimum error variance” parameter field that constitutes the “calibrated
model” allows a modeller to gain important insights into the integrity of a calibration dataset, and/or of the
model itself. These insights may not be as obvious when the outcome of the history matching process is an
ensemble of random parameter fields.
• Because the PESTPP-IES history-matching process does not yield a sensitivity matrix, linear
parameter and predictive uncertainty analysis, and ancillary data worth analysis, cannot be undertaken as an
adjunct to parameter estimation. (Note, however, that the whole purpose of PESTPP-IES is to produce an
ensemble of “calibrated” parameter sets, this being a measure of parameter uncertainty which is not subject
to a linearity assumption.)
• Optimal performance of ensemble methods sometimes requires the use of so-called “localization”
methods. PESTPP-IES implements several forms localization. These require that a user indicate in advance
of the history-matching process observations which are unlikely to be sensitive to certain parameters.

Groundwater Vistas Version 8 Page 243

Alternatively, the ensemble smoother algorithm may be able to acquire knowledge of insensitivities
through the history-matching process itself. In the latter case, acquisition of this knowledge can be difficult
if the ensemble size is small.

Ensemble Smoothers
At the commencement of its execution, PESTPP-IES reads or generates an ensemble of random parameter
fields; each of these fields is a sample (i.e. a realization) of the prior parameter probability distribution.
Then, through a succession of iterations, it modifies these realizations until they become samples of the
posterior parameter probability distribution (i.e. the post-calibration parameter probability distribution). A
posterior parameter probability distribution expresses residual parameter uncertainty arising from:
- limited information contained within the calibration dataset, and
- measurement noise associated with this dataset (some of which is, of course, so-called “structural
noise” arising from inadequacies of the model as a simulator of real-world behaviour).
PESTPP-IES can generate the initial parameter ensemble itself based on a multi-Gaussian distribution
centred on parameter values provided in a PEST control file. If this option is taken, then it is incumbent on
the user to ensure that initial parameter values comprise “expected parameter values” (in the statistical
sense) from the standpoint of the prior parameter probability distribution. That is, they should be “best”
parameter values based on all information that exists prior to the history-matching process. If parameters
are correlated, users should also supply a parameter covariance matrix (through an uncertainty file or a
matrix file) for PESTPP-IES to use for generation of the initial parameter ensemble. As has already been
discussed, the covariance matrix for subsets of spatially varying parameters can be calculated from a
variogram.
In addition to an initial parameter ensemble, PESTPP-IES also requires an observation ensemble. The
observation ensemble is centred on observation values supplied in a PEST control file. Each observation
realization in the observation ensemble is the original observation vector from the PEST control file plus a
realization of measurement noise. Generally, the measurement noise associated with each observation is
assumed to be statistically independent of that associated with all other observations. If PESTPP-IES
generates the observation ensemble itself (which is its default behaviour), it assumes that the standard
deviation of measurement noise associated with each observation is equal to the inverse of the weight
associated with that observation. It is thus incumbent on a PESTPP-IES user to ensure that weights
supplied in a PEST control file are “correct” if he/she asks PESTPP-IES to generate the observation
ensemble itself. (Note, however, that exactness is not essential here.)
Let Φi denote the initial objective function (i.e. the objective function based on initial parameter values
supplied in a PEST control file). Suppose that you think that an objective function of Φf is achievable
through the history-matching process. Then a “correct” set of weights can be calculated by multiplying all
existing weights by the factor f, calculated as:
f= √(Φ_f/Φ_i) (3.1)
(The WTFACTOR utility supplied with the PEST suite can help here.) After multiplication of weights by
this factor, the achievable objective function should be roughly equal to the number of non-zero-weighted
observations featured in the PEST control file.
Unfortunately, more issues than measurement noise must be taken into account when assigning weights to
observations. It is often advantageous to design a weighting scheme that approximately equalizes the initial
contribution to the objective function made by each observation group. By rendering each observation
group as visible in the initial objective function as any other observation group, assurance is gained that the
information which it contains is not lost to the history-matching process. However weights calculated in
this way may not be in accordance with those calculated on the basis of measurement noise. Hence there
may be occasions where it is better to use an objective-function-balancing set of weights in a PEST control
file, while using a different set of weights to calculate the observation noise ensemble used by PESTPP-
IES. This will be demonstrated herein.

Groundwater Vistas Version 8 Page 244

Number of Parameters
In the present workshop we use PESTPP-IES to adjust a few hundred pilot point parameters. However
PESTPP-IES is able to adjust many more parameters than this –millions of parameters in fact. What is even
more impressive is that the number of model runs per iteration required by the parameter adjustment
process does not increase with the number of adjusted parameters. However, in order to achieve a good fit
between model outputs and the calibration dataset, the number of parameter realizations (and hence the
number of model runs) must be greater than the dimensionality of the solution space of the inverse
problem. (Alternatively, users must rely on a strategy called “localization” in which observations and
parameters are related through parameter-centred “localization windows”; in this case the number of
realizations must be greater than the size of the “localization window”.) How large is the dimensionality of
the solution space? Often this must be guessed. Nevertheless, an ensemble size of a few hundred (and often
less) is suitable for most occasions. (We successfully employ an ensemble size of only 80 in the present
example.)
Because adjustment of a large number of parameters does not incur a greater run-time burden than
adjustment of a moderate number of parameters, spatial parameterization of a model domain does not need
to be based on pilot points. Instead, parameters can have a much greater spatial density than this - as dense
as one parameter per model cell. At the same time, other parameter types can express uncertainties in other
aspects of a model, for example the temporal and spatial variability of historical pumping rates. This
obviates the need to assign “fixed” values for these rates that are probably incorrect. This, in turn,
eliminates the proclivity for estimated parameters to compensate for this incorrectness. The preferred
outcome of a history-matching process is therefore achieved. That is, parameters, and the predictions that
depend on them, remain unbiased but are endowed with higher (and quantifiable) uncertainty that reflects
the true state of knowledge of a system.

Control Variables
PESTPP-IES is a member of the PEST++ suite of programs. These programs are completely
interchangeable with those of the PEST suite. Programs of the PEST++ suite read a PEST control file just
like PEST does. Furthermore, they communicate with a numerical model using template and instruction
files, just like PEST does. Some of the control variables used by members of the PEST++ suite are the
same as those used by PEST. These are read from a PEST control file. However optional control variables
which are specific to PEST++ programs must be inserted into a PEST control file in such a way that they
are recognizable by members of the PEST++ suite. It is not essential that all control variables that pertain to
a specific PEST++ program be represented in a PEST control file that is used by that program; PEST++
programs provide default values for all missing variables. On the other hand, if a PEST control file which
contains PEST++ control variables is provided to PEST, PEST simply ignores these variables.
A PEST++ control variable can be placed anywhere within a PEST control file. It is recognized as such
because the line on which it is placed must begin with the characters “++”. This must be followed by the
name of the variable, and then by one or more values surrounded by brackets; multiple values supplied for
the same variable must be comma-delimited.

PEST Checking Utilities

As is discussed in PEST documentation, PESTCHEK should always be used to check the integrity of a
PEST input dataset before running PEST, BEOPEST or PEST_HP. PESTCHEK checks all parts of a PEST
control file, as well as all template and instruction files cited therein. In checking a PEST control file,
PESTCHEK ensures that all PEST control variables are correct in themselves, and are consistent with each
other.
If PESTCHEK finds a line beginning with “++”in a PEST control file, it ignores this line. Hence it does not
check the integrity and consistency of PEST++ control variables. Nevertheless it will tolerate their
presence. Meanwhile it checks all other variables found within a PEST control file, as well as their
consistency with template and instruction files cited in this same file.
3.4 PESTPP-IES Input and Output Files

Groundwater Vistas Version 8 Page 245

PESTPP-IES makes extensive use of comma-delimited files (i.e. CSV files) for reading its input data and
recording its output data. In particular, prior parameter realizations can be provided to PESTPP-IES in a
CSV file; it can record its posterior parameter ensemble in a CSV file. The same applies to its input
observation ensemble and to the ensemble of model outputs that are calculated by the model using the
posterior parameter ensemble.
A CSV file can be imported into a spreadsheet such as Microsoft EXCEL. The data contained therein can
then be processed in many ways. Unfortunately, however, this may be a difficult undertaking where
parameter numbers are very large (in the tens of thousands, or greater) for EXCEL places limits on the
widths of CSV files that it reads. To facilitate pre/postprocessing of its input/output datasets, PESTPP-IES
supports two options for the structure of the CSV files which it reads/writes. In the first of these options,
one row of a CSV file is dedicated to each parameter or observation realization (i.e. this row contains
values for all parameters or observations that comprise the realization). In the second option, one column of
the CSV file is dedicated to each realization. The first of these options may result in CSV files which are
too wide for EXCEL to read, and that are difficult to read even by a self-written program. The second
option can make processing of the ensemble difficult, as it may require that the program which reads this
file hold all realizations in memory at the same time. These processing difficulties are exacerbated by the
time required to read and write large ASCII files. These issues are typically encountered when the number
of parameters and/or observations is greater than about 10,000.
PESTPP-IES also supports storage of parameter and observation ensembles in so-called “enhanced
Jacobian matrix files”. These binary files are recognizable by their “.jcb” extension; hence they are referred
to as “JCB” files herein. JCB files can be converted to CSV files using utility programs supplied with the
PEST suite and demonstrated in this workshop. (Translation between these two file types can also be
accomplished using functionality available through the PyEMU library.)
In the workshops documented herein we make use of JCB files. However use of JCB files is not essential to
use of PESTPP-IES.

Running PESTPP-IES
PESTPP-IES can undertake model runs in serial or in parallel.
Suppose that a PEST control file is named case.pst. To undertake model runs in serial based on this file,
PESTPP-IES should be run using the command:
pestpp-ies case.pst
PESTPP-IES (and any other member of the PEST++ suite) undertakes model runs in parallel if its
execution is initiated in a similar manner to that of BEOPEST. First, all files required by PESTPP-IES, as
well as those required by the model that it runs, should be copied to all folders in which workers will be
operating. Execution of the PESTPP-IES manager is then initiated using the command:
pestpp-ies case /h :port
where port is a suitable port number (for example 4004). Note the space between “h” and “:”. Meanwhile,
execution of workers is initiated using the command:
pestpp-ies case /h ip_address:port
where ip_address is the IP address or hostname of the computer on which the manager is running and port
is the port used by the manager.
This same initiation protocol applies to other members of the PEST++ suite, including PESTPP-INV
(which carries out regularized inversion) and PESTPP-SWP (which undertakes model runs based on
different, user-specified parameter sets). PESTPP-SWP is used in the present workshop.

Groundwater Vistas Version 8 Page 246

Using PESTPP-IES in Groundwater Vistas
We will start this session from the point where the 3d pilot point example was ready for calibration with the
normal version of Pest. If you did not save this model, you can use the one called
New_gv8_tutorial_pilotstart_setup.gwv.
We need to make a few changes to this model at the start. First, select Model|Pest|Options and change the
value of NOPTSWITCH to 3. This is done because for some reason this particular model calibration goes
immediately from a single run per parameter to 2 runs per parameter. The use of NOPTSWITCH forces
pest to not switch right away.

Turn off the use of regularization as well on this default tab. Use of regularization is not appropriate when
using PESTPP-IES (although it will ignore the regularization informatin).

Set up for PESTPP-IES is virtually identical to that of PEST. There are a few new options, though. Select
Model|Pest|PESTPP-IES|Options. Use 80 realizations and turn ON the option to adjust observation
weights. Enter a weight scaling factor of 2 for heads. These new weights are intended to express the fact
that “noise” associated with head measurements that comprise the calibration dataset has a standard
deviation of 0.5.

Groundwater Vistas Version 8 Page 247

The first of the above fields instructs PESTPP-IES to use 80 parameter realizations and corresponding
observation realizations (observation values plus measurement noise realizations). As stated above, initial
parameter realizations are sampled from the prior parameter probability distribution; the parameter
adjustment process undertaken by PESTPP-IES transforms them until they become samples of the posterior
parameter probability distribution. As is also discussed above, the generation of observation realizations is
informed by weights ascribed to observations in the PEST control file; PESTPP-IES assumes that each
weight is the inverse of the standard deviation of measurement noise associated with the pertinent
observation.
The next fields instruct PESTPP-IES to read the parameter uncertainty file param.unc in order to obtain
prior parameter variances and covariances; prior parameter means are assumed to be initial parameter
values listed on the PEST control file. Note that where a parameter is log-transformed in a PEST control
file, then variances and covariances provided in a parameter uncertainty file must pertain to the log (to base
10) of the parameter. (Note that it is not essential that PESTPP-IES read a parameter uncertainty file. If the
parcov() control variable is omitted from a PEST control file employed by PESTPP-IES, then PESTPP-IES
calculates prior uncertainties from parameter bounds supplied in that file.)
During each iteration of the ensemble adjustment process undertaken by PESTPP-IES, an appropriate value
for the Marquardt lambda must be determined. This requires the testing of a few different values of this
variable and (optionally) of line search factors along each lambda-determined upgrade direction. The third
of the above control lines instructs PESTPP-IES to devote two realizations to ascertaining the best
Marquardt lambda and line search factor to use during each iteration. Once an appropriate Marquardt
lambda and line search factor have been selected, the remaining 78 realizations are then upgraded using this
lambda and line search factor.
Now run PESTPP-IES by selecting Model|PEST|PestPP-IES|Create Datasets and then Model|PEST|PestPP-
IES|Run PestPP-IES. PESTPP-IES will now run. When you see “--- starting solve for iteration 8 ---“, as
shown below, press Ctrl-C to end the run.

The most important line in the above display is the second last (starting with “actual”). This reports
objective functions based on differences between model outputs calculated using each parameter realization
and observations recorded in the PEST control file. As was stated above, if actual measurement noise is in
accordance with the weighting scheme used in the PEST control file, the values of these objective functions

Groundwater Vistas Version 8 Page 248

should be commensurate with the number of non-zero weighted observations featured in the PEST control
file, 42 in the present case. It is apparent that at the end of iteration 5, PESTPP-IES is well on its way to
achieving this result; in fact some realizations have actually exceeded this target.
The phi type of “measured” in the above table is calculated using differences between parameter-
realization-specific model outputs and corresponding observation realizations (each of these is comprised
of observation values plus a realization of measurement noise). The phi type of “regularisation” is
calculated from differences between the current values of parameters within a particular realization and the
initial parameter values that comprise that realization
To see the phi values for each realization in each iteration, you can view the file called t2.phi.actual.csv in
Excel. This shows that after iteration 7, the total number of runs was only 752. Compare this to the SVD-
Assist calibration where there were 402 runs just to compute an initial jacobian matrix. If you scroll to the
end of the line you will see the results of the “base” realization, which should be the lowest sum of squared
residuals.

If you would like to see the results of all realizations, select Model|PEST|PestPP-IES|Combine files. This
does the same thing as the combine results command for Null Space Monte Carlo and you can then do the
same sort of post-processing as outlined in the Null Space Monte Carlo tutorial.
On the other hand, if you just want to see the results of the base calibration to process like a normal pest
run, use Model|PEST|PestPP-IES|Run Base Realization. You first enter the Pestpp-IES output which is
t2.7.par.jcb for the 7th iteration and then specify a root name of t2.

Now import the results and your screen should look like the one below. If you review the calibration
statistics, you will see that this run is even better than the original Pest run for pilot points in 3D from a
previous tutorial.

Groundwater Vistas Version 8 Page 249

Groundwater Vistas Version 8 Page 250
MODFLOW-USG for Unstructured Grids
MODFLOW-USG is a new version of MODFLOW for use with unstructured grids. It is functionally
equivalent to MODFLOW2005 and MODFLOW-NWT but without support as yet for the UZF Package.
There are two manuals for MODFLOW-USG which are located in the GWV8\Documentation\USGS
directory on your computer. These are called:
mfusg_tm6-A45.pdf This is the main user guide for MODFLOW-USG
mfusg_io_v_1_0.pdf This is the guide to the input and output file formats
The following set of tutorials introduces you to the capabilities of MODFLOW-USG and how it has been
implemented in Groundwater Vistas 8. Even if you do not actually perform the tutorials, reading this guide
will familiarize you with the important concepts that you will need to understand before you can use this
new version of MODFLOW.

Mesh Concepts
Unstructured grids are those that are not necessarily arranged on row and column basis. These grids can
contain cells of just about any shape, such as triangles, octagons, quadrilaterals, etc. The trick is to tell the
model how the cells are linked together and the geometric information about the connections between cells.
Groundwater Vistas supports the use of MODFLOW-USG (and MODFLOW 6) through the use of square
and rectangular elements, but ones that do not necessarily line up in a row/column pattern. This means that
you can quickly use existing MODFLOW models and enhance them with new grid schemes.
First, you can use MODFLOW-USG with your normal MODFLOW row, column, and layer grids. Instead
of having a row, column numbering scheme, though, each cell has a node number. The following figure
shows how Groundwater Vistas numbers nodes in a normal MODFLOW grid.

One added benefit of this type of grid scheme is that you can pinch out nodes that are very thin. In a
normal MODFLOW grid, you cannot pinch out a layer. But using MODFLOW-USG, it is relatively
simple. We will cover this in a later exercise.

Groundwater Vistas Version 8 Page 251

Most modelers will want to take advantage of the unstructured nature of MODFLOW-USG to create
models that are refined in areas of interest but are also efficient in terms of the number of nodes required to
simulate these refinements. One way of doing this is the use of a nested grid, as shown below. This is a
similar concept to MODFLOW-LGR but with MODFLOW-USG the nested grid is part of the model
instead of being a separate simulation. In the nested grid, a rectangular area is subdivided into much
smaller cells and the area of refinement is confined to just the area of interest. In a normal MODFLOW
grid, these refinements must carry through to the outer edges of the grid which means that many extra rows
and columns are needed.

Nested grids are actually separate objects in Groundwater Vistas so they can be turned on and off. This
means that you can have a regional model with a relatively uniform grid and quickly add a nest to it to
make a more detailed prediction. When that prediction is no longer needed, the nest can be temporarily
deactivated. The main limitation with nests is that they cannot overlap each other. Each nest, though,
contains its own properties and boundary conditions which are initially inherited from the parent grid. The
properties and boundary conditions can be refined, however, once the nest has been created.
Nested grids can have the same layering scheme as the parent model or sublayering can be used. In a
sublayered nest, the nest can be confined to a subset of parent layers and/or the parent layers can be
subdivided. The figure below shows a cross section through a nested grid that has 5 layers in the parent
grid and 5 layers in the nest. However the nest layers start in parent layer 2 and end in parent layer 4, with
parent layer 3 split into 3 sublayers.

Groundwater Vistas Version 8 Page 252

This makes keeping track of where you are in the USG model a bit tricky. You will notice that a new item
has been added to the 3D cube at the left side of your Groundwater Vistas window. This is the "Sublayer"
number. The "Layer" number refers to the original parent layer you are viewing. If a nest has sublayers,
you may view the properties and boundary conditions of each sublayer using this "Sublayer" item on the
3D cube. If a parent layer does not have sublayers then the sublayer number cannot be changed from the
default of 1.
One potential use of this sublayer nest concept is to have high resolution in the upper layer of the model so
that surface water features can be better resolved and coarser cells in deeper layers (see the cross section
below). A USGS model in the upper Midwestern US is making use of this type of nested grid, for example.

A much more general gridding scheme is called quadtree refinement. This is similar to finite-element
modeling but the mesh is a lot easier to generate and maintain. In smoothed quadtree refinement, each
parent cell can be refined into subcells using a power of 2. This means that subgrids of 2x2, 4x4, 8x8,
16x16, and 32x32 subcells can be created. Unlike the nested grid, these refinements happen on a cell-by-
cell basis. Within Groundwater Vistas, the refinements are smoothed such that each cell connects to no
more than 2 other cells on each face of the cell. An example of a smoothed quadtree mesh is shown below.

Groundwater Vistas Version 8 Page 253

In all of these mesh types (normal finite-difference, nested grids, sublayered nested grids, and quadtree
refined grids), cells can pinch out if the cell thickness is below a specified threshold level. When this
happens, the nodes above and below the pinched out layer are connected as if that cell was not there. This
is shown in the figure below. Groundwater Vistas indicates that a cell has been pinched out by coloring it
as shown (the user may customize this color).

Groundwater Vistas Version 8 Page 254

If you have the Professional or Premium versions of Groundwater Vistas, you can also design meshes that
contain non-rectangular cells. The most common types are triangular and voronoi meshes. These mesh
types are designed in a separate program called AlgoMesh. The mesh is then exported to a grid-
specification file (GSF) and imported into Groundwater Vistas. You then design the remaining aspects of
the model such as boundary conditions and properties. The following are examples of mesh types that can
be designed in AlgoMesh:

In the following tutorials we will start with examples that do not need AlgoMesh and then follow those
with some AlgoMesh tutorials.

MODFLOW-USG Versions
There are two versions of MODFLOW-USG. The public version is from the USGS
(http://water.usgs.gov/ogw/mfusg/) and the Transport Version (used to be called advanced or beta version)
is available through Groundwater Vistas. The USGS and transport versions support the following
MODFLOW packages:
BASIC
Block-Centered Flow (BCF) with upstream weighting capability of MODFLOW-NWT
Layer-Property Flow (LPF) with upstream weighting capability of MODFLOW-NWT
Horizontal Flow Barrier (HFB)
Time-Variant Constant Head (CHD)
Recharge (RCH)
Evapotranspiration (EVT)

Groundwater Vistas Version 8 Page 255

 Transient Flow and Head Boundary (FHB)
Well
Drain
River
General-Head Boundary (GHB)
Stream (STR7)
Streamflow Routing (SFR2)
Gage
Lake3
Subsidence (SUB)
Sparse Matrix Solver (SMS)
Ghost-Node Correction (GNC)
Connected Linear Network (CLN)

Groundwater Vistas supports all of these packages. You will note that there is a new solver, called SMS,
which must be used for every model. This is essentially the same solver used in MODFLOW-NWT. Two
other new packages are Connected Linear Network (CLN) and Ghost Node Correction (GNC). The CLN
package is roughly equivalent to the multi-node well (MNW) packages or MODFLOW-Surfact's Fracture
Well packages. The GNC Package is generally needed when two nodes do not line up perpendicular to the
cell face separating them. Nested grids and quadtree grids may need ghost node corrections. Groundwater
Vistas automatically configures ghost nodes, though, so you only need to decide whether to use them or
not. The MODFLOW-USG manual contains a good discussion on ghost nodes.
The transport version of MODFLOW-USG contains the following additional packages and options not
supported by the USGS version:
Adaptive Time Stepping (ATS)
Transient IBOUND (TIB)
Ponding Depth and Time-series Options added to the Recharge Package
Time-Series option added to the ET package
Richards Equation formulation (unsaturated zone flow) added to BCF and LPF
Dual-Porosity Flow (DPF)
Specified Gradient Boundary Condition (SGB)
Block-Centered Transport (BCT)
Prescribed Concentration Boundary (PCB)
Dual Porosity Transport (DPT)
Density Driven Flow (DDF)
Time-Variant Materials (TVM)
Sink Return Flow (QRT)

Adaptive Time Stepping is similar to the MODFLOW-Surfact ATO Package but also allows you to change
some solver parameters by stress period. These packages are described in detail in the Groundwater Vistas
8 Users Guide.

Groundwater Vistas Version 8 Page 256

Converting an Existing Model
We will explore the use of MODFLOW-USG by starting with an existing MODFLOW model. This is
likely how you will start using it. Start Groundwater Vistas and open the model called
new_GV8_tutorial.gwv located in the gwv8\tutorial directory. The model should look like the one below.
It is a simple 3-layer model with constant heads on the west end and some pumping wells in the lowest
layer.

To run MODFLOW-USG on any existing model, simply select Model|MODFLOW|Packages and change
the version of MODFLOW-USG Transport. As long as the "automatically reset package units" flag is ON,
Groundwater Vistas will change the solver to SMS, set the flow package to LPF, and change the
MODFLOW program file to MFUSGsWin32.dll.

Groundwater Vistas Version 8 Page 257

When you click OK, Vistas will alert you to the fact that it changed the MODFLOW-USG solver to the
default set of options. You should confirm that the MODFLOW program file was changed by selecting
Model|Paths to Models, as shown below.

Groundwater Vistas Version 8 Page 258

Note that Groundwater Vistas also put the name of the MODFLOW name file under the Command Line
arguments field. This is not necessary for the DLL version. However, if you want to switch to using the
console version you will need this. In most cases, the console version of MODFLOW-USG (called
USGs_1.exe) is the same as the DLL version. However, there may be times when we suggest you change
to this console version because it is more up to date. To change to the console version, you would change
the MODFLOWwin32 option at the top to "Do Not Use" and then click the browse button next to the
MODFLOW program and find the USGs_1.exe file in the GWV8 directory. Likewise, if you would like to
use the USGS version you would do the same thing but find the file called mfusg.exe or mfusg_x64.exe.
We do not install the USGS version with Vistas to avoid confusion but you may download it from the web.
The only other thing you may want to do is select Model|MODFLOW-USG|Options to see if there are
options you want to repeat in the USG run. For example, if you had been using MODFLOW-NWT or
MODFLOW-Surfact (with pseudo-soil functinos), you should turn ON the option called "Use Upstream
Weighting on Convertible Layers" (this is chosen automaticallyl when you convert any modflow model to
USG). If you had been using MODFLOW-Surfact to simulate unsaturated zone flow, then also activate
"Use Richards Equation Formulation in BCF/LPF". You will see that the "Use Ghost Nodes..." option is
not activated. This would only be used if you had a nested grid or a quadtree grid. Even then you should
make sure the model runs successfully before trying the ghost node option as the latter can cause the model
to have convergence problems..

Groundwater Vistas Version 8 Page 259

You should also check the solver settings on the "SMS General" tab of this options dialog. SMS is the only
solver used in MODFLOW-USG and the settings are provided here. Like MODFLOW-NWT, you may
elect to have the program set many of the solver options for you. You may select from SIMPLE,
MODERATE, or COMPLEX. These settings generally do not work very well with USG Transport, so
Groundwater Vistas automatically sets the solver to “Specified by User” and then selects a set of options
that we have found to work in most cases.

Groundwater Vistas Version 8 Page 260

The last thing to do before making your first run is to check the new packages available in MODFLOW-
USG. Select Model|Modflow-USG|Packages. The CLN Package would be selected if you were using
either MNW1, MNW2, FWL4, or FWL5 packages in the previous run. The GSF package is used only if
you are using PEST with pilot points for calibration or if you intend to do particle tracking with MOD-
PATH3dU. GSF is not used directly by MODFLOW-USG but is needed so that the PEST utility programs
(mainly PLPROC) knows something about the unstructured grid layout. In this first model we do not use
those packages so you can leave this packages dialog alone.

Groundwater Vistas Version 8 Page 261

Before running this model, it is a good idea to use File|Save As and create a new gwv file for use with
MODFLOW-USG. GV will also ask if you want to change the root file name. Select Yes and change the
run name from t2 to t2u.

Groundwater Vistas Version 8 Page 262

Now click the calculator button, answer YES to create datasets, NO to see the error/warning file, and then
the model should run very quickly. Answer YES to import the results of this run. One thing to note on the
import results dialog is the "Unstructured Grid" option below the time step and stress period to import.
Normally this will be set correctly but you need to check it as the unstructured grid binary files are
somewhat different from a structured grid run.

The contoured heads should look like the original modflow run, as shown below.

Groundwater Vistas Version 8 Page 263

So there is really not much problem running your existing model in MODFLOW-USG. Of course, the
more complex the model, the more time may be required to adjust solver settings. However, it should not
be too difficult to migrate to MODFLOW-USG so that you can begin to use the more robust mesh options.
If you are knowledgeable about MODFLOW file formats, you may want to check out the equivalent
MODFLOW-USG files. You will find they are very similar to the standard MODFLOW files. One
difference is that 2D arrays (e.g. row-column matrices for layers of data) are now 1D by node number.
Boundary condition files which typically start each line with the layer, row, and column number, now just
list the node number. Otherwise the files are almost identical. Probably the biggest difference is the
discretization file. In previous versions of MODFLOW, discretization consisted of layer elevations and the
row and column spacings. In an unstructured grid, though, there is no preconceived idea about what the
grid should look like. Therefore the DIS file needs to list how nodes are connected to each other, the
distances between nodes, the area at nodal interfaces, and elevations. MODFLOW-USG still has the layer
concept, although it is more general. Now, MODFLOW-USG also needs to know if nodes are connected
horizontally or vertically.
For a little more practice at converting a normal MODFLOW model to MODFLOW-USG, try using the
model called bedrock_example.gwv also located in the tutorial directory. If you have a model of your own,
now is a good time to try that out as well.

Groundwater Vistas Version 8 Page 264

Nested Grids
We will now add a nested grid area to an existing model. Start by opening the model called
Bedrock_example.gwv located in the gwv8\tutorial folder. Convert this model to MODFLOW-USG as you
did in the previous section.

Now create datasets and run MODFLOW-USG on this model. After running the model in MODFLOW-
USG, the results should look like the figure below.

Groundwater Vistas Version 8 Page 265

The nested grid approach works best when the parent or regional model has a relatively uniform grid. The
grid does not need to be uniform to use a nest but it makes a lot of sense to do this. The uniform grid
model is generally fast and efficient to simulate and the nest can then be added at any point where
additional details are required. This model is not totally uniform but only has one level of refinement
around the "site" - the red box in the figure above. Select Plot|What to Display and turn on the grid so we
can see it while adding the nest. Zoom in around this site area.

Groundwater Vistas Version 8 Page 266

One thing we did not discuss in the last example was how Groundwater Vistas displays information about
unstructured grids. GV still keeps track of the parent grid using the original row and column numbers.
These are shown on the status bar on the right side of the screen. The node number corresponding to the
original row and column number is shown on the left side of the status base as the cursor is moved around
on the model grid.
Before we add a nested grid, save this file as Bedrock_Example_USG.gwv. We will use this in another
exercise to add a quadtree grid after we work on the nested grid.
Now, to add a nest you simply select Grid|Nested Grid|New and drag a window from row 42, column 49
(node 7347) to row 52, column 64 (node 9091). The following dialog will then be displayed:

Change the number of divisions for both rows and columns from 2 to 3 as shown above. Keep the other
information at the default values. If you did want to either restrict the nest to a subset of layers or split the
original layers into sublayers you would make those changes here. When you click ok, GV will ask if you
want to copy the parent boundary conditions to the nest. Normally it is a good idea to do this. You can
always modify them later. However, if you know that you will be importing new information from
shapefiles or other sources, then answering no is fine too. In this example, answer YES to copy the parent

Groundwater Vistas Version 8 Page 267

boundary conditions to the nest. Now your grid should look like this. (Note: you may see purple dry cells
in the nest. This is because we do not have heads yet for this area. You can turn them off using plot/what
to display).
If you zoom in a bit on the nest you will see that the drain boundary conditions cover the same extent as in
the parent grid. The conductance, however, has been adjusted so that it is proportional to the new cell size.

Use File|Save As to create a new GWV file for this nested grid. You should generally use ghost nodes
with nested and quadtree grids in MODFLOW-USG. Ghost nodes are necessary to make the solution more
accurate. The MODFLOW-USG manual describes ghost nodes and their significance. In Groundwater
Vistas, ghost nodes are added laterally around nested grids. If the nested grid is not contained in all layers,
ghost nodes are also placed above and/or below the nest. The figure shown below illustrates the position of
ghost nodes (shown in green) around part of a nested grid.

Groundwater Vistas Version 8 Page 268

The red triangle shows that the ghost node for node 56 is a linear interpolation of nodes 10 and 18 outside
the nest. The idea is to have a ghost node outside the nest and perpendicular to the edge of the node in the
nest (56 in this case). When a nest overlies a parent grid cell, the ghost node is directly beneath the node in
the nest and inverse distance weighting of the closest parent nodes is used in assigning the ghost nodes.
Because this all happens behind the scenes, you do not need to design and configure the location and
parameters for ghost node. You simply need to decide whether you need to use ghost nodes or not.
Sometimes when you have a complex nested or quadtree mesh, the model will not converge well with
ghost nodes at first. A trick to use when this happens is to run the model first without ghost nodes and then
use the heads from that first run as starting heads for the next run where you add ghost nodes.
Select Model|MODFLOW-USG|Options and turn on "Use Ghost Nodes..." and the other option called
"Use Explicit Update for ghost nodes...", as shown below.

Groundwater Vistas Version 8 Page 269

Now run the model to confirm that everything works.

Groundwater Vistas Version 8 Page 270

You will notice that when the nest was created, Groundwater Vistas copied the original river and drain
boundary conditions from the parent grid to the nest and split them into the smaller cells of the nest. You
may refine these boundary conditions by selecting BCs|Drain and right-click on any boundary cells you
would like to remove from the nest. Refining rivers and drains in the nest shown above would look
something like this:

Groundwater Vistas Version 8 Page 271

You can also reimport any shapefiles or text files (as long as they reference x & y coordinates and not row-
column coordinates) to reset boundary conditions in the nested area.
Before we move on the adding a well, we will set our starting heads from the results we just created.
Adding starting heads from a previous run serves two purposes. First, it makes the model run faster and
you can also compute drawdown based on whatever change you intend to make.
Select Props|Initial Heads and then Props|Import|Matrix. Browse for the head file from the last run with the
nest. Turn on the flag for a binary file at the bottom of the dialog and click OK. Now use File|Save As to
make a new version of the model and, when prompted, select a new root file name.

Groundwater Vistas Version 8 Page 272

Select Props/Property Values/Manually Reset Property Bounds. Enter 320 for minimum head and 560 for
maximum. You screen should look like the following:

Groundwater Vistas Version 8 Page 273

Connected Linear Networks (CLN)
In MODFLOW2000/2005/NWT, wells that are screened across multiple layers can be simulated using the
MNW1 or MNW2 Packages. In MODFLOW-Surfact, the same thing can be simulated using FWL4 or
FWL5. The MODFLOW-USG equivalent is called the Connect Linear Network (CLN) Package. It is
much more general than MNW or FWL. For example, you could simulate a conduit (i.e., karst system) or a
river. Groundwater Vistas supports vertical CLNs for wells and quasi-horizontal CLNs in the form of
polylines to simulate kart features, stream channels, horizontal wells, etc.
We will now add a multi-layer well to the nested area in the previous model. Select AE|Well and move the
cursor to somewhere in the nest (see next page) and click the left mouse button. This brings up the analytic
well dialog. Analytic wells are located at an (x,y) location rather than a row,column location and are the
only way to use the CLN Package with wells. Enter a flow rate of -10,000.00 (without the comma!) and
turn ON the option that says "Use as Fracture Well...or Multi-Node Well...or CLN...". This is the master
switch that tells GV that you want to use whatever multi-node well package makes sense based on the
MODFLOW version you are using.

Groundwater Vistas Version 8 Page 274

There are additional options for CLN wells on the "CLN Data" tab. For now, you will not change these but
if you wanted to simulate a skin effect, for example, that would be selected on the "CLN Data" tab. Each
special multi-node package (MNW, FWL, and CLN) has it's own tab to keep the options organized. Click
OK when you are done and the well should be located as shown below.

Groundwater Vistas Version 8 Page 275

Groundwater Vistas Version 8 Page 276
We also have to activate the CLN package for MODFLOW-USG. Select model|MODFLOW-
USG|Packages. Enter 88 as the unit number for CLN and check the 2nd column to create the file.

Now run the model as before and bring in the results. The contours may be a bit coarse as the default
setting is to contour the entire model. Select Plot|Contour|Window and drag a window around the area of
the nest to make them smoother. The results should look similar to the ones below.

Groundwater Vistas Version 8 Page 277

Many Groundwater Vistas users are used to viewing and editing the MODFLOW input files. With CLN,
this can be a bit tricky. If you open the CLN input file for this example, it should look like the following:

Even if you don't know how to read this format, you can see that the pumping rate of -10,000 is not in this
file. The CLN file defines the location of the feature within the parent model and defines the physical
characteristics of the well. However, the rate is actually stored in the MODFLOW Well Package. Open
that file in a text editor and you will see the following:

Groundwater Vistas Version 8 Page 278

The Well Package stores the rates for CLN wells (it is the last line of information in the file shown above).
The node number in the Well package (3 in this case) is not the node number in the MODFLOW model.
Rather, it is the CLN node number. The CLN file contains the mapping of the CLN nodes (1, 2, and 3 in
this example) to the MODFLOW model node numbers (11975, 25065, and 38155). So for those of you
that like to do some file creation outside of Groundwater Vistas, this makes things a bit more complicated
when dealing with the unstructured grids.

Quadtree Refinement
Quadtree refinement is also available in Groundwater Vistas as an alternative to the nested grids. The
following tutorial example will illustrate how to design a simple quadtree mesh. As with nested grids, it
makes sense to start with a relatively uniform parent model grid. This is not really necessary but we
believe it will make the resulting meshes more visually appealing. There will be no restrictions on this,
however, within Groundwater Vistas.
Using quadtree refinement in a model grid is three-step process. In the first stage, each cell in the model is
assigned an integer code from 1 to 7. A value of 1 means that the cell will not be divided. A value of 2
indicates the cell will be split into 2 rows by 2 columns, 3 means a 4 x 4 split, 4 means 8 x 8, 5 is 16 x 16, 6
is 32 x 32, and 7 is 64 x 64. These will be color coded in Vistas. In the example below, the white cells are
not divided, blue will be divided 2 x 2, and green will be divided 4 x 4.
Two types of quadtree refinement can be performed in Groundwater Vistas. In the most simplistic case, the
same level of refinement is used in each model layer. In Groundwater Vistas 7, this was the only type of
quadtree refinement allowed. In version 8, you also have the choice of have different levels of quadtree
refinement in each layer. To use the same quadtree refinement in each layer, you only have to define the
level of refinement in layer 1. For the 3D case, you define the levels in each layer. Use of sublayers is
NOT supported in either quadtree grid type.

Groundwater Vistas Version 8 Page 279

Groundwater Vistas will make sure that prior to actually implementing the quadtree refinement, these codes
will be smoothed so that no cell can be divided more than a factor of 2 compared to an adjacent cell. Once
the smoothing has taken place, the quadtree mesh is created as shown below. Note that if you have a
different quadtree type in each layer, smoothing is done in 3D, starting with the most highly refined cells
and working out to the less refined cells.

Finally, after the quadtree refinements have been made new boundary conditions and updated properties
can be applied to the refined mesh. The best approach will be to have boundary conditions like rivers be
defined in one or more shapefiles so they can be easily imported and assigned to the new grid.
Start this example by opening the file called Bedrock_Example_USG.gwv located in the gwv8\tutorial
directory. The model is a uniform grid model already set up for use with MODFLOW-USG. We are going
to add quadtree refinement around the streams and the large river in this model. This is an ideal use of
quadtree refinement where the grid is refined along linear features that do not lend themselves to use of a
nested grid.

Groundwater Vistas Version 8 Page 280

Start by importing two shapefiles (largeriver and streams) into the Hydrostratigraphy property. Select
Props|Hydrostratigraphy and then Props|Import|Shapefile. Both imports work the same way. Change the
“Zone Number” column in the database to “QT”, as shown below and then click OK.

Groundwater Vistas Version 8 Page 281

After importing both shapefiles, your screen should look like the following if you turn off display of
boundary conditions:

The light blue cells are in the large river and will be refined to quadtree level 2 (2 x 2 refinement in each
parent cell) and the green cells in the streams will use quadtree refinement level 3 (4 x 4) refinement.
Select Grid|Quadtree Refinement|Start Quadtree Mesh. Groundwater Vistas will then ask if you want to
vary quadtree refinement by layer. Answer NO to this prompt.

Then select the next command called Grid|Quadtree Refinement|HSU zone to Quadtree level. Now the
model should look like the following:

Groundwater Vistas Version 8 Page 282

Next we will smooth the quadtree grid so that there is never more than a 2:1 connection between adjacent
nodes. Selecct Grid|Quadtree Refinement|Smooth Quadtree Mesh. Now the model should look like the
following:

So far, Groundwater Vistas can draw the quadtree mesh but it has not computed node numbers and nodal
geometry yet. If you are satisfied with the quadtree mesh, select Grid|Quadtree Refinement|Allocate
Quadtree Mesh. When GV8 asks you if you want to copy boundary conditions to the new grid, answer
NO. We will import the river cells again from the shapefiles to take advantage of the new grid resolution.

Groundwater Vistas Version 8 Page 283

Your screen will not look any different but now when the cursor moves around the screen, you'll see the
correct node numbers displayed in the status bar at the bottom of the Groundwater Vistas window.
This is a good time to use File/Save As to create a new GWV file. Do that now and change the root name
when prompted to Bedrock_Example_QT.gwv.
To get the river boundary conditions back into the model, select BCs|River and then BCs|Import|Shapefile.
Start with the largeriver.shp. Fill out the dialog as shown below:

Note that we turned OFF the checkbox near the bottom called “Import into Parent Grid”. We only want to
replace river boundary conditions in the quadtree cells.

Groundwater Vistas Version 8 Page 284

Do the same thing with the streams shapefile, using the following example:

Groundwater Vistas Version 8 Page 285

Now the stream network should look much more refined, as shown below:

Save your work and then run the model. The results should look like the following:

Groundwater Vistas Version 8 Page 286

Octree Refinement
In the quadtree example in the last section, the final model had 75,267 nodes. The quadtree mesh was
defined in an identical way in each model layer. In this model, though, the quadtree was really used to get
better resolution around streams, which are only in layer 1. Now, let’s see what happens if we use octree
refnement where the quadtree refinements are smoothe vertically to remove resolution with depth.
Start with the model from the last section, Bedrock_Example_QT.gwv. Remove the quadtree refinement
by selecting Grid|Quadtree Refinement|Remove Quadtree Mesh. This reverts back to the original normal
MODFLOW grid.
Select Props|Hydrostratigraphy. You should still have the HSU zones that were used to create the quadtree
mesh. (If not, go back to the last section and set up the HSU zones as before).

Select Grid|Quadtree Refinement|Start Quadtree Mesh. This time answer YES when prompted to vary
quadtree refinement by layer. Select Grid|Quadtree Refinement|HSU Zone to Quadtree Level. So far, the
grid looks just like the last section. Now use Grid|Quadtree Refinement|Smooth Quadtree Mesh.
Layer 1 should look just like layer 1 before. But go down to layer 2 and you will see that there are
refinements in this layer that are not the same as in layer 1.

Groundwater Vistas Version 8 Page 287

The streams were refined into 16 quadtree nodes per parent node in layer 1. In layer 2, these same cells are
refined into 4 quadtree cells. If you look at layer 3, you will see just normal parent cells.

Groundwater Vistas Version 8 Page 288

Use Grid|Quatree Refinement|Allocate Quadtree Mesh to make these refinements permanent. Return to
layer 1 and import the stream shapefile like you did before. Select BCs|River and then
BCs|Import|Shapefile. Start with the largeriver.shp. Fill out the dialog as shown below:

Note that we turned OFF the checkbox near the bottom called “Import into Parent Grid”. We only want to
replace river boundary conditions in the quadtree cells.

Groundwater Vistas Version 8 Page 289

Do the same thing with the streams shapefile, using the following example:

Groundwater Vistas Version 8 Page 290

Now the stream network should look just like the previous example. The only real difference is that the
quadtree resolution is highest in layer 1 and decreases with depth. The total number of nodes is now
49,443 instead of the previous 75,267.

The main workflow difference between a normal quadtree mesh ans an octree mesh is that defining the
level of refinement for quadtree is done ONLY in layer 1. For Octree, the level of refinement is defined in
all layers. Also, smoothing is done between layers in octree. GV will start with the highest level of
refinement and smooth the refinement out both laterally and vertically from those highest levels. It then
proceeds to the next lowest level of refinement and so on.

Polyline CLNs to Simulate Karst, Fractures, and Streams

One of the unique features of MODFLOW-USG Transport is the CLN Package, which stands for
connected linear networks. The CLN grid is a series of line segments which can be vertical (wells),
horizontal, or inclined. In this section you will define several CLN polylines to represent a stream in a
simple model to see how they can be used in place of rivers, drains, and stream boundary conditions.
Start by opening the model CalEx1.gwv. This model should look like the following:

Groundwater Vistas Version 8 Page 291

We are going to replace the largest set of drains with several CLN polylines. These drains represent an
ephemeral stream that flows when the water table rises up the drain elevation. The same thing can be
simulated with CLNs. The main difference is that we also get stream flow in addition to the groundwater
discharge to the drains.
You will digitize 3 polylines as shown below:

For each polyline, start where the 3 intersect and digitize in the order shown above. Each polyline should
have about 7 line segments.

Groundwater Vistas Version 8 Page 292

Start by converting this model to MODFLOW-USG Transport by selecting Model|MODFLOW|Packages
and change the version at the top. Click OK.
To digitize each of the 3 polylines, use AE|CLN Polyline. Click the left mouse button to set a point along
the line (right-click deletes that last point) and double click the left mouse button to end. Then a dialog is
shown with multiple tabs. On the main tab, do the following:
- Change the hydraulic conductivity to 0.0002 (this is the Manning coefficient or CONDIUTK)
- Change starting elevation to 147 and ending elevation to 141
- Change starting head to 152 and ending head to 146

Note that when digitizing these CLN polylines, you should NOT change the Global Starting Node Number.
Groundwater Vistas computes with from all other CLN polylines and is the correct one to use in all cases.
The elevations entered for the beginning and end of the polyline determines which layer the polyline will
be in. In the case of a stream these elevations should be slightly below land surface and represent the
bottom elevation of the stream channel. The starting and ending heads set the initial conditions of the CLN
nodes. GV will linearly interpolate to the intervening CLN nodes on the line. You can see and edit that
data by clicking the Node Properties button. Remember that each line segment along the polyline is one
CLN node. The head computed for this node is at the center of the line segment so it is block-centered just
like MODFLOW.
Now, click the Groundwater Connection tab and change the skin factor (hydraulic conductivity in this case)
to 100.

Groundwater Vistas Version 8 Page 293

This first CLN will have a drain at the end, so click the BCs tab. Change the end boundary condition to
Drain with head of 143 and conductance of 10000.0.

Click OK when you are done. Now digitize the second polyline, starting from the beginning of polyline 1
and moving upstream. Try to digitize about 7 segments. There will be no boundary conditions on this
polyline but change hydraulic conductivity to 0.002, starting elevation to 147, ending elevation to 200,
starting head is 152, and ending head is 205. Click the Groundwater Connection tab and change the skin
factor to 100.
Another key thing to do before clicking OK, is to define how the second polyline connects to the first one.
This has to be done manually when hand digitizing. Click the Connections tab and enter 1 for the node that
connects to the starting node of this polyline. This says that the beginning of polyline 2 connects to the
beginning of polyline 1, which is node 1.

Groundwater Vistas Version 8 Page 294

Now digitize the third polyline. Do the same as for polyline 2. The only difference is that the ending
elevation is 215 and ending head is 220. Everything else should be the same.
The last step is to connect the first polyline to the other two. You already told GV that polylines 2 and 3
connect to CLN node 1 on polyline 1. Now you have to make that connection symmetric by entering
similar information on the dialog for polyline 1. Double-click the first polyline, click the Connections tab
and enter the starting node number on each of the other two. If you do not remember, double-click those
other two polylines first and write down the global starting node number at the top of the main tab. In this
example, I have nodes 8 and 16.

Groundwater Vistas Version 8 Page 295