Discussion archives on Groundwater Modelling

I have been compiling selected extracts on groundwater modelling discussion from various
mailing lists for last many years, as given below. I understand that in view of random and
discontinuous placing, many parts may not be easily comprehensible. Still I think that it could
be helpful to groundwater modellers to some extent.
Regards,
C. P. Kumar
==================================================
C. P. KUMAR
Scientist 'F'
National Institute of Hydrology
Jal Vigyan Bhawan
Roorkee - 247667 (Uttaranchal)
INDIA
http://www.angelfire.com/nh/cpkumar/
https://in.groups.yahoo.com/groups/cpkumar/
Groundwater Assessment and Modelling (Book)
http://www.amazon.com/Groundwater-Assessment-Modelling-Mr-Kumar/dp/1511520493
==================================================

Discussion archives
* In my experience, PCG is faster than LMG for small models but LMG is faster for large
models. Of course, for small models, speed generally is not so much of an issue.
* DAMP is used as a multiplier to scale the head change at each iteration, not RELAX. The
DAMP parameter in the PCG solver package is analogous to the ACCL parameter in the SIP
package. Although I cannot explain precisely what RELAX controls (since I'm no
mathematician), the typical range for RELAX is 0.97 to 1.0. In my experience, setting
RELAX=0.97 can help to achieve convergence, and may speed up convergence on a "wellbehaved" model, but not always.
* I'm sure you've heard "All models are wrong but some are useful." If you replaced all the wells
in a model with drains, you would expect to get different results. How is this any different?
You have replaced one package with a different one that is based on different assumptions so of
course, they get different results. If you want to know which one is better, examine the
assumptions behind the different packages and see which assumptions best match the conditions
at the particular region to be modelled. If none of the available packages do what you need,
write your own package to do what you need.
* The newer LPF package is the way that most other models work, i.e., you enter Kz and the
inter-cell conductances are computed internally. The way that MODFLOW88/96 did it with a
pre-computed vertical conductance always struck me as a bit odd; however, that has been our
happy MODFLOW world for about 20 years. So now we have a new option that is
mathematically more correct, but it is still disconcerting when the computed heads are different.
I guess you'd have to ask a lawyer about who would win. My sense is that the differences could
never be explained to a jury. It does present the MODFLOW modeling community with a

problem, though. The way that you did it with MODFLOW-SURFACT is probably the way that
the USGS should have done it as well - adding the input of Kz in the BCF Package.
* Input of vertical hydraulic conductivity has its advantages, however, McDonald and Harbaugh
got it correct in keeping a fixed thickness of a cell for the vertical direction conductance - for
gravity-segregated vertical equilibrium (GSVE), you have a transmissivity that is conductivity
times saturated thickness which is valid only for the horizontal direction and not for the vertical
direction (in actuality, the vertical direction physics changes from GSVE to unsaturated flow
which would lower the conductivity further and that would be closer to the "fixed thickness"
answers that do not reduce separation distance between 2 cells vertically even for consideration
of a homogeneous case, but that aside). Nor does the document state where or under what
conditions the use of a "variable thickness for vertical conductances" option performs better.
That's why I was asking to see if anyone knew why this was done in the first place.
* I propose that the node location of a cell that contains the water table should be located at the
water table instead of the center of the cell as is standard. Comparisons of this formulation to
analytic calculations numerically implemented in the WATQ code indicate a much improved
solution at shallow depths compared to the calculations of the current LPF formulation. This
formulation does not, however, take into account the dynamics of drainage from the unsaturated
region above the water table which can be a major influence. I want to repeat Richard Winston's
point that "All models are wrong". A model is not intrinsically good or bad. That judgment
depends on what the model is used for. What may be better in one situation may not be better in
another. You have highlighted this concept in your discussion of GSVE. MODFLOW still exists
for two contradictory reasons; 1) as the name implies it is modular and hence easily extensible to
specialized situations. 2) It is widely known and accepted that the code has accurately solved
groundwater flow problems. It is incorrect to extend the second point to expect MODFLOW to
accurately solve all groundwater flow problems. Once again required accuracy like good and
bad depends on the problem that needs to be solved. That MODFLOW produces two results for
the same geometry and boundary conditions means that it approximates the physics of the flow
situation differently. It proper care is taken, the ability to change the approximation of the
physics of flow is a good thing because the code can be tailored to specific problems.
* Yes, having flexibility in averaging schemes is a good thing. The LPF package provides one
more averaging scheme in the vertical direction. It does a harmonic average of the conductances,
as opposed to the BCF package's harmonic average of vertical conductivity times area divided
by separation distance as provided in the MODFLOW documentation for the various fully threedimensional, and quasi-three-dimensional alternatives. However, I am guessing that people are
encountering drastically different and surprising or unexpected results is because of the vertical
direction treatment. Specifically, the cell thickness varies as a function of its saturated thickness
in the LPF package for vertical direction treatment. For a simple example, consider a
homogeneous case with two cells where the cell below is getting drier. The vertical conductance
quickly rises due to the cell below drying up, to such levels that drain and dry up the cell above
(which also causes the conductance to increase in a cascading manner) which would be a very
different result than with use of any of MODFLOW's BCF options. Like I stated earlier, in fact,
when things dry up, it should slow down the conductance due to physics change to unsaturated
flow, and even a gravity flow assumption will not speed it up.
Yes, there is a dilemma in GSVE models for vertical direction treatment because GSVE by its
definition, applies only to horizontal direction flow - I have seen this in saltwater-freshwater
GSVE models with multiple aquifers as well. And there too, when you give it specialized
treatment, it is due to certain physically motivated considerations. Otherwise, the way
MODFLOW BCF did it (or a use of grid-block cell thickness in the LPF package) is the best
you can do with the VE assumptions being used, since conductance may be smaller than
saturated levels due to unsaturated zone physics - but you don't know by how much, unless you

simulate unsaturated zone physics. Using saturated thickness instead of cell thickness in the
vertical direction leads to results that are more removed from this physics.
* This is one of the most challenging groundwater modelling projects you can find in real-world
modelling... Ideally, you should use a saturated-unsaturated code, such as FEFLOW or Modflow
surfact or similar. Such codes are able of simulating perched water conditions.
If you are using traditional MODFLOW, and assuming saturated conditions, it is a bit more
complicated to simulate such a scenario. You will probably have some dry cell issues (and
perhaps some convergence problems), but it is possible to simulate the open pit crossing
multiple layers using drain boundary conditions.
For the upper layers, where seepage faces may occur, set the drain elevation slightly above the
layer bottom elevation (say 0.1 m above cell bottom elevation). If you use Visual MODFLOW
as the interface, that's very easy to do using formulas that will assign the correct elevation even
in irregular layers. In that case, if the head in the pit wall is higher than the cell bottom elevation,
Modflow's drain package will remove the outcropping groundwater. The conductance value
(another input to the drain package) is typically a calibration parameter, obtained through
matching drain removal rates with real values observed at the mine site.
I suggest that you also use a solver that is not too aggressive, such as PCG2, and that you play a
bit with re-wetting parameters and dumping factors until you obtain a stable solution. We've
done several mine dewatering modelling projects using this approach and it definitely works for
most cases, as long as you understand the code and it's limitations.
* Dry cells in a multi-layer model are not necessarily a bad thing unless they do not accurately
reflect the conditions in the field. Perhaps I am stating the obvious, but just for the record, dry
cells occur in MODFLOW models when the calculated water table is below the bottom
elevation of the grid cell. Since MODFLOW only simulates saturated groundwater flow, it does
not represent a head value in the unsaturated cell, so the cell becomes 'dry' and MODFLOW
assigns a 'dummy' head value usually in the range of -1e-30 (or something else easily recognized
as a dry cell). Although the presence of dry cells in a model is often a hassle because they create
problems with the convergence of the numerical solution, dry cells do not necessarily indicate a
'problem' or error with the model. In your case, the dry cells don't appear to be causing a
problem with the solution convergence (or atleast, you haven't mentioned this problem) and you
are getting a good mass balance, which is a good sign but doesn't necessarily indicate
'correctness' of the solution. If the water levels in the second layer of your model match closely
with the observed field conditions, then the occurrence of dry cells in layer 1 appear to be
reasonable.
However, if the dry cells are occurring where you would otherwise expect saturated conditions
(based on water levels in the field) then you probably need to revisit your boundary conditions
to make sure they are reasonable (conductance values are often the culprit), check your initial
heads and make sure you are not starting the iterations with dry cells, and make sure you have
enough recharge flux entering the system to accommodate flux leaving the system through
wells, rivers, and other boundary conditions. If all this looks good, then Mark Wilsanac gave
some very good suggestions on how to change the solver and rewetting package settings in order
to deal with dry cells. - Patrick Delaney
* If the river boundary cells are the only place in your model where water may leave the system,
then one of the most likely causes of the mass balance problem is the conductance values you
are using for the river cells. Check your conductance values to make sure they are within
reason. The conductance values can be reasonably estimated using the following formula:

C = (L x W x Kv)/B
where
L = length of the river in a cell W = width of the river in a cell Kv = vertical hydraulic
conductivity of the riverbed in a cell B = thickness of the riverbed in a cell
Most of the popular graphical interfaces for MODFLOW allow you to enter these 'physical'
parameters and will automatically calculate the conductance values for each river boundary cell.
Another possible cause for mass balance problems could be the solver you are using (SIP often
produces larger mass balance than other solvers like the PCG or LMG) or perhaps the
convergence criteria for the solver is not 'tight enough'.
Just as an afterthought, the fact that you have more water entering the system from the rivers
than leaving the system through the rivers does not, in itself, indicate a problem with the water
balance. This indicates you have 'losing rivers' because the water table adjacent to the river is
lower than the river stage. The excess water entering the system from the rivers may be leaving
through other avenues such as evapotranspiration, pumping wells, drains, specified head head
boundaries, etc. - Patrick Delaney
* Check out if you don't have any dry well cells, or any other dry boundary cell. If a cell goes
dry during simulation, it becomes inactive for MODFLOW, and any boundary assigned to that
dry cell will be ignored. That means that your wells may be inactive (even though you assigned
them to be pumping all the time). That typically produces a noticeable change in the budget, but
sometimes the heads may not change too much, unless you look at specific well cells very
closely.
My suggestion is to first look into the budget for changes in well pumping/injection rates. If the
total rate is different from those you entered into the model, then you have a dry well cell. Zoom
in all well cells to identify which ones have become dry during that stress period (look in all
model layers).
* With a model set up with cell-to-cell size changes below 50%, there can be instabilities or
failure to converge. This can be due to other reasons, or cell size change coupled to highly
variable conditions in a transient solution. If a geologic unit pinches out, that should be
represented primarily by changes to cell properties, and secondarily by changes in cell
dimension (aspect-ratio rules apply vertically as well as horizontally). Remember to preserve
aspect ratios of each cell below 10:1, and below 5:1 to be safe. It is acceptable to have a layer
with variable properties from cell-to-cell. It is rarely acceptable to use MODFLOW cell
dimensions to closely simulate physical variations in layers when they pinch out.
* I have not used the WHS solver sold by waterloo hydrogeologic. while i therefore cannot
comment on this solver and its claimed superiority to SIP, i feel quite sure that SIP has been the
best performing solver for almost all models i have constructed over the past few years, and
never had problems with mass balance which could not be successfully overcome by using SIP.
i do recall a paper published in Ground Water years ago when WHS proponents at software
developer Waterloo Hydrogeologic compared their WHS to SIP and PCG (among other public
domain solvers). i felt that sip had been shortchanged and misrepresented in their analysis in
that they had claimed that sip yielded a much greater mass balance error than that obtained when
using their whs solver. what they had failed to do in their analysis, was to accordingly decrease
the HCLOSE with their corresponding decrease in the acceleration parameter. this is the
equivalent of not closing tightly enough on heads, and therefore, ending up with an excess mass
balance error. this was an improper use of SIP.

I have found that lowering of the acceleration parameter, and corresponding decrease in the
HCLOSE will yield a very low (acceptable) to zero mass balance error, but one must be careful
in that the acceleration parameter is not set so low that the model converges prematurely with
insufficient head change.
* Check all inputs in the flow model first. Make sure your flows are realistic. Make sure your
K's and recharge are realistic. Refine your grid and use dispersivity values that will minimize
numerical dispersion. Make sure your grid cell size complies with appropriate Peclet criteria (as
a rule of thumb, for finite differences, Pe should be ~ 2; that means your grid size should be
roughly 2* your dispersivity value, in the area where, for MOC, this can be higher). I suggest
your read some transport modelling books that explain this in detail. Be careful with using
constant concentrations, they can act as a source, but also as sinks (if he concentration in
neighbouring cells is higher than the ones you specified in the constant concentration node).
* When she is referring to inflow, in plane, and outflow, I think what she is doing is looking at
the color coding for the velocity vectors or pathlines. When she sees that there are very few
arrows or pathlines with a green color (indicating 'in plane' or flat horizontal flow in the layer)
she gets concerned for some reason. Most likely the lack of 'in plane' flow has very little to do
with anything she is concerned about, it just reflects the fact that she has slight vertical gradients
in the model.
WRT to the vanishing concentrations, you could also suggest her to make sure she didn't input a
default degradation rate of 0.5 or something very high and then forgot about it, or the other
possibility is she has assigned a sorption coefficient of 1 (mistaking it for a retardation
coefficient), or perhaps just a very large sorption coefficient of 0.01 L/mg which would cause
the plume not to move at all, thus giving the impression that it is disappearing from the model,
when in fact it hasn't moved at all. Another possibility is that she initially assigned nonconservative values of sorption and decay coefficients when she set up the transport model
scenario, and she is now trying to modify these values in the Setup/Transport Engine dialog
instead of in the Input mode (I've seen this problem a few times) or Visual MODFLOW.
Finally, the fact that the solution solves in two iterations seems to indicate that the total run time
of the MT3DMS solution may have been left as the default of 1 day (perhaps she assumed it
automatically picks up the end time of the flow simulation). She can change this by selecting
Run/MT3DMS/Output Times and entering the desired Simulation Time.
* The simplest way of defining a starting concentration is to use the Recharge Coverage and
specify a polygon shape that denotes the contaminant concentration to be applied to the model.
* What to do when your contaminant plume does not migrate as expected.
When using MT3D or RT3D for a contaminant transport simulation, if the plume fails to move
as expected (or does not appear at all in your Visual MODFLOW output), here are a few
common causes and their solutions.
Problem #1: Overlay is not active, or masked by another overlay
Solution #1: As with Head Equipotentials, Particles, and even Base maps and other overlays,
you must make the Concentration overlay active in order to see it. Click the F9-Overlay button
at the bottom of your screen, and ensure the overlay has been checked off (to make it active). It
is also possible that other overlays are masking your concentrations. To resolve this, change the
Overlay Order setting to User Defined, then highlight the Concentration overlay, and use the
arrow buttons to move it up the list.

Problem #2: Simulation Output time

Solution #2: In Visual MODFLOW, the Simulation Output time can be different for your flow
and transport simulations. Check to see that you have defined the correct simulation time(s) in
the Run Menu, by selecting MT3D (or RT3D) / Output - Time Steps. Additionally, in the Output
Menu of Visual MODFLOW, ensure that you have selected the Concentration overlay as the
active overlay, then select the Time button in the left toolbar, to change output times as desired.
Problem #3: No concentration input assigned, or not assigned properly
Solution #3: Ensure that you have correctly defined at least one cell with an Initial
Concentration, or a transport boundary condition of one of the following types: Constant
Concentration, Recharge Concentration, Evapotranspiration Concentration, or Point Source.
Please NOTE that Concentration values entered for Concentration Observation Wells are used
for calibration purposes only; they do not contribute mass to a transport simulation.
Problem #4: Inadequate flow gradient
Solution #4: Before running your transport simulation, run just the flow simulation
(MODFLOW). Using Pathlines or Velocity Vectors, ensure that there is a sufficient flow
gradient to cause plume migration.
Problem #5: Incorrect reaction parameters
Solution #5: Check the reaction options in the Main Menu, by clicking on Setup / Numeric
Engines / Transport. Check that the correct Sorption and Reaction options have been selected.
First order decay rates (dissolved and sorbed phases) may have a tremendous impact on the
plume mass, since during the simulation, some contaminant mass may be removed from the
model. If the decay rate is too high, your plume will show very small concentrations, and/or will
not be visible at all at later simulation times.
Decay rates (due to biodegradation or other mass-removal processes) can be taken from
literature values, but this should be done with caution, as this parameter is highly site-specific
for most compounds. A good reference on decay rates used in natural attenuation studies can be
found in:
Wiedemeier et al., 1999: Technical Protocol for Implementing the Intrinsic Remediation with
Long-Term Monitoring Option for Natural Attenuation of Dissolved Phase Fuel Contamination
in Ground Water. Air Force Center for Environmental Excellence, Brooks, AFB.
This document can be downloaded from:
http://www.afcee.brooks.af.mil/products/techtrans/monitorednaturalattenuation/protocols.asp
The decay rate (l, or sometimes called Kd, with units of 1/day), is typically obtained from halflife values, converted into appropriate units using the following relationship:
l = ln(2)/t1/2
Where t1/2 = half-life of the compound

In addition, check that your Kd value is correctly defined in the Species Parameters tab. A very
large Kd value will result in an extremely high retardation factor, which can result in lack of
contaminant movement through your model.
For typical organic compounds (such as TCE, DCE, PCE, BTEX, etc.) where linear, reversible
sorption can be assumed, retardation will be calculated using the following formula:
Retardation = 1+ (Bulk Density/porosity)*(Kd)
Where Kd = Partition coefficient
For hydrophobic organics, Kd can be determined using the relationship below:
Kd = Koc*foc
Koc - octanol-carbon coefficient
foc - organic carbon fraction in the aquifer
A more detailed overview on Kd's can be found in:
US-EPA, 1999. Understanding variation in Partition Coefficient, Kd, values. EPA
402-R-99-004A&B. US-EPA Office of Air and Radiation.
This document can be downloaded from:
http://www.epa.gov/radiation/cleanup/partition.htm
* From the Modflow standpoint, water that exits the GW system through of a drain cell is
accounted for in the budget, but is otherwise not simulated. The situation for river cells is
similar--Modflow does not simulate any flow in the river, it only simulates exchange between
the GW system and each individual river cell. So there is no way to route water from a drain
cell to a river. The Streamflow Routing (STR) Package, on the other hand, does simulate flow
in surface-water streams, accounting for flow rates in the stream and calculating stream stage,
which is then used as the external head in the GW/SW exchange calculation. If you want to
simulate exchange between drains and rivers, you could use the STR Package for both types of
features.
* How to import modflow model files to gw vistas 4?
Select File/New and click the MODFLOW button. On the next dialog, click browse to go find
the name file (*.nam). If this is an older MODFLOW88 dataset, then browse to find the *.bas
file. Some datasets (especially those that were created without the use of a preprocessor) can be
troublesome.
* I want to input separately 2 sets of recharge into a modflow model: (1) Effective recharge from
rainfall, and (2) urban leakage (same format as the (1)), which will overlap. Since both
components are fairly complex and over a long time (1200 Stress Periods), I would like to keep
them as independent as possible (avoiding the data compilation option, if you see what I mean).
It is possible to do what you want using just the Recharge package. Here is how you do it.
Define each recharge distribution for each stress period using parameters. You can use one set of
parameters for the rainfall and another for the urban leakage. With each parameter, you can use
multiplier arrays and zone arrays to define the spatial distribution of the recharge. Then, for

each stress period, use the parameters for that stress period to apply recharge from both rainfall
and urban leakage. MODFLOW-2000 will add the contributions from all the parameters you
use in a stress period to determine the total recharge.
You should be able to do this with any reasonably up-to-date GUI for MODFLOW-2000. If you
are using a GUI and you can't figure out how to do this, contact the GUI developer for
assistance. If you aren't using a GUI, you can check the input format in the Online Guide for
MODFLOW-2000 at http://water.usgs.gov/nrp/gwsoftware/modflow2000/MFDOC/guide.html
or in the original MODFLOW documentation as modified in "Time-varying-parameters.pdf"
(distributed with MODFLOW-2000).
* Since I know you are using Modflow VKD (based on MF96, not MF2K) and that the wells
package is almost certainly being used for many abstraction wells, I suggest 2 routes:
1. A FORTRAN utility to combine two recharge files - a days work? 2. To use a MF package
that you aren't already using - but with some manipulation e.g. the rivers package. By setting the
stage of the river as above any elevation in the model (1000m?) and the conductance equal to the
quantity you want to recharge for that SP - with a 1 m difference between stage and bottom
elevation you will get the appropriate amount leaking (recharge) to each cell.
You can achieve the same result with the drains package by specifying 2 drains in each cell. The
trick is to have one with a positive conductance and the other negative, but the same value.
Make the difference in elevation 1m and the magnitude of the two conductance values the
quantity you want to leak/abstract. If the elevation is outside the range of variation in the model,
you end up with a constant recharge/abstraction from the model.
For composite/trick boundary conditions of this type I suggest drawing figures for them like
those in the MF88 book, it will help to understand what I'm trying to say.
* Design the shoreline?
Depending if you are using FEMWATER or MODFLOW, it is handled differently. With
FEMWATER, you want the boundary of your 3D mesh to follow the shoreline. With
MODFLOW, you are working with a 3D grid. So, you need to mark the cells that contain the
shoreline with a fixed head boundary condition, and the cells outside this area will be disabled.
If you are attempting to model the interaction with the sea bed, then you will need to set the top
elevations of the mesh or grid to match that of the sea bed. However, generally you end your
model at the shoreline.
* MT3D Performance
What you need most depends on where your bottle-neck occurs. You need to monitor CPU and
RAM usage on the computer during the MT3D run. If you run Windows 2000 or XP, you can
right click (for a right-handed pointing device) on the Taskbar (grey bar at bottom of screen),
then select Task Manager in the menu pop-up. Once Windows Task Manager opens, select the
tab labeled "Performance". "Performance" shows CPU usage graphically and memory usage in
numeric form. If the "CPU Usage History" (top graph) stays maxed at 100%, then a CPU speed
increase should help. In parallel, observe the "Physical Memory" values. If the "Available" value
becomes a small fraction of the "Total", AND the "Commit Charge, Total" exceeds the
"Physical Memory, Total" then you are likely to have a RAM-limited condition. In this case,
more RAM would help. With 300,000 cells, consider 1 Gbyte or more. If both things are
happening (unlikely), then upgrading CPU and RAM should help. Be aware that upgrading one
component sometimes results in the other becoming the limiting condition. That is why it is

"unlikely" both limits are happening simultaneously. Usually one tops out before the other. If
you run Win98... consider upgrading the OS.
* There are various things that you have to do to get Surfact running in Vista 3:
1. You can only have a limited number of packages. For example, if you are doing contaminant
transport modelling then you have to turn some other packages off, otherwise Surfact will not
run e.g. you can turn the cell by cell flow packages off (just type 0 into the packages number in
Model - Modflow - Packages). Another pace you can turn packages off is in the output control:
Turn off the drawdown unit.
2. You have to modify some things in the Model - Modflow options and some in the Modflow Surfact options. These are:
Model - Modflow - Packages: change modflow version to surfact; change solver to PCG4; and
untick automatically reset package units
Model - Modflow - BCF package: tick the box to use the BCF4 package
Model - Surfact - Packages: add a unit number (one that you have not yet used) and tick the box
for BCF4; add the unit number to PCG4 and tick the box (use same unit number as shown in
Model - Modflow- Packages); add a unit number and tick box to RSF4 is you want the model to
simulate surface seepages (and remember to turn this unit on in Model - Surfact - RSF4
package).
Model - Paths to models: set modflowwin32 option to DO NOT USE; put in correct path for
surfact in the modflow box.
I can't think of anything else right now - I always forget one thing and spend a couple of hours
wondering why surfact won't run. If you have any difficulties it would be helpful to know if the
surfact Dos window displays and if so, what it says in the window.
* The most common problem when using SURFACT is setting up the program file. Select
Model/Paths to Models. Change the MODFLOWwin32 Option at the top to "do not use". That
tells Vistas that you are not using one of our model DLLs. Then change the MODFLOW
program from MFWIN32.DLL to whatever your SURFACT program is (usually it is msft.exe).
* I believe that if you are using the latest version of SURFACT (V2.2) that problem 1. below is
no longer an issue. It used to be that SURFACT could only open a limited number of files but
that is no longer the case. Also, if you upgrade to Vistas Version 4 and SURFACT V2.2 the link
between the two programs is easier to establish. The same holds true for all of the other versions
of MODFLOW that Vistas supports (MODFLOW88, MODFLOW96 in double precision,
MODFLOW2000, MODFLOWT, MODFLOW-SURFACT, SEAWAT, and SEAWAT2000).
* VS2DI or VS2DT, being a Richards equation-based models have certain PROs and CONs
when used for groundwater recharge estimation:
Pros: the Richards equation models are the most theoretically based and allow representation of
the flow processes in porous mediums more realistically than the water-balance models. They
have been well tested against field and laboratory experiments and proved to provide good
correlation with observed results.
Cons: the major complicity of the Richards equation, comparing to the saturated flow models, is
that its coefficients are non-linear functions of the pressure potential. To approximate these

functions, three different algebraic equations are usually used (named after their authors):
Brooks and Corey's, Gardner's, and van Genuchten's. Richards equation can be solved with a
very limited number of boundary conditions. The condition for water at the boundary can be
specified either as the flux of water across the boundary, the head at the boundary or as a
combination of specified head and specified flux. The Richards equation with these boundary
conditions is a nonlinear partial difference equation that has no close-form or analytical solution.
To solve the Richards equation, a finite-difference method of numerical approximation is
applied in VS2DI. Searching for a best numerical method for the Richards equation became a
special field in hydrologic science, particularly in 1980's, however, almost all implemented
approaches cannot assure that the model will unconditionally converge and simulation results
will be obtained. It is an art to get the model to work correctly (produce results for the whole
simulation period with a good water balance) when you have varying flow boundary conditions
in your profile. Our experience also proved that applications of Richards equation-based models
to highly heterogeneous soils with variable hydraulic properties can be extremely difficult to
execute and time consuming.
These days there more and more examples when less sophisticated in flow equation but much
more advanced in terms of weather/plant effects water-balance model HELP is used to estimate
groundwater recharge.
* I will suggest you keep the north and south boundary as variable head boundary. This I am
suggesting you treating there is no river, lake etc. If these features are present on north or south
side of model domain, then you have look for another type of boundary. Regarding limited
observation well data and that too is limited to layer1, then it will not be possible to do any
realistic modelling. If there is no scope of generating additional data, i would like to suggest that
you confine your modelling activity to first layer only.
* What makes a good correlation depends on what your expectations are. If you are conducting
exploratory research, maybe 0.2 isnt bad. If you are testing a known process having some
natural variability, 0.6 might be acceptable. But if you are calibrating instruments, maybe 0.9
isnt good enough.
If you dont have any clear expectations, how do you tell if a correlation is good? The answer
comes in three parts.
1. Value - Square the correlation coefficient (called the coefficient of determination or just Rsquare). R-square is the proportion of variation in the dependent variable (y) that can be
accounted for by the independent variable (x). You might be able to decide how good your
correlation is from a gut feel for how much of the variability you wanted your model to account
for.
2. Significance - Every calculated correlation coefficient is an estimate. The real value may
be somewhat more or somewhat less. You can conduct a statistical test to determine if the
correlation you calculated is different from zero (or some other number if its relevant). The
larger the calculated correlation and the greater the number of samples, the more likely the
correlation will be significantly different from zero. For example, a correlation of 0.59 (Rsquare of 0.35) would be significantly greater than zero based on about 25 samples, but a
correlation of 0.01 wouldnt be significant with 250 samples.
3. Plots - You should always plot the data used to calculate a correlation to ensure that the
coefficient adequately represents the relationship. Specifically, the data should be linearly
related and free of outliers. There are a few other things to look for (e.g., hidden trends, autocorrelation) that I wont go into here.

So, the reviewer who said that the "R square" value of 0.35 has no significance and is just as
good or as bad as say 0.01 would only be correct if she looked at a statistical test of whether the
value was significantly different from zero. R square does not need to be more than any
particular value to draw a comparison. Remember, too, that no relationship may also be an
important finding.
* If you are considering GUI's for your project, you may want to look at Visual MODFLOW
Pro. In particular, if cell splitting, or grid refinement is an issue for you. Visual MODFLOW
includes two distinct features that help users with this.
1) Cell refinement tool
2) Grid smoothing tool
1) Cell refinement/splitting tool: You'll need no more than a few clicks to edit your grid in a
very flexible manner. To split your cells, just click on 'Refine by ...", and specify how many
times you want the cell to be split into (2, 3, 4...). Then, select the area you need to refine with
your mouse.You can apply this to one row or column, or all cells in the domain - whatever you
wish. The same applies for splitting layers and coarsening the grid.
2) Grid smoothing tool: After grid refinement, you may want to use the grid smoothing routine
to produce a smooth transition between coarser areas to highly discretized ones. Again, just a
few clicks. This is actually a perfect tool to help you better understand the effects grid size and
refinement will have on your model results.
Another feature that may be useful for you is Visual MODFLOW Pro's batch capabilities. It
will allow you to prepare all data input files in different model projects and run them in 'batch
mode'.
* The interpretation method is different according to the geology. You have methods for porous
media, others for fissured aquifer, others for double porosity media. Methods also vary
according to the type of aquifer (confined or unconfined; semi-confined with a leaky aquifer...)
and corrections can be made according to the type of well (partially penetrating well; pumping
well with head loss; skin effect and so on). Finally, boundary effects (barrier or recharge) may
affect significantly your interpretation.
In order to remain pragmatic I would suggest you to start with the simplest method : the Theis
formula, (or even the Jacob approximation if your pumping time is big enough) and check
wether you get a good fit or not with realistic parameters. Even a fissured unconfined aquifer
can be interpreted with Theis when your radius of influence is wide so that the fissure network
can be assimilated to an homogeneous equivalent porous media and the depletion of the water
level is moderate compared to the thickness of the aquifer. This should give you a rough
estimate of your transmissivity, which is in many cases, sufficient.
If you need more accuracy you can use specific softwares. You will find on the net many
softwares proposing many different methods. You don't need Pest as they have their own fitting
engine. AQTESOLV for instance proposes methods with well storage effect. However, as soon
as a software proposes its own adjustment, it's becoming very difficult to know what's you're
doing and you end up playing a video game. So be careful, especially if you lack experience in
this domain, not to use complex methods with many parameters which will end in a perfect fit
but with irrealistic results. In my company (French geological survey)we use ISAPE, a software
which is no more commercialised, but whose philosophy is to let the user propose realistic
values and where you can add or remove well effects or boundary influence. I wish this
approach were more widespread.

* I think your scenario will represent two different geologic materials with peculiar intrinsic
properties. Hence, I suppose this will require two separate simulations. To the best of my
knowledge, MODFLOW 2000 only allow one K matrix values per layer per simulation and this
is incorporated within the flow package. However, if the introduction of the permeable barrier is
controlled along defined specific paths or unique relatively smaller area(s), then you can use one
simulation with two stress periods and incorporate Horizontal Flow Barrier Package in the
second period to account for the permeable barrier distribution. This is not suppose to be of
much problem especially if you incorporate your modflow with GIS package like GRASS GIS.
* Sophisticated modeling programs like Visual Modflow Pro, or any of a number of similar
packages, will run properly with a variety of inputs that may not be physically realistic - and
thus provide garbage for output. With that in mind, here are some thoughts on your questions:
1) You may divide a single aquifer into more than one layer if there is some reason to look at
vertical stratification within the aquifer. For example, a thick aquifer may have different
hydraulic or transport properties in different vertical zones. You may also divide a single
aquifer into several layers if you want to examine the vertical flow patterns due to pumping from
different zones within the aquifer.
2) The top of Layer 1 could be the ground surface, the water table (not as common because it
can move vertically), or the top of the uppermost aquifer or aquitard of interest depending on the
physical system being modeled.
3) You'll need to assign boundary conditions no matter what the size of the physical system is.
If you don't have natural physical boundaries, one strategy is to assign boundary conditions at a
distance far enough away from the area of interest to minimize the effects of boundary
assumptions on the solution.
* It is appropriate to use a single layer if you feel that it is reasonable to ignore vertical flow in
your model. Assuming that you would be using the Layer Property Flow (LPF) Package of
Modflow-2000, and if the aquifer represented by layer 1 is not overlain by a confining unit, then
specifying the top of layer 1 as ground surface is reasonable. The reason that you would be
better off this way than specifying the water table elevation as the layer top is that the LPF
Package only provides two options with respect to the confined/unconfined status of a layer:
Confined or Convertible. If the head in a cell goes above the specified top of a convertible layer,
the cell is treated as confined. Every model needs to have at least one fixed head, either as a
constant-head cell or as a fixed external head (such as the stage at a river cell), or the solver will
not be able to reach a solution. You may need to expand the domain of your problem to
encompass a fixed head.
* 1- Model design depends greatly on your project goals. For example, you could have one
aquifer, but an overlying layer (and/or underlying layer) as well. Or, you could be modelling just
1 aquifer, but split it up into several layers in VMOD to provide more detailed flow information
(i.e. if the aquifer is 100 feet thick, having just 1 layer will not provide very detailed output. You
can subdivide the 1 "real-world" layer into 10 "model" layers, all with the same hydrological
properties, in order to obtain more detailed output). Or, you can simply design a 1-layer model if
that is all your project requires.
2- In Visual MODFLOW, Layer 1 represents the uppermost layer of your profile, and the top of
Layer 1 is therefore the ground surface. Layers in Visual MODFLOW represent soil layers (or
conceptual soil layers)....the location of groundwater in these layers is determined by your model
inputs, and the resulting calculations of the flow model.

3- The assignment of boundary conditions is a question that often goes beyond the scope of
Technical Support, and enters the realm of Extended Modeling Support. However, to provide
you with some guidelines:
-If you have no "obvious" water inputs (streams, rivers, lakes, injection wells, recharge from
rainfall, etc.), you can try assigning an upgradient equipotential line, and downgradient
equipotential line, using Constant Head Cells at the upgradient and downgradient edges of your
model, to represent the regional water table (other boundaries may be more appropriate,
depending on your specific model domain and objectives). You can then add additional inputs
(extraction wells, contaminant sources, etc.) to the model region, which will be influenced by
your regional flow gradient.
4- I would recommend taking some time to run through the Tutorials included with your Visual
MODFLOW software (the PDF instruction files are located on your installation CD-ROM, and
the files are automatically copied to the Tutorial subfolder in your Visual MODFLOW program
folder). These tutorials are designed to teach you how to work with your software, and how to
design a model, import data for model inputs, run the various packages, calibrate your model,
examine your output in 2D and 3D, and export data.
* You can use the field interpolator program in the PMWIN package. Using the field
interpolator you can interpolate the field data in txt file to the grid point of your model. On the
other hand, you can import any dxf file which illustrate the changes in hydraulic properties to
help you in the graphical interface.
* Upwind discretization always has an artificial diffusion term no mater how refined your grid is
(even thought it diminishes with grid refinement). Central discretization always produces an
artificial dispersion term that causes "wigles" however you can't control it with grid refinement.
For almost any Pellet number the upwind scheme will produce positive coefficients for your
coefficient matrix, while that isn't true for central differences. However central differences has
"second order accuracy" while upwind only has first order. You can visualize numerical
diffusion and dispersion mathematically by deriving the "equivalent or modified equation" see
http://widget.ecn.purdue.edu/~jmurthy/me608/main.pdf for some cool notes on this (as good as
any book I've read).
Physically you can visualize numerical diffusion by imagining a 1D discretization of a domain |
: | : | : | where | are faces and : is the center of the cells.
If your initial property is 1 on a given cell say i and 0 on all others it would look like this:
|0|0|0|0|1|0|0|0|0
So using upwind with a courant = v dt / dx of say 0.5 and a velocity from left to right after the
first time step the accurate solution would be something like (zooming on cell i):
| 0 { 0.5 | 0.5 } 0 |
Note that I have created a new cell delimited by the {} brackets this "new cell" that doesn't exist
in our domain is exactly half of cell i and alf of cell i+1. The property's value will be 0.5 inside
this new cell and 0 outside it (meaning that cell i and i+1 would have half with 0.5 and half with
0). This would be the accurate solution because a courant of 0.5 makes the property shift half a
cell every time step. However we are bounded to our initial discretization so the solution we will
obtain will be:
| 0 | 0.5 | 0.5 |

so you can see than instead of having a 0.5 of property in a volume the size of a cell we have 0.5
in a volume the size of 2 cell thus lowering the concentration. This happened because the
definition of concentration is C = lim vol ->0 DM/DVOL and we implemented it as DM/DVOL.
If we would diminish the size of our grid so that currant = 1 we could obtain the exact solution.
So the smaller your grid is the more accurate your solution will be. This is the physically correct
way of solving the diffusion problem another way is to use higher order schemes witch usually
maintain the sharpness of the gradients but usually remove mass from all the wrong places (even
thought they conserve it). Looking at the same example a central differences discretization
would derive something like:
| -0.25 | 0.75 | 0.25 |
Cell i-1 will produce a negative property because the concentration al the face between i-1 and i
is 0.5 cell i +1 will obtain the accurate concentration of 0.25 (0.5 in half the volume of a cell).
But we are producing the famous "wigles" close to the properties gradient. There are smarter
second order schemes like qwick or TVD schemes.
* In visual MODFLOW there is provision for importing MODFLOW files (*.bas files). In
PMWin there is provision for conversion of MODFLOW88/96 (*.nam). I have tried to import
*.bas file in Visual MODFLOW and found that model data is not correctly coming to model.
These options may be available in GMS but I am unable to locate the exact sub-menu. Number
of options is available for opening different format files In the FILE menu. But It does not
permit opening of *.bas or *.nam files. This option must be in different menu.
* To clarify the capabilities of Visual MODFLOW, the latest version (Version 4.0.0, released in
April of 2004) is capable of importing any MODFLOW-based model. The import capabilities
have been significantly enhanced since the release of Version 2.8.2 in 1999. The Version 4.0
User's Manual contains a detailed description of how to convert an older MODFLOW-88 or
MODFLOW-96 model to MODFLOW-2000 format (using the USGS MF96TO2K program),
then import the MODFLOW-2000 model directly into Visual MODFLOW.
Although previous versions of Visual MODFLOW were able to import existing MODFLOW
data sets, the import process often ignored important data such as Specific Storage and Specific
Yield values, and it was not able to accommodate quasi 3D models containing implicitly
represented aquitards. Visual MODFLOW 4.0 has a significantly improved importing process
that supports both MODFLOW-2000 Groundwater Process data sets, and older data sets from
MODFLOW-96 and MODFLOW-88. This process utilizes a modified version of the USGS
utility (MF962MF2K.EXE) to convert MODFLOW-96 and MODFLOW-88 data sets to
MODFLOW-2000 data sets, and then imports the MODFLOW-2000 data set into the Visual
MODFLOW graphical environment.
* Unfortunately, Version 3.1 was limited to DXF and BMP file formats. However, Version 4.0
released early in 2004 includes the following import possibilities. Plus, Version 4 also includes
a handy layer management feature so you can adjust layer sequencing easily.
- DXF
- BMP
- SHP
- GIF
- JPG
- PNG

In terms of animating your heads, you can also do this using the built-in VMOD 3D-Explorer
(part of Visual MODFLOW Pro).
* You are write in pointing out that in Visual Modflow only DXF and BMP files can be
imported as base map. Even in latest version Visual Modflow Pro 4.0 other than DXF and BMP
import is not possible. I would suggest you that try to reduce the depth of BMP or save the
original base in monochrome or less colour depth (grey scale). This will reduce your size of file
considerably. This will also help you fast operation of the programme. You may import Visual
Modflow generated heads to GMS. You import the super model file from open menu in GMS
4.0.
* My suggestion would be to read the model directly into GMS. GMS supports multiple formats
for image display (including the format that you have) and you can perform the animations like
you need to.
* The latest version of Visual MODFLOW 4.0 actually supports much more than BMP and
DXF files.
For example...
- DXF
- BMP
- SHP
- GIF
- JPG
- PNG
* 1) If you have a point source boundary condition assigned to an injection well, the
concentration of contaminant in the injected water remains constant, however the volume of
water being injected into your flow model relates directly to the pumping rate. Therefore, the
total volume of contaminant being added to the model also varies directly with the pumping rate
assigned to the injection well.
Therefore, I would anticipate that your model would react as you have indicated (reducing the
injection rate results in a lower detected concentration level at your observation well) due to
dispersion of a smaller volume of contaminant over the same area.
2) The following is an overview of the solution methods from the head of our Software
department:
Numerical dispersion and oscillations depend on a number of factors such as grid discretization,
time step size, and solution method. Typically, when a solver is oscillation-free, such as
Upstream Finite Differences (UFD), it is prone to high numerical dispersion.
What you have described sounds like a typical breakthrough curve obtained by MOC. MOC can
have mass balance issues, and I strongly suggest you look into mass balance errors before trying
to reach any conclusions. A high mass balance error makes it very difficult to rely on the output
data.
There is no such thing as a "best solver" for all transport model cases. In order to determine
which solver to use, you need to understand what the dominant transport process is in your
project area (i.e. advection or dispersion). This is estimated by determining the Peclet Number
(see the MT3D PDF Manual located in the Manual folder of your Visual MODFLOW
installation CD-ROM for details). Pe (after some simplifying assumptions for most cases) is
roughly equal to cell length/longitudinal dispersivity. So, if your dispersivity is 10m and your

cell length is 20m, your Pe=20/10 = 2. It is easy to see that large grid cells and small
dispersivities will produce large Pe Numbers.
For Peclet numbers that are smaller then 2, dispersion is the dominant process and finite
differences (UFD) will work fine. For Peclet numbers larger than 10, advection dominates and
MOC is a good option. TVD is a very good option in both cases. Every solver has pros and cons.
Some are faster (e.g.: UFD, implicit in time) some are slower (MOC, explicit UFD). Some are
more prone to numerical dispersion, but are oscillation-free (UFD, MMOC). Some are the
opposite (Central-in-space Finite Differences, MOC, HMOC). TVD seems to be the most
flexible solver available in MT3D. It does not typically present numerical dispersion nor
oscillation, but is slower than Implicit UFD). Sounds confusing? I suggest Dr. Chunmiao
Zheng's book on contaminant transport, a must read if working with MT3D.
What we suggest in our courses is to use Implicit UFD in the early stages of the modeling
project, and check results with TVD or MOC at the end. We then use Implicit UFD, TVD, or
MOC for final simulations, depending on the results of initial simulations and objectives of the
modeling project. We don't recommend using central-in-space finite differences in general,
because it can produce oscillations that are difficult to overcome. However, it does not present
numerical dispersion.
To avoid the discrepancies your are describing, you could try using TVD (with Cholesky preconditioning) or Upstream Finite Differences (UFD) which is faster, but subject to numerical
dispersion.
A final note on grid size. The effects of numerical dispersion can be reduced by increasing your
grid discretization (i.e. use smaller cells where contamination is being simulated). Actually, the
grid cell size can be calculated using the Peclet Number. For example, if you want to use finite
differences, make sure your grid size is small enough to achieve a Peclet that is smaller than 2.
* The PEST program (developed by John Doherty) is a Parameter Estimation tool that can be
used to optimize model parameters based on field observation data. Visual PEST is a graphical
interface to the PEST program, and WINPEST is the Visual MODFLOW interface for PEST.
* If you are looking for a GUI independent calibration tool, you can try Visual PEST-ASP. This
version of PEST-ASP actually includes a user-friendly GUI and will allow you to automatically
calibrate a complete range of parameters from your groundwater model. If you are using Visual
MODFLOW, you can use an add-on program called WinPEST. This is a fully integrated version
of PEST. Since it is part of the Visual MODFLOW GUI, calibrate parameters such as hydraulic
conductivity is really quick and easy.
* You will not be able to import *.vmf directly. You go file menu of GMS then click open submenu, then you search *.bas file in directory containing simulation made in visual modflow.
You can import basic files of Visual Modflow directly into GMS.
* I am guessing that the counting of the cells you want to do is for the estimation of the water
logged area? If that's the case than you could quickly get this area using the following
procedure: Save the simulation result you are using as a matrix file. In Search and Modify
change the values in this matrix to integers. (For instance if you are interested in the area of the
cells with values in the range of between 0 and -1 and nothing else than modify all these values
to 1 and all the remaining values to 0.) - save this matrix as a separate file.
Use program "Zone2dxf.exe" from John Doherty's set of "Groundwater Utilities" to create a dxf
file with contours of the 0 to -1 zone. I think you can get Utilities from the internet. If not
contact me directly. Use Autocad (or any other program that can calculate polygon areas) area

function/option to calculate the area of the polygon. All this can be done within just a couple
minutes.
* The RMS error is one method of judging calibration and you can not assume with RMS error
that your model is calibrated. It is related to only obs. and cal. head. Normally in Visual
Modflow 5-10 % RMS error is acceptable. You will find two parallel line above and below the
45 degree (i.e. 100 percent fit line) in visual modflow obs and cal. head display. I am not sure
but It looks to me that you model is producing more than 60 % error. All depends on your target.
I will suggest that you must modify your parameters so that you may able to minimize your dry
cells in model.
* I am using visual modflow for contaminant transport. while running the model i get error
message as below : ERROR: MAXIMUM NUMBER OF PARTICLES ALLOWED
[MXPART] IS 1000000 ACTUAL NUMBER OF PARTICLES NEEDED AT THIS POINT
1000004 INCREASE VALUE OF [MXPART] IN ADVECTION INPUT FILE ERROR:
MAXIMUM NUMBER OF PARTICLES ALLOWED [MXPART] IS 1000000. I have already
assigned maximum number of particles that could be assigned but still i get that error. Is there
any way to increase the number?
Try going to the Run Menu of Visual Modflow and click on the MT3D option at the top of the
screen and select Solution Method. In the Solution Method window, select the Options button
beside Advection Terms. In this window, increase the MXPART variable from 100000 to a
number greater than that specified in the error message. You may alternately reduce the "Max
particles per Cell" value from 30 to 20 or even 10 if this error continues to be a problem.
* I would like to know if I can work SEAWAT with PMWIN 5.3 Also I would like to know if
PMWIN 5.3 can be a graphical interface of SEAWAT and if so how?
Looking at SEWAT manual you can use PMWIN to prepare your data files. However, you will
have to make small modifications/adjustments to some of the input files (they are all in ASCII
text format) outside PMWIN using a text editor. Once you have done this you will have to run
SEAWAT from the DOS window. On the completion of the run you will be able to read
simulation results using PMWIN again. Remember that SEWAT will give you simulated heads
as equivalent freshwater heads. You will have to convert those to the "field" heads using a
formula shown in SEAWAT manual. This formula converts heads using simulated fresh water
heads and concentrations. Conversion will have to be done outside SEAWAT/PMWIN (e.g. in a
spreadsheet) but once it is done and saved as an matrix you will be able to read it into PMWIN
and export it from there as an image or dxf file.
* 1. Typically PEST does not have an enormous RAM requirement - if you obtain the latest
(from www.sspa.com/pest) there are a number of memory-conserving storage routines that help
reduce memory requirements. The amount of RAM PEST requires - and also the relative speed
of PEST execution at any particular CPU speed - is often a function of the number of parameters
estimated as well as the number of observations. I have estimated a couple hundred parameters
with a few thousand observations on a 3.2GHz/1MB RAM PC. However, this leads to the next
aspect; 2. The forward model itself (MODFLOW) may be the determinant for RAM - the
number of nodes you mention though is not extremely high, though the number of stress periods
is fairly unusual. Beyond a certain point you will not gain any additional speed by having
additional RAM. You can make some rough calculations of the RAM Modflow will use based
on the size of the XARRAY when dimensioned (I forget if it is actually reported in the
LST/GLO files?) 3. Finally - if you are estimating more than a handful of parameters and/or
your forward model takes more than a few minutes to execute, I would strongly recommend
using parallel PEST - I believe this comes with GMS, and if not you can get it from the same
URL as above - this enables you to run the independent parameter perturbations (and sometimes

lambda runs) on different computers in a standard PC (office environment) network, and leads to
enormous time savings. 4. I can't speak to the RAM requirements of GMS, but their help desk is
extremely responsive and helpful.
Summing up - naturally, if you can obtain a faster and bigger PC - why not(!) - but I would be
inclined to focus on the processor speed, and would not go above 2GB RAM unless there is a
very good reason to do so. And - I would use Parallel PEST for your calibration, from what I
understand of it. You can make a lot more headway with 10 computers with 2.4 GHz processors
and 1GB RAM in parallel than with one souped-up computer!
* In Version 4 of Vmod there is an export tool for every single layer surface. You can find it in
the input menu under file/export/data. Create a xyz file - choose your coordinate system and then
reimport in your transient data set.
* I am not familiar with Pmwin, but you could define head observations (and other types of
observations) as part of the Modflow-2000 input and set up the Observation Process input file
with the variable OUTNAM as something other than "NONE" to generate a series of output
files, including one with the extension "_os". This file will list the model-calculated and
observed values as well as the name you provide for each observation.
* First you check the capability of the software you are interested to use it for modelling. If
software is capable to manage the huge number (200,000 to 400,000) of cells (grids), then you
need huge hard disk space as well as RAM. But at the same time it will be very difficult to
manage the model. Your output modflow file will will more than 5 to 10GB. Opening such a
huge output file will need more RAM.
* You must first conceptualize the system. What are your boundaries? Is the system confined,
unconfined, or both? What does the potentiometric surface look like? Are there any pumpage
wells, streams, springs, or lakes within the system? Where and how does recharge occur and at
what rate? Do you have any hydraulic property measurements? What does the structure look
like? Is the system in steady-state? ... and most importantly, what is the purpose of the modeling
effort?
Once you have answers to these questions then you can begin to assess what your data needs are
or will be. You can then determine the level of descretization and begin to organize the data into
an appropriate format for model input. Then you calibrate to steady-state conditions and then to
transient if necessary. Do a sensitivity analysis of your parameters and proceed to answering the
questions being asked of the modeling effort. GW modeling is a very complicated effort which
should be avoided if there is an easier way to solve your problem.
* Waterloo Hydrogeologic, Inc. has developed a Non-Convergence Tip Sheet for Visual
MODFLOW users. Even if you are not working with Visual MODFLOW, the suggestions
contained in this Tip Sheet should be applicable to your modeling project.
* I cannot give you any definite answers based on the information you provided, but you need to
know why the cells are drying. Do they go dry due to the stresses imposed on the aquifer (this is
what I think you alluded to), or do they go dry as a result of large head changes during the
iteration process? In the former case, you can try using the Rewetting Package, but you should
first decide whether or not your conceptual model can allow for a thicker top layer. This would
be the easiest solution. If the cells are going dry due to unwidely iterations, try adjusting the seed
parameter so as to slow down the iterations.
* I assume that you are modelling only the unconfined aquifer system i.e. top aquifer. There is
no problem in selecting partially penetrated open dugwells as observation wells. Only thing you

have to see that water level in the well do not go beyond the base of the well any time in the
year.
* Partial penetration for monitoring groundwater elevations in your unconfined alluvial aquifer
should be OK. It might be a problem if you have significant vertical gradients within the
alluvial system, but that is generally not the case.
* You may try with different solver for convergence of your model. You may slightly increase
your convergence criteria if there is large season variation in head or water table. This will not
affect much in results. But without changing anything, you will able to solve your problem using
different solver. You try to change convergence criteria only if you have only one solver with
you.
* What is your mass balance in the model? If it is reasonable than try to increase your
convergence to say 0.05 or 0.1 re-run the model and check the mass balance. However, before
you do it try to run the model using different solvers (and pre-conditioning methods if using
PCG2), increase the number of iterations and try different relaxation and dumping parameters
(say between 0.9 and 1). If your mass balance keeps below say 3% than you are doing well. I
have heard the opinion that in some difficult cases mass balance as high as 10% may be
acceptable and in general below 5% is OK. You may also try different time steps and PERLEN
factor of up to 1.5. The idea is to have the very first time step, in the new stress period, quite
short as this helps to stabilize the model.
* The grid / mesh size must be the same for all layers. However, you can use no-flow cells to
activate/deactivate different areas of the model domain by each layers to more accurately
represent your lithology. This may be sufficient to meet your needs.
* You can load up to 5 maps (I use usually dxf)at once. They will be shown as a background on
all layers. You may have to switch them on and off manually if you require one particular map
shown in a particular model layer.
* The Recharge Concentration option will introduce leachate mass into the system through the
recharge flux across the uppermost wet layer of the model. As such, the concentrations you will
see in the model cells will most likely be much less than the concentrations you specify in your
recharge, but this is probably the most realistic way to approach the problem from the point of
view of getting a proper accounting of the leachate mass in the system.
The Constant Concentration option will introduce the leachate into the system assuming a
uniform specified concentration in the cell in which you assign it. If your model is discretized
finely enough, this may not be a problem, but in many cases this approach will introduce much
more solute mass into the system than is probable. However, if all you are interested in doing is
matching the observed concentrations rather than the overall mass of the constituents, this
approach may be acceptable. However, you have to be careful when using the Specified
Concentrations because you cannot turn off this boundary condition at a later time. If you want
to turn it off (so to speak) you have to set the concentration in the cell equal to zero for the stress
periods when it is off. If you try to assign it only for a portion of the overall simulation time, it
will automatically apply the final concentration for the remainder of the simulation.
If you are using a two dimensional (one layer) model and the overall mass fluxes across a
boundary are important, you will likely have to use the Recharge Concentration boundary. But
in this case you will likely have a very difficult time matching any of your observed
concentrations because the two dimensional model will effectively dilute the mass across the
entire depth of the cell.

If you are using a two dimensional (one layer) model and you are only interested in the
concentrations, then you can get away with using the Constant Concentration boundary
condition. But we aware that the concentration is uniform across the entire depth of the cell, so
you are likely significantly over-predicting the overall solute mass in the system.
In general, the same applies for three dimensional models except if you have a fine vertical
discretization at the source of the contamination. In this case it may be feasible to use a
Constant Concentration boundary condition in the cell where the leachate is being introduced to
the system.
* Transport Model Considerations Volume 2: Properties
Waterloo Hydrogeologic's Technical Support department presents the second of two articles
highlighting the Contaminant Transport component of Visual MODFLOW. Along with defining
the sources of contaminants in your model (see Volume 1: Boundary Conditions), it is important
to consider the Transport Properties of your model:
Bulk Density:
The Soil Bulk Density is used to calculate the Retardation Coefficient for each chemical species.
The Retardation Coefficient is used to calculate the 'retarded' flow velocity of each chemical
species. The retarded flow velocity is used to calculate the advective transport of each species.
The options available for customizing the Soil Bulk Density values will depend on the Transport
Engine selected for the current transport variant.
Model Parameters:
This is only available for models where RT3D is the selected Transport Engine and the Reaction
Parameters are Spatially variable (these settings are specified during the setup of the Transport
Engine). Here you can define the soil Bulk Density and other reaction parameters (decay rates,
reaction rates, yield coefficients, etc.) required for the selected Reaction model (the parameters
required for each reaction model are described in Appendix C of your Users Manual).
Species Parameters:
Here you can specify the sorption and reaction parameters used by the selected Transport
Engine. Each of the Transport Engines can handle a different set of sorption methods and
reactions, so the options for customizing the sorption and reaction parameters will depend on
which Transport Engine is selected for the current Transport Variant (see Appendix C of the
Users Manual for a summary of the available sorption options for each Transport Engine). Some
of the parameters that may need to be defined include: Distribution Coefficients (Kd), and first
order reaction rates for the dissolved phase and for the sorbed phase.
Initial Concentration:
In many cases, the historical conditions of the site are unknown, and the contaminant source has
been removed or remediated. However, the groundwater contamination is still present and the
mass transport simulation must be run forward in time, starting from the existing conditions, to
predict the potential downstream impacts. Here you can define the existing conditions
(background groundwater concentrations) of each chemical species being simulated. Initial
concentrations can be defined using the .ucn file from a previous simulation.
Dispersion:

Dispersion is a physical process that dilutes, or spreads, the contaminant mass in the X, Y and Z
directions along the advective path of the plume, reducing the solute concentration. Dispersion is
caused by the tortuosity of the flowpaths of the groundwater as it travels through the
interconnected pores of the soil. MT3D calculates the Dispersion tensor for the mass transport
model using the following parameters:
Longitudinal Dispersivity for each transport grid cell
Ratio of Horizontal to Longitudinal Dispersivity for each layer
Ratio of Vertical to Longitudinal Dispersivity for each layer
Molecular Diffusion Coefficient for each layer
* I am using visual modflow for contaminant transport. while running the model i get error
message as below : ERROR: MAXIMUM NUMBER OF PARTICLES ALLOWED
[MXPART] IS 1000000 ACTUAL NUMBER OF PARTICLES NEEDED AT THIS POINT
1000004 INCREASE VALUE OF [MXPART] IN ADVECTION INPUT FILE ERROR:
MAXIMUM NUMBER OF PARTICLES ALLOWED [MXPART] IS 1000000. I have already
assigned maximum number of particles that could be assigned but still i gt that error.
To resolve your error message: Go to the Run Menu. Click on the MT3D option at the top of
the screen and select Solution Method. In the Solution Method window, select the Options
button beside Advection Terms. In this window, increase the MXPART variable from 100000
to a number greater than that specified in the error message. You may alternately reduce the
"Max particles per Cell" value from 30 to 20 or even 10 if this error continues to be a problem.
* When first creating a model in Visual MODFLOW, you can only set uniform thickness. Once
the model has been created, you can import/assign variable elevation data from the Input Menu,
using the Grid option. Detailed information about the process of assigning/importing elevation
data is described in the Input chapter of your Visual MODFLOW user's manual.
* As usual, the best software depends on the goals of the model. Hydrus can be used to solve the
Richards unsaturated flow equation in either a 1D column or in a 2D vertical slice. Its 2D finite
element approach allows it to easily handle both vertical and lateral flow and transport in the
unsaturated zone. However, Hydrus cannot easily be used to simulate distributed nitrate
pollution across, for example, a watershed. Nor, can it be used to simulate the uptake and
interaction of nitrate pollution with vegetation or the movement of the nitrate in the groundwater
zone and/or discharge to and subsequent movement in surface water bodies.
MIKE SHE, on the other hand, assumes the unsaturated flow is purely vertical. This assumption
is reasonable in most applications, except perhaps in small scale models of a farm field with
substantial lateral flows in the unsaturated zone. MIKE SHE's strength is in its ability to
simulate the areal distribution of nitrate movement and its interaction with the other important
processes of the hydrologic cycle, including vegetation and surface water bodies (e.g.
eurtophication). If you require a more sophisticated soil-plant-agro model, MIKE SHE can be
combined with DAISY (www.agsci.kvl.dk/planteer/daisy/main.htm) in a GIS interface.
MIKE SHE is flexible framework for hydrologic modeling. It includes a full suite of pre- and
post-processing tools, plus a flexible mix of advanced and simple solution techniques for each of
the hydrologic processes. MIKE SHE covers the major processes in the hydrologic cycle and
includes process models for evapotranspiration, overland flow, unsaturated flow, groundwater
flow, and channel flow and their interactions. Each of these processes can be represented at
different levels of spatial distribution and complexity, according to the goals of the modeling
study, the availability of field data and the modeler's choices. The MIKE SHE user interface
allows you to intuitively build your model based on your conceptual model of the watershed.
The model data is specified in a variety of formats independent of the model domain and grid,

including native GIS formats. At run time, the spatial data is mapped onto the numerical grid,
which makes it easy to change the scale and spatial discretization of your model. Finally, MIKE
SHE also now includes sophisticated tools for auto-calibration and monte carlo analysis,
including distributed computing across your office network.
* A hydraulic potential loss of 800 m is obviously not realist for 10 km. I think it would be well
suited for a power plant. Please be careful with the units. When you have the right value, you
can assign heads on the boundaries of your model to get the gradient (the absolute values of
heads are not important, only the gradient is considered). You can also define your problem with
an influx of water upstream if you want. It is the same in your case. But don't forget to allow
your water to flow out of your model !
* As I know, you can delete any layer separately. It is also not possible with GMS and PMWin.
Only way out is export the dataset of different layers and then import to new model. I hope
Visual Modflow technical team is closely watching this group and they will be able to provide
more appropriate answer.
* Unfortunately there is no "simple" way to completely remove a layer. However, I will
describe the process for you. If the layer you want to remove is the bottom layer of your model,
you can simply import a new surface elevation file. For example, if your current model bottom
is at -50 meters, and you want to move it up to -30 meters, just create a text file with the
following (typical) coordinates:
0 0 -30
2000 2000 -30
Where the first line has the X and Y coordinates at the model origins plus the new elevation, and
the second line has the Y and Y coordinates at the model extents plus the new elevation. The
process for importing a surface elevation file is described in your Visual MODFLOW user's
manual. If the layer you want to remove is in the middle of your model, you would need to
remove the layer division (in cross section, select Edit Grid-Edit Layers-Delete), then use the
Move option to move all other gridlines up (to resolve the issue of "merging" 2 layers into 1),
and finally import a surface elevation file for the model bottom as described previously. Please
remember that you need to make sure any boundary condition/well screen/layer property data is
correctly modified to reflect the changes in layer surfaces.
* The analytical solution assumes an infinite domain while MODFLOW simulation is always
finite. That said MODFLOW can be set up to represent a quasi infinite domain using appropriate
boundary conditions and model grids.
* There are a number of approaches you can take for modelling groundwater flow in fractured
rocks. The choice depends on factors such as what you are trying to get out of the modelling and
availability of data.
1. Equivalent porous medium (EPM) approach. In other words, ignore the fractures and treat the
rock as a continuum with average "whole rock" hydraulic properties. If you haven't got much
data on the fractures then this is probably the best approach and can be done using MODFLOW
or FEMWATER within GMS. Drawbacks are that the EPM properties may be scale dependent
(the larger the area you look at, the more large but rare fractures you encounter). Also,
averaging may work for flow, but not for contaminant transport.
2. Discrete fracture representation. If you know where your fractures are then they can be
simulated. If you have a regular, orthogonal distribution then you can use MODFLOW, if not

then FEMWATER. The permeability of the fractures can be related to the aperture width. May
have some stability problems due to the heterogeneity of the grid.
3. Stochastic fracture modelling. If you have lots and lots of data on your fracture distribution
then you can take a stochastic approach. You need to build up probability density functions
(PDF's) for fracture aperture size, fracture spacing and fracture orientation. You then use the
same PDF's to stochastically build your fracture grid. Run the model in a Monte Carlo fashion
with many different fracture patterns. Each will provide a different result but will be
probabilistically correct. Present your results also as PDF's. This will require specialist
software, such as FRACMAN, or others.
* There is no best baseflow separation technique. There are some which separate only the lower,
slow part of the hydrograph, others which separate a good part of the peaks as baseflow. The
HYSEP methods belong to the second category, leading to high BFIs. For the first one you
could simply pick for every month of your time series the lowest discharge value. The time
series built using these low-flow values is a slow baseflow line. If you want to play around, use
the Digital Filter method (Nathan and McMahon 1990 WRR), which has a simple iterative
formula with coefficients that you can change.
Baseflow separation methods are not only subjective. They are simply restricted to the
information contained in the discharge hydrograph. There are a lot of modelling results showing
that you cannot determine a unique solution for the groundwater discharge based on the
hydrograph alone. So there is a fundamental weakness here, no best method is possible.
* The analytical solution assumes an infinite domain while MODFLOW simulation is always
finite. That said MODFLOW can be set up to represent a quasi infinite domain using appropriate
boundary conditions and model grids.
* MODFLOW calculates the "average" hydraulic head in each cell at each time step. It then
calculates the drawdown by subtracting the head in each cell from the starting head for that cell.
Your hand calculation and the calculations performed by typical aquifer-test software will
calculate the drawdown at the exact point of interest, not a finite-difference cell with some
dimensions around that point. The drawdown in MODFLOW is thus an average value for the
cell that contains the point at 500 meters from the well, and will usually be less than the value
you would calculate for the exact point of interest. The difference between the hand calculation
and the MODFLOW result will become less as the cell size becomes smaller, but in general the
two methods will never agree with precisely the same calculated drawdown.
* This is easy to answer as many users probably will. Modflow calculates AVERAGE
drawdown (and head, and other values such as concentrations) for one whole cell. If "your" 500
m distance from the pumped well is somewhere in a cell of large area, the average for the cell
will not be the same as for the point exactly 500m away.
Advice: if you need better precision than average for an area, make the grid finer near the point
of interest. Thus you will reduce the size of the cell and averaging will be closer to your
expectations. Again, you are right in your calculation (1.24 m), but only if the whole aquifer
satisfies Theis conditions (homogeneous, horizontal, that is one value of T and Sy for the whole
model, infinite extent, etc.).
* In Visual MODFLOW you can assign Zone Budget zones for areas of interest. So, you may
assign a Zone Budget zone to your drain and another zone or zones to the areas your water is
coming from and discharges to the drain. When you run the model be sure to check the Zone
Budget option in the Engines to Run pop-up window. In the Output module you may than go to
Maps/Zone Budget and select Zone Budget from the left menu. Here you will have listed all the

flows (inflows and outflows) for the selected zone in a given stress period, time step or model
time.
* The .FLO file (which contains Cell by Cell flow terms) is not a readable file. To create a
readable output file, go to your Run Menu, and click on Modflow-Output Control. In the Output
Control window, check off all boxes under Print to LST. The LST file is an ASCII file that can
be read with Notepad. Run your model and view the LST file. NOTE: This will ONLY
produce flow terms for Boundary Condition cells. If you are interested in flow terms for
"regular cells" you can assign ZoneBudget Zones to those cells of interest.
* Your lowest model layer has its base set as a no flow (impervious) boundary by default. If you
want for, whatever reason, introduce another impermeable boundary between layers inside the
model you can set VCONT in the upper layer to a very low value (say 1e-8), which will
effectively separate your model into two independent sub-models. However, I do not think it
would be a good idea and in this case it would be probably better to build two independent
models.
* There is no need to explicitly assign a bottom-most layer as totally impervious. By default, all
boundaries on the exterior of the MODFLOW model grid are simulated as no-flow.
* You can not directly insert a new layer, you have to divide any one layer into two layer, and
re-assign the elevation.
* MODFLOW is a saturated zone model, so you cannot directly handle rainfall. An option is to
use Visual HELP to estimate recharge to the groundwater from rainfall, and import the data into
Visual MODFLOW as recharge boundary condition. Another option is to use MODFLOWSURFACT.
* Computation of T by tide-aquifer interaction involves two approaches: (a)direct use of 'Time
Lag' model and/or 'Tidal Efficiency' model; and (b)inverse modeling. The first approach is very
simple, and computation can be done using a scientific calculator. However, the second
approach requires the use of a nonlinear optimization technique (e.g., Gauss-Newton or
Levenberg-Marquardt).
* The Recharge boundary condition could be used to simulate average rainfall (for example,
monthly averages) being applied to the top layer of your model. It is important to note that
depending on your model design (i.e. discretization of layers), if you have one of more layers
above the water table, they will likely become unsaturated, or oscillate between unsaturated and
saturated if recharge is being applied. Andras Jakab's suggestion of using MODFLOW
SURFACT in this case is a good one, as SURFACT is designed to handle both unsaturated and
saturated flow modeling. However, if your layers are designed so that the bottom of layer 1 is
below the water table, this will not be a concern.
* The simulation of a wetland could be done using either the Constant Head boundary condition
(which can act as an infinite source/sink for water, to maintain the head value assigned) or the
River boundary condition (which will add/remove water from surrounding cells through the
river bottom, depending on the head value of the surrounding cells).
* Visual MODFLOW software can be used to determine optimal pumping rates, volumes of
water extracted, and drawdown cones of influence.
1) The Well Optimization component of Visual MODFLOW is designed to answer questions
such as: -what is the minimal pumping rate required to maintain an assigned head level? -what is
the minimal volume of water that must be removed to contain a contaminant plume? -what is the

maximum mass removal rate attainable? -what is the maximum pumping rate that can be used
while maintaining a specified drawdown level? etc.
2) The Zone Budget component of Visual MODFLOW can be used to calculate the cumulative
volume of water being extracted through a pumping well (or other boundary conditions) over
time.
3) Visual MODFLOW provides drawdown contours as one of the output maps available. You
can customize the contour interval, add specific contour values, and colour shade your contours.
* Unfortunately there is no automatic way to find the number of active or inactive cells in your
Visual MODFLOW model. However, you could take the active/inactive array from the .VMG
file and put it into excel, then use the COUNTIF function to count the number of 1's (active
cells) or the number of 0's (inactive cells).
* Dewater Model
You can download the model from the following zip file:
http://www.pmwin.net/models/dewater/dewater.zip
Here are what I have done:
1. Since PMWIN uses consistent time/length units, all parameters are converted to using meters
and days (for example recharge = 0.000219 m/d) and then entered to the model.
2. In order to estimate the zone of influence, the extent of the model grid is constructed quite
large (north-south width = 2275m; west-east width = 3080 m). I noticed later that this size is not
large enough (see below).
3. The northern and southern boundary of the model are constant head boundaries. The southern
boundary represents the sea and is set at h = 0 m. The northern boundary is set at 9.1 m so that
the hydraulic gradient between these two boundaries is 1/250.
4. The groundwater recharge is entered, and a steady state flow simulation has been carried out.
The trench is not yet modeled at this point.
5. The calculated steady-state head values are imported as initial heads (so that we can calculate
the "real" drawdown cone). I got a problem here: When considering gradient of 1/250 and the
distance of the mine pit from the sea (500 m), the groundwater level at the mine pit should stand
at 2.0 m MSL (not 1 m MSL). When groundwater recharge is considered, the calculated
groundwater level stands at 2.5 to 2.8 m MSL. Therefore, there is a disagreement between the
given water level and gradient. However, I ignored this problem and continue my exercise.
6. The trench is modeled by using constant head condition with h = -1 m.
7. Finally a steady state simulation is carried out again.
8. I put the screen shot of the drawdown cone (zone of influence)
here: http://www.pmwin.net/models/dewater/drawdown.jpg
The image shows that the drawdown reaches the boundaries of the model. This means that either
the extent of the model is still not big enough and/or the problem with the data disagreement
(see step 5) needs to be solved first.

9. The amount of water that needs to be pumped out from the trench can be easily obtained by
carrying out a subregional water budget calculation for the trench.
The remaining question is whether the capacity of the aquifer/trench system is able to support
the required pumping rate. Ignoring the capacity problem, question #2 can be solved by carrying
out a transient flow simulation (with desired simulation length and number of time steps) at step
7 instead of steady-state simulation. We can set an observation point within the mine pit and let
PMWIN draw the drawdown-time curve.
Hope this helps and the correctness of the model is NOT guaranteed since I have done this
model on the fly.
* To estimate the mine inflow into an open pit, a soft ware "Mine Hydrology" by Donald Koch
is available. The other best method is to develop a groundwater model for the study area and
predict the inflow at different stages of mine expansion. This will be more accurate. As your K
value seems to be very high, please verify whether the flow would be laminar or turbulent. If
turbulent, the conventional equations may not work as they all are based on Darcy's law, derived
on laminar flow.
For estimation of radius of influence, you may use the Schidart formula R=c*(h1-h2)*sqrt K
Your can case also be viewed on density basis, because of fresh water and saltwater. In such
case, the other suitable method for variable density.
* The fundamental construction of MODFLOW is that mass transfer occurs across the faces of
cells, not at depths within a cell. Thus, to get evapotranspiration as a function of depth of soil
using MODFLOW would require multiple cell layers that could each take a unique ET value.
That level of subdivision tends to generate numerical instability (unless the system you are
modeling is relatively small). I've not heard of using MODFLOW to model ET as a function of
soil depth. Using polygons to assign unique ET values by location is probably the most
commonly used method for ET varying over the model domain.
* You can use Visual MODFLOW to visualize the results from seawat output file by extract the
head file (.hds) and concentration file (.ucn) from SEAWAT output files to Visual MODFLOW
output files. You must use Visual MODFLOW first to create your model.
* PCG2 has two levels of iteration. The trick in using it is to get enough convergence within
one outer iteration. In most cases, you need between 25 and 50 inner iterations. Some models,
however, are very sensitive to the number of inner iterations, so you just have to experiment
with it. A common problem with PCG2 is that it can get to the point where the model is
converging within the inner iterations but not between successive outer iterations. It just keeps
oscillating and never actually converges. We built an option into Vistas to cut off this
oscillation if N successive outer iterations have reached the head and residual tolerances but the
model has not converged. Normally that will keep the run going, although you need to check
the mass balance errors to make sure the run is valid.
* Visual MODFLOW 4.1 now includes the SEAWAT package. You can graphically visualize
inputs and outputs related to a SEAWAT project (created using Visual MODFLOW) the same
as you can with all other flow and transport engines that are part of the program.
* If water does not flow away fast enough in your model, you can either increase the
permeability (i.e. the ease with which water flows through the system) or increase the head (i.e.
height difference, or slope between inflow and outflow).

* There is no formula that will give you the value of a parameter that you can only measure in
the field. And the fact that you are using MT3D has obviously no influence on the value of the
dispersivity of your contaminant plume. The relationships you refer to are empirical formulas
and I don't understand why you hesitate. There is no right or wrong empirical data. You only
have to ask yourself if the data representative of these regressions are compatible with the
hydrological context, with the lithology, and more important with the scale of your problem.
Note that dispersivity behaves like a fractal property, I mean, at each scale, the value of the
dispersivity is different, because the mechanisms that cause dispersion are not the same at each
scale.
Short: there is no right or wrong formula, and you can enter what you want into MT3D. You'll
always get a numerical result corresponding to the dispersivity value you have entered. If you
don't have field data that allow you to calibrate an analytical solution to find a value for the
dispersivity, I suggest you to simulate simply several dispersivity values. In this case, you have
to give results for a range of dispersivity values. I think it is more rigorous as to use a magical
formula.
* A preprocessor is used to create the input files for a model. Usually preprocessors convert a
graphical representation of the model to the text files required by the model. A postprocessor
reads the output from the model and does something with it. Usually what it does is display the
results in a graph, map, or 3D image.
* The default grid within Visual Modflow provides the following:
1. 60 Layers
2. 1000 Stress Periods
3. 500 rows and 500 columns
4. 250,000 (500 rows by 500 columns)
5. I am not aware of any limitation in the number of polygons that can be assigned in a layer
* Unfortunately, Visual MODFLOW does not currently support Telescopic Mesh refinement,
which is the feature you are looking for. This feature is under consideration for a future release
of Visual MODFLOW.
* To your question: "will pumping work in Modflow if the pumps extend through multiple
layers, some of which may or may not go dry?" YES, it will work, if other conditions are
appropriate. Did you know that if a cell in MODFLOW goes dry, it stays dry for the rest of the
simulation? Cells going dry is not necessarily a problem, but it can be. If cell size is relatively
large, discontinuities in head between adjacent cells may cause instability or unrealistic head
distributions. Cells going dry in transient situations can be particularly troublesome.
* Surely soft computing techniques give new possibility to find better solutions. But, basically,
they were designed to find discrete decision variable values while hydrologic parameters are
normally continuous type. You should do extra work to implement continuous feature to the
traditional discrete techniques. In addition, although soft computing methods do not require
gradient information, they do require algorithm parameter value assumption such as crossover
rate, temperature decreasing rate, etc. These work requires additional effort. Moreover, you need
to make sure whether your solution area has really up-and-down local optima shape. Sometimes,
traditional gradient methods still give much better solutions.
* One of possible reasons for non-convergence could be that you have wrongly specified
boundary conditions. If you do not have a way for water to get out of the system, for example,
all is input (precipitation, recharge) and no output (a river, constant head boundary, wells, etc.)
there will be no convergence in steady-state simulation. Levels will build up and up, reach the
max number of iterations and declare "non-convergence". Change of solvers will not help.

Having in model isolated cells that are not connected with the rest may also "call for trouble".
Check that all cells are connected with and to an ouput boundary. Make isolated cells inactive.
* You can use Wetting Capability package for dried cells and in this way rewet them.
* I guess your model is an one layer unconfined aquifer. If it is, then you may get dry cells if, for
instance, the head in the river cells is very close to the bottom of the layer so the oscillations in
water levels during first iterations jump below the base of the layer in some cells. This will make
the cells to go dry. The same effect you may get when your starting heads are very different
from the actual water levels.
* In Modflow layer type 1 (unconfined) top of the layer is infinity. The top of this layer does not
play any role in model calculations. You may however specify the elevation but it is used only
for presentation, not during model calculations. If you get the simulated heads above the ground
elevation than it probably means that maybe you have too high recharge or too low hydraulic
conductivity. Keep working on model calibration.
* I always prefer some simple hand-made calcs to check plausibility of the result:
The change of water volume per time unit is:
dV/dt=recharge*area (=0.1 m/yr*area in your model)
The relation between water volume and head for confined conditions (means as long as the head
is greater than -300m in your model) is:
dV/dh=S*area*M (S=1e-5 1/m in your model; M- thickness of the aquifer = 300 m in your
model)
The resulting change in head per unit time is:
dh/dt=dh/dV * dV/dt = 1/(S*area*M) * recharge *area = recharge/(S*M)
= (0.1 m/yr) / (1e-5 1/m * 300 m) = 33 m / yr
Therefore the estimated drawdown is 33 m per year.
* DRASTIC is very crude way for vulnerability assessment. Remember that DRASTIC does not
give you pollution status but Vulnerability scale. Other ways of vulnerability assessment could
be Factor method, physical or/and mathematical models. These gave more realistic view of the
pollution status.
* Looks to me like you may have two problems with your model. 1) No flow boundaries around
the whole model perimeter and recharge at the same time; 2) Starting heads
Re No 1) If your model, in pristine conditions, (e.g. with no extraction by wells etc) does have
no flow boundaries all around the model, but at the same time you have recharge over the model
area than once you start your simulation the water levels will start building up and up and up :),
because there is no outflow from the model domain. I would suggest re-visit your conceptual
model and figure out where, and at what elevation is the outflow from your model domain.
Re No 2) You have probably started your simulation with starting water levels set at some
negative number. Check this in the "starting head" option.

* Here is a quick overview of Visual Modflow: The Visual MODFLOW interface has been
specifically designed to increase modeling productivity, and decrease the complexities typically
associated with building a three dimensional groundwater flow and contaminant transport
models. In order to simplify the graphical interface, Visual MODFLOW is divided into three
main sections:
* Input
* Run
* Output
Each of these sections is accessed from the Main Menu when a Visual MODFLOW project is
started, or an existing project is opened. The Main Menu serves as a link to seamlessly switch
between each of these sections to define or modify the model input parameters, run the
simulations, calibrate the model, and display results. The Input section allows the user to
graphically assign all of the necessary input parameters for building a three-dimensional
groundwater flow and contaminant transport model. The input menus represent the basic "model
building blocks" and are displayed in a logical order to guide the modeler through the steps
necessary to design a groundwater flow and contaminant transport model. The Run section
allows the user to modify the various run-time options for each numeric engine. These include
selecting initial head estimates, setting solver parameters, selecting the layer types, activating the
re-wetting package, specifying the output controls, etc. Each of these menu selections has
default settings, which are capable of running most simulations. The Output section allows the
user to display all of the modeling and calibration results for the groundwater flow, particle
tracking, and contaminant transport simulations. The output menus allow you to select,
customize, and overlay the various display options for presenting the modeling results. In each
of the three sections, the Visual MODFLOW 3D-Explorer may be used for three-dimensional
visualization of the groundwater flow and contaminant transport model.
* In my opinion, there is no recipe or blueprint in evaluating depletion of ground water
resources. What we need is:
(1) Good and reliable ground water data (lithology, water levels, water quality, abstractions, etc.)
both as time series and individual points (monitoring, observation networks, water meters
installed on pipelines, locations confirmed by GPS, etc.);
(2) Ground Water Information Systems (GWIS) in which we turn data into information (data
processing and management, analyzing, interpreting, quantifying, presenting and reporting);
(3) Modeling, if we have enough and trusting data.
* Associated with eucalyptus plantation is the use of enormous quantities of chemical fertilizers,
pesticides and agro toxics for growing the non-native eucalyptus. This in turn is responsible for
polluting the soil, ground water and streams, and therefore damaging the surrounding
environment as well. There are many studies on Internet about eucalyptus and its effects on
subsoil. With respect to ground water there are many factors to consider: depth to water table,
lithology of unsaturated zone, sources of recharge, etc. Evapotranspiration process is limited to a
certain depth and ground water may escape the "sucking" as you say, if it is deeper than 3 to 4
meters.
I do not think the paddy cultivation is bad on ground water resource provided you have
sufficient recharge and potential of underlying aquifers. For example, paddy fields in the Terai
of Nepal get a lot of water from shallow wells. Shallow aquifers are recharged after each
monsoon season. The same cannot be true for basalt, gneiss and other hard rocks in many parts
of India. However, again, we witness pollution of shallow ground water by agricultural practices

(nitrates, phosphates, etc.). The same damage comes from sugar cane fields in Jamaica to paddy
cultivation worldwide.
* MODFLOW (all versions) is a finite difference code which requires a regularized rectangular
grid for all layers. You cannot "pinch out" a layer to zero thickness because you would end up
dividing by zero and crashing the simulation. Instead, specify some minimum thickness (say 1
m) and assign the portion you wish to "pinch out" the hydraulic parameters of the layer above
(or below).
* In basaltic or granitic hard rock terrain, where the rock strata are very massive, it is sometimes
necessary to create an 'artificial aquifer' for providing drinking water supply to small villages
and hamlets in remote, hilly areas.
In India, the Monsoon rains are from June to September, followed by 4 months of mostly dry
winter and 4 months of dry summer. Dug wells (3 m dia and 10 m depth) used for drinking
water supply by villagers are useful during Monsoons but go dry by end of winter. In
summer,the villagers have no reliable source for drinking water. Deep bore wells (80 m to 100
m depth) do not yield water due to massive nature of the rock, if at all the drilling rigs could
reach these villages. Water Tankers cannot ply in these remote, hilly areas due to lack of good
roads. We therefore, drill about 100 to 120 bore wells of 10 m depth and 150 mm dia, within 30
m radius from the dug well, fill them with fine sand and 2 kg of dynamite sticks and blast to
create a jacket of artificially fractured aquifer around the dug well. A seasonal dug wells then
becomes a perennial dug well, although the yield in summer is just enough to provide drinking
water for about 100 to 150 residents.
In another situation, consider a narrow ravine of about 3 m depth and 1:100 gradient of bed,in a
hilly granitic terrain. In the first year, a concrete dam of 1 m height is constructed across the
ravine. A 100 mm dia pipe and a valve is provided at the bottom of this dam. During rains the
dam overflows but a sandy aquifer is created behind the dam. Next year the height of the dam is
increased by 1 m more and a thicker aquifer is created behind the dam. Within next 4 to 5 years,
as the height of the dam gradually increases, a good sandy 'artificial aquifer' is accumulates
behind the dam which gets saturated in the rainy season. A pipe line is laid from the valve at the
bottom of the dam for providing PURE drinking water supply by gravity flow to small villages
at the foot of the hills.
These are the only examples of 'artificial aquifers' I know from my field work as a consulting
hydrogeologist, since 1962. I will be happy to learn if there are more examples elsewhere.
* To correctly simulate the response of water level due to tidal sea level fluctuations, the
simulation of seepage boundary condition is important for unconfined aquifers. It may affect the
modelled length of the seepage face and the location of intersection point of the water table and
the aquifer boundary. You may check if the seepage condition has been reasonably simulated.
This condition is time-dependent due to change of sea level. Also to check the sensitivity if the
specific storage on water table.
* The constant flux condition must be made with wells that inject water.
* You could assign a constant flux to each node, or cell, in your model using the MODFLOW
well package.
* When interpolating add dummy points in areas where you have no data. This should help you
to control the interpolation results.

* You have two options here. First, you can have the model layer share properties with a layer
above or below to represent the hydrologic unit above or below. The second option, which I
prefer, is to make the unit hydrologically "inactive". In that case, you assign a relatively high
vertical conductance and a low horizontal conductance to the model layer in the area that is
"pinched out.". In this way, the unit provides little to no resistance to vertical flow but no longer
functions as a significant permeable unit in the horizontal.
* You have two options to come over this problem, First: you can achieve the interpolation of
your layers from top to down (from the upper most layer to the lower one), after finishing the
interpolation of the first layer use GIS to subtract one meter from the first layer in the positions
where the second one pinches out, and force these values to the available data of the second
layer and so on..
The second option is to put reference points in every layer, were the other layers pinch out
(reference point = elevation of upper layer - 1 meter), then import the data to VMOD and let him
interpolate them with more neighbors, but it will take a while.
* In VS2DT, be sure to select "Simulate Transport" under the Options/Model/Basic tabs. After
which, you should have the option to define a specified concentration for flux in boundary
conditions. As far as assigning a contaminant concentration to soil, perhaps you can define
initial contaminant concentrations in the model along with a bulk density and partition
coefficient (Kd) and run the model for a period of simulated time (i.e. equilibrium) PRIOR to
allowing any water to move into the model domain. In that way, the initial contaminant mass
will partition between the dissolved and sorbed phases. I don't think you'll ever have a situation
where mass is all sorbed to soil, there always is a partitioning between water, soil, and air.
* The so-called extinction depth depends on air temperature near ground surface (and many
more physical factors!). Prof. Schoeller has developed an empirical formula which relates this
depth (depth below which there should not be evaporation directly from ground water table) as:
Dext = 8 * Tmean +/- 15 cm,
where Dext is extinction depth in cm, Tmean is mean air temperature for the time period in
degrees Centigrade. Of course this is a very crude representation of real conditions but it may be
a starting point. For example, if your mean air temperature is 15C, then extinction depth could
be between 105 and 135 cm. If you expect that ground water table will never rise closer to the
surface than, say, 3m, you may ignore completely the ET package.
* If you have a recharge rate, which I will assume you are interpreting as a net boundary flux
into your problem, then you need to break out the influence of the following components:
1. Precipitation
2. Evaporation
3. Transpiration
The sum effect of these three components should equal your net recharge rate assuming zero
contribution from lateral flow or deep flow in your area of interest. If you have access to
precipitation data, then you should be able to back-calculate the expected lumped evaporation
and transpiration effects using a spreadsheet.
If you want to calculate actual evaporation as well as transpiration rates you will need software
which can calculate actual evaporation (the Modified Penman method is common) as well as
transpiration effects. To make use of such software you will need to have access to weather
station data such as temperature, wind speed, net radiation, precipitation, etc.

* I would say rather that an analytical model has an exact mathematical solution because of the
many simplifying assumptions built into it (e.g., infinite area, homogeneous, isotropic, et cetera).
These can be applied with a minimum of data and effort (for good or ill). The numerical model
is an approximation to the exact solution because of discretization in one or more dimensions.
The discretization allows localized conditions (e.g., aquifer thickness, boundary conditions,
heterogeneity, et cetera) to differ from the general assumptions of the analytical solution. These
use an iterative process to arrive at a solutions and are more data and labor intensive than the
rather simple analytical solutions. But numerical models can be tailored to the specific situation
of your site much more than analytical solutions.
Knowing when you can and can't use either one is the art within the science. Watch the
assumptions, the data requirements versus data availability, and most of all, keep the objective
of the modeling effort in mind. Get the now-classic benchmark book by Anderson & Woessner,
Applied Groundwater Modeling (1992). I have found it to be an indispensable reference and
guide.
* Anderson and Woessner is certainly a good start. You might also try a couple USGS
publications:
"Methods and guidelines for effective model calibration"
(http://water.usgs.gov/nrp/gwsoftware/modflow2000/modflow2000.html), and
"Guidelines for evaluating ground-water flow models"
(http://pubs.usgs.gov/sir/2004/5038/).
One of the most important things is to try and know as much about the ground-water system as
possible before constructing the model. Know what the aquifers are, and what the boundary
conditions (both external and internal) are. Know where the recharge and discharge areas are.
Know something about the water budget - don't just calibrate to water levels or you'll end up
with a non-unique solution. The model is a good tool to help you further your understanding of
the ground-water system, but you need to know something about it up front so that you can "ask
the model the right questions to answer". Models need to be built for a specific purpose, to
answer a specific question. Find yourself a mentor, who has modeling experience, either
someone at the school, a private consultant (sign on as an intern), or at a local USGS office.
* Surfact Fracture-Well package
I have used the fracture well package successfully over the last 10 years for various purposes,
including as a conduit connecting multiple aquifers and in density-dependent flow/transport
cases.
The fracture well package constraint is that the cell sizes should not be too large since it uses
superposition to represent the well as well as the porous matrix block at the node. Larger cell
sizes will lead to greater averaging, and the logarithmic drawdown near wells will not be
captured. This averaging of the head can then affect the flow magnitude through a well-bore
even if the well itself is not pumping.
A consideration in using the fracture well package is that sometimes, for large radius wells, the
conductance down the well can become huge whereby the gradient down the well is exceedingly
small, causing the typical "big number problem" as occurs in representing lakes by "high K" etc.
This can cause convergence difficulties or mass balance errors. In that case, the FCONST term
(which represents rho * g / 8 mu) may be made smaller, or the radius of the well may be made

smaller, with the post-processing check down the well to ensure that gradients between layers
are not too large - i.e., that the well is not now creating too much resistance as to restrict flow.
Hopefully soon - in the next month or two - a newer version of Surfact is expected to be
released, which includes an additional fracture well package that uses the Thiem log function to
connect a porous matrix node to a fracture-well node. This removes the cell-size limitation in
connecting the well to the porous matrix block. Further, the fracture well nodes are solved fully
implicitly with the porous matrix nodes providing a stable solution. And use of a fracture-flow
formulation down the well allows for resistance down small-bore wells to be included, as
opposed to the formulation of equilibrium down the well-bore which neglects these effects.
* Contouring is a "trend" analysis. While we accept interpolation using known random points,
we do not trust extrapolation, that is program calculating values outside of domain with known
values. You will notice that negative values are generated in places where field values are
missing or spacing between field points with known values is too big. I have seen maps with
storage coefficients being either negative or more than 1.0; both values clearly physically
impossible. Same as getting negative values, you may expect also "blown up" values to
extremely high ranges.
You may solve the problem in several ways. One is to assign minimum and maximum contour
values to be plotted on the map. Of course, the minimum values would be a positive number.
The other method is to exclude the areas that have no "positive value" points by cropping the
map coverage. For example, in Ground Water for Windows (GWW) package, you draw a closed
area (enclosing "positive values" points) and allow contours to be plotted only within that area.
In other words, you will not accept extrapolation. Still another way is to experiment with several
methods of solution (krigging, polynomial, minimum curvature, etc.; see SURFER) and find the
one that produces better results. You may also modify "modeling" parameters used for gridding.
* There are many algorithms for interpolating data. Some are "exact" (in that they return the
value of the input data) and some are "inexact". The Surfer (http://www.goldensoftware.com/)
documentation provides this list of exact and inexact interpolators...
Exact:
Inverse Distance to a Power (no smoothing function)
Krigging (no specified nugget effect)
Nearest Neighbor
Radial Basis Function (no R2 specified)
Modified Shepard's Method (no smoothing factor)
Triangulation with Linear Interpolation (TIN)
Natural Neighbor
Inexact:
Inverse Distance to a Power (with smoothing factor)
Krigging (with error nugget)
Polynomial Regression
Radial Basis Function (with R2 specified)
Modified Shepard's Method
Note... the ability to return input values may or may not be related to surface accuracy. To test
accuracy, hold out (don't use) a few well positioned data points and compare those values with
their predicted values. All interpolators have problems at the edges of data sets, so be sure to
collect extra data (outside of your study area) to avoid this problem. Also, interpolators

generally describe local variability or global variability - not both. The exceptions are
geostatistics and radial basis functions. Surfer has been a favorite interpolator package, but
ESRI's Geostatistical Analyst extension (in ArcGIS) is also very good. Besides having both
radial basis functions and geostatistical functions - it provides surface error analysis tools that
produce both graphic and numeric descriptors.
* I can only offer that when i have used interpolation in arcview, a gradient is maintained which
can cause your gridded values to be below zero. one way to correct this is to essentially add
dummy contours to control the gradient and prevent negative values. check your high end
values as the gradient maintained can also cause too high a value. you can use global min and
max to set the limits; however, i have had to use dummy contours to control local minima and
maxima.
* If you have one time series, then the decision on the stationarity of the data is actually an
assumption (needed in most cases). Strict stationarity indicates that the probability distribution
is independent of location. Weak stationarity is more commonly used (since Kolmogorov in the
1960s). It is that the correlation function depends on the spacing between two points and not the
actual location.
* If you have 3D Analysis extension for ArcView3.2a, you can do it. Otherwise you should find
a free GIS software like GRASS, SAGA GIS, etc. First you have to create TIN model for each
parameter and from that you can create corresponding contours.
* An alternative is to take the natural log of the values you wish to contour (grid), then grid
these values, and then back-transform the gridded data and contour that grid. This should
mitigate negative values and usually results in a more pleasing map. However, note that krigging
the log of the values can be interpreted as a bias (low) representation of the data in between your
measured points. This is of concern if you are making certain calculations (mass, etc) but may
not be of such concern if you are simply attempting to make a representative map. I am not
certain if ArcView/ArcMAP provides the automated facility to grid the logs of values - this may
require you to do some data manipulation prior-to and after the gridding process. I find this is
simple in Surfer due to the GRID options provided, but am not so familiar with
ArcMap/ArcView.
* My former colleague is dead right that krigging the log of the values will not preclude the
occurrence of negative values in log space - this might be unavoidable. However, since the result
of exponentiating any number, positive or negative, is a non-negative number, when the data are
back-transformed following interpolation in log space, all values in native space should be
greater than or equal to 0.0, and I believe the resulting map you are after is in native space not
log space (I do not have a copy of the original post). Also, since the log of the native data show a
smaller variance and diminished gradients this usually leads to diminished extremes in the
interpolated field.
If either of these occurrences does not happen in ArcMap I am not sure why that is the case
since I have never used its interpolation methods - but I can think of no reason why it should
not.
When back-transforming the gridded field of data, a cut-off can be used in the logic which will
produce a similar effect to capping the global minimum or 'blanking' beyond a specified value that is, by back transforming with a formula such as:
If (value >= 0) value = exp(value)
If (value < 0) value = 0

This approach would make a map of the native parameter which has a lowest non-zero value of
1.0, with all other values equal to zero. A variant would be to use a cut-off equivalent to the log
of the reporting limit (rpt) for the parameter. For example, if the parameter reporting limit is
0.01 then using:
If (value >= log(rpt)) value = exp(value)
If (value < log(rpt)) value = 0
should ensure that the native interpolated field shows a lowest non-zero value of 0.01, the
reporting limit for that parameter, with all other values equal to zero. This might be a useful
result, depending on the purpose of the mapping.
For two-dimensional gridding of data of this type I would probably recommend Surfer - I am not
a paid advertiser for the software (!!!!) but in general find it user-friendly, the file formats easily
manipulable, and the GRID-MATH utility very flexible.
* From a practical standpoint, there are several free and user-friendly software applications
which facilitate parameter determination and relationship comparison. Among these are: XLPlot, scilab, OpenOffice Calc, SMADA REGRESS, and Data Master.
* I am not sure about the equations you present, but I think the difference here is due to the
different mechanisms of transport. Advection along a flow path is different than convection, or
in some sense could be considered a sub-category of convection. The Peclet number refers to the
ratio of advective to diffusive transport along a flow path in a porous medium. The advective
portion of the transport is driven by a potential gradient in the fluid, such as a head gradient in
groundwater flow. The diffusion portion of transport is driven by concentration gradients.
Density of the fluid is not considered, just how much of the solute transport is due to advection
versus how much is diffusion. In transport modeling, the Peclet number is generally considered
to represent the ratio between advection and the combination of diffusion and mechanical
dispersion.
The Rayleigh number, on the other hand, describes density-driven convection currents. The
density gradient may be caused by different solute concentrations, or by temperature, for
example. So, the two numbers really describe different phenomena and are not directly
comparable. In my opinion, the Peclet number is more relevant for most transport-modeling
work, because the solute concentrations are usually relatively low. With low concentrations, the
density gradients are small (equivalent to very low Rayleigh number) and density-driven
convection is not important. This would not be true for modeling brine transport or salt
water/fresh water interactions.
* You first need to understand what dispersion means: It is the spread of solute due to the spatial
variation of the macroscopic velocity. (Molecular) diffusion is the transport of solute due to the
random motion of molecules. They are both represented the same way if you are looking at the
problem at a larger scale.
Peclet represents the ratio of transport by longitudinal convection to transport by transverse
processes. These processes could be due to dispersion (i.e., solute spreading due variation of
velocity over space) and/or diffusion (solute spreading due to molecular motion). the vertical
Raleigh number represents the ratio of vertical density gradient by stabilizing forces (viscosity
and diffusion/dispersion).
Now, if the systems that you are dealing with are two or three-dimensional, then they are
inherently unstable. The only way a plume does not engender local unstability is if you have

enough "dissipation" (diffusion and dispersion) in the system coupled with large horizontal
velocities. The work of List (1965) and Schincariol (2000) are excellent references.
* MODFLOW is not well-suited to modeling variably saturated flow. There is an add-on called
SURFACT that can be used to model the unsaturated zone above a MODFLOW saturated-flow
domain, but I do not know if it is available for free.
VS2DT is a free program from the United States Geological Survey that can be used to model
saturated-unsaturated conditions. It can be found at
http://wwwbrr.cr.usgs.gov/projects/GW_Unsat/vs2di1.2/index.html.
Another free choice from the USGS is SUTRA. It can be used to simulate variable-density flow
under saturated or unsaturated conditions. Read about it at
http://water.usgs.gov/nrp/gwsoftware/sutra.html.
UNSAT-H
(http://hydrology.pnl.gov/resources/unsath/unsath.asp)
and HYDRUS-1D
(http://www.pc-progress.cz/Default.htm)
are free models that can be used to simulate one-dimensional unsaturated flow systems. If your
project can be completed with a 1-D model, either would be a good choice.
The choice between finite-difference and finite-element models depends on the nature of your
problem, especially the boundary conditions and the complexity of the model domain.
* Using an ephemeral or intermittent stream as a boundary condition is usually not advisable.
However, if you calculate the flux contribution from the stream, you may be able to create a
variable flux boundary. This could then be simulated by a series of wells in the location of the
ephemeral stream, each well varying in its contribution depending on the time period.
* The MT3DMS (Multiple Species) is usually the most effiecient solver from my previous
experiences. It allows the user to specify an initial step size, maximum step size and a factor to
adjust sucessive steps. A more effective solver will automatically adjust the step size based on
your numerical tolerance criteria.
* Normally MODFLOW assumes that the boundary (limits) of your model are "no flow"
boundaries, that is there is no inflow from outside the model domain and no outflow from inside
the model domain out. There are however options (e.g. constant heads or general flow boundary)
that allow you to modify this. MODFLOW is also a saturated flow model only. This means that
if any of your model cells goes dry than it is removed from further calculations. If your layer, or
part of it, goes dry that means that it disappears from the model completely, therefore
subdividing one of your layers in two (one dry and one saturated) will not make any sense.
Installing a constant head boundaries around the model may or may not be necessary. It depends
on the situation on the ground, e.g. if you have a river, a lake or ocean somewhere within or next
to the model area than you may (but do not have to) simulate it using a constant head boundary.
Saying all this you should start your simulation from reading one of the books recommended by
David. The next step will be conceptualization and simplification of the model area, then
building and calibrating your model and only after that running predictive simulations.
* If you have just one model layer MODFLOW it means that you are simulating 2D flow only
and there is no need for vertical conductivity. MODFLOW is not using vertical conductivity

anyway, it is just your pre-processor that is using vertical conductivity together with the aquifer
thickness/elevation of the top and bottom of the layers to calculate VCONT parameter.
MODFLOW itself is using this parameter (VCONT) to calculate vertical flow between layers.
* If you only have one layer, there is no vertical flow in the model.
* The first thing to determine is the units of the budget terms. MODFLOW uses consistent units
so if your grid cells are measured in meters, these numbers represent cubic meters. The values
are for the entire modeled area so if there was evapotranspiration outside the wetland that would
be included too. You could use ZONEBUDGET to get the evapotranspiration in the wetland if
evapotranspiration outside the wetland is an issue. The evapotranspiration calculated by
MODFLOW only includes evapotranspiration from the saturated zone. Evapotranspiration
from the unsaturated zone might or might not be an issue depending on whether or no an
unsaturated zone is present. If an unsaturated zone is present, the evapotranspiration calculated
by MODFLOW will only be part of the total evapotranspiration.
Some things you might want to consider include:
1: Is the pan evaporation for the same period as the model?
2. Is all the data in the model in consistent units?
3. Is evapotranspiration from the unsaturated zone an issue?
4. Are the stresses on the system represented correctly in the model?
5. Is evapotranspiration ever limited due to lack of water?
6. Does evapotranspiration from the water table occur outside the wetland?
7. Are there other processes that need to be include in the model?
* One comment to using pan evaporation data. Often the true open water body evaporation is
less then measured pan evaporation. There are a number of reasons for this. In practical terms, if
you have no other data, you can probably assume pan evaporation factor of 0.7 (see Technical
Note No 126, "Comparison Between Pan and Lake Evaporation", by C.E. Hounam, World
Meteorological Organization, 1973), that is the true evaporation from the lake surface will be
70% of pan evaporation value. This correction factor gives you a standard error of 21% and a
greatest expected error of 60% according to the author. The range of annual pan evaporation
factors is roughly between 0.5 and 0.9 but on a monthly basis it can be as wide as form 0.13 to
2.04.
If there are cells in your model representing the wetland, that went dry during simulation than
they are excluded from further calculations and consequently there will be evapotranspiration
from these cells.
* It is actually MT3D that simulates contaminant transport within Visual Modflow. MODFLOW
itself only simulates ground water flow. MT3D of course takes into account the "concentrational
differece" or the concentration gradient. However, we prefer to call it dispersion for contaminant
transport in porous media, rather than diffusion because the process of diffusion can be
considered as insignificant when compared to the magnitude of mechanical dispersion.
* Running Transient simulation without steady state - There are a couple of approaches that you
could take. First of all, with MODFLOW 2000 you have the option of running your model for
the first stress period (or any stress period for that matter) as a steady state model and then
transient after that. Meaning, you can do your steady state run and transient run all in the SAME
model. This is very convenient and I would suggest the you take a look at this option.
However, if you would like to do it the more traditional approach, all you have to do is follow
these steps:

- run your MODFLOW steady state simulation AND read in your results
- either double-click on your "starting heads" data set in the project explorer (if running GMS
6.0) or bring up the Starting Heads dialog via the MODFLOW|Global/Basic package dialog
- In the upper right hand corner choose the button "3D dataset->grid" and when the dataset
chooser window comes up, select the MODFLOW solution you just got through reading in.
* Running Transient simulation without steady state - It depends on the format of your heads
from your SS run.
MODFLOW: One method would be to copy and paste the head matrices within the MODFLOW
files themselves (or Basic Package). Copy your heads out of the SS .BAS file and paste into
your transient .BAS file. See page 4-9 of the MODFLOW 88 documentation for the Basic
Package format.
Other: If for some reason your heads are not in a MODFLOW array format, you can use GMS
and create a grid or a 3D data set. Once you have imported your data into GMS go to your
MODFLOW menu, Global Options, Starting Heads, 3D Data Set > Grid, then select your SS
heads 3D Data Set (or Grid) file. This will set your starting heads to this data set.
You can also import 3D data sets, e.g. Surfer files, .dem, .ddf, .asc, etc into GMS too and then
follow them same steps.
* There are sophisticated methods of calculating evapo(trans)piration from ground water table
(Penman, Thorntwaite, Mather, and all derivatives), if this was the question ("net recharge").
However, often we are faced with a decision of accepting the so-called "extinction depth", that is
the depth to the water table below which there will be no evaporation loss. See, for example,
Visual Modflow manual.
Yet, as a first approximation, there is a very simple and highly EMPIRICAL formula by prof.
Schoeller:
Dext = 8 x Tav +/- 20
where Dext is the extinction depth in cm, and Tav is an
average air temperature near ground surface for the period calculated. Thus, e.g., if monthly
average air temperature was 25 degrees C, extinction depth would be between 180 and 220 cm.
Meaning that when water table falls below that depth, there is hardly any evaporation loss
directly from ground water. Not necessarily the transpiration loss!
* Several years ago in one of Yahoo groups (WaterForum) we had discussion about conversion
from "measured" electrical conductivity to "calculated" TDS. I saved one of communications to
the WaterForum group. Here it is fully reproduced. Author is Nick Walton.
From:
To:
Subject:
Date sent:

Self <nick.walton@port.ac.uk>
waterforum@yahoogroups.com
TDS and Conductivity - a tricky relationship
Sun, 24 Aug 2003 12:54:09 +0100

Recent correspondence on this apparently simple but deceptive relationship has highlighted the
need to be very careful when using different conductivity meters in different waters/solutions for
different purposes, as the practical TDS/EC relationship is only empirical and approximate and
thus works best for comparative rather than absolute measurements. There are a significant

number of issues which complicate this deceptively simple relationship, especially when used to
compare different waters/solutions. Some of these factors I discuss briefly below, but for a more
detailed understanding I refer the reader to my paper on this subject as referenced at the end of
this posting.
Firstly - the wide variety of meters on the market vary in their use of temperature compensation
(yes/no or on/off), the coefficients used in their internal electronics and the automatic
temperature compensation standard (20 or 25 deg.C) used. This can give inaccuracies of more
than 10%, which can be significant in monitoring situations.
Secondly - the electrodes used (material type, size and configuration will all have different cell
constants and are only suitably accurate for either low, medium or high ranges of conductivities.
Similarly, the associated meters require increasingly sophisticated electronics to overcome
impedance and capacitance effects associated with passing the AC current through different
lengths of cable to different electrodes immersed in differently conductive/resistive waters. The
commonly available one-type-fits-all approach leads to significant errors in unsuitable
conductivity ranges, and those errors are then compounded when there is a fixed conversion
factor (usually between 0.65 and 0.70) in the meters electronics to enable the direct display of a
TDS result from an EC reading.
Thirdly - the whole electrochemical basis of conductivity being related to the TDS of a
water/solution depends critically on not just the number of ions present, but the size and charge
(ionic potential) of each individual ion which carries the current. Now this can be readily
calculated (molar conductance) at infinite dilution, but for all normal waters/solutions, there is
an increasing 'ion-crowding' effect which changes these absolute molar conductivity values for
each ion as the water/solution becomes more concentrated, and thus the original linear
relationship takes on increasing curvature as concentration increases.
This can be readily demonstrated by using different concentrations of single salt solutions. For
example the TDS/EC ratio for a simple KCl salt solution changes from around 0.51 at 100mg/l
to 0.61 at around 10,000mg/l, whilst that of a potassium sulphate solution of similar
concentrations goes from 0.71 to 0.81.
Fortunately, for most environmental waters, the usual good mixture of ions present ensures a
levelling-out of all these individual ion effects, and only where one or two ions are
overwhelmingly dominant (as with Na & Cl in sea-water or H in acid mine waters), does the
TDS/EC relationship stray far from the usually used average values of around 0.65 to 0.70,
towards the limits for this relationship, of 0.5 to 0.9.
An understanding of the deeper aspects of this apparently very simple and much used TDS/EC
relationship becomes very important when regulatory matters, legal standards, plant operational
guarantees etc. are involved. The use of the wrong conductivity probe, meter and TDS/EC
relationship can then cost one dear.
For further understanding of this subject, I would refer readers to my paper on this topic entitled,
' Electrical Conductivity and Total Dissolved Solids - What is their precise relationship ?'
published in the Journal of Desalination, vol 72 (1989) pp275-292.
* Factor of 0.64 or 0.65 is OK if you have no other data (lab analysis). But be aware that in real
life the conversion factor may vary as much as about 0.55 to 0.9 (or 0.95?). All depend on
chemistry of water because the chemistry determines water electrical properties. So, if you do
not have any lab results than use 0.64 (or 0.65), however it would be better if you could look t
water lab results and compare lab (or field) determined EC (electrical conductivity) with lab
determines TDS (total dissolved solids).

* I think PMWIN creates standard MODFLOW files that are called "bas.dat", "bcf.dat" etc...
You can import these in Visual Modflow, however you have to make sure you use layer type 2
or 3, so the information of the top and bottom of the layers is available.
* I think the best way to do so is to create the standard MODFLOW input files and import them
into VM. As far as I know the modflow input generated by PMWIN is strictly stick the standard
of original file format of MODFLOW, but I am not sure about the VM. I think you should also
be careful when you import them into VM since some data may lost because some setting. You
may have to try a few times before you would succeed since the import program in VM may
crash due to some setting, that was happened to me before, and don't know if the new version of
VM fixed the problem.
* First you have to check the Modflow version of both the software. If both the softwares are
using MODFLOW different version then it will create problem. Most of time I have exported all
data of PMWIN in *.grd or *.dat format in separate file then importing dataset into visual
modflow. But any case you will be able to import only basic data. You have to again run the
model and simulate the results.
* Van Genuchten Parameters - The inverse of alpha could be used as an estimation of the height
of the capillary fringe (zone of considerable moisture). The parameter n represents the
uniformity of the pore size distribution. A value of 2.5 to 3 would be ok for sand due to the
uniformity of the grain size distribution, which could translate into uniformity of the pore size
distribution.
* Even when you use other software to estimate groundwater recharge, the estimates are not
usually reflective of the dynamic system because they are calculated externally from the
MODFLOW model and are not dynamically linked to the model. While using external
programs like the HELP model, or some hydrology-based models like HSPF, is better than
simply using Recharge as a calibration parameter, this approach does not 'close the loop' in
terms of integrating the entire hydrological cycle in one dynamic model. Integrating PRMS with
MODFLOW is a good step in the right direction, but there are other more established
approaches you may also want to consider (warning....commercial software plug is coming...)
Models like DHI's MIKE SHE have addressed the issue of integrated surface water and
groundwater modeling for a long time, but one of the knocks against it was that it was too
parameter intensive and required too much data for the typical groundwater
modeller/hydrogeologist. However, with the push towards a more integrated approach to
modeling surface water and groundwater interactions, it seems that the industry is heading in
this direction, and is forcing the hydrogeologists to start talking with the hydrologists and the
agronomists to come up with a set of data to properly represent the complex relationships
between surface water and groundwater. MIKE SHE is capable of modeling the land phase of
the hydrological cycle by integrating complex and/or simple representations of these processes,
including evapotranspiration/infiltration, 1D unsaturated zone flow, 3D groundwater flow, 2D
overland flow (runoff), and 1D river channel hydraulics. These processes are all dynamically
coupled so you don't get the inconsistency problems associated with disconnected models
representing connected processes.
* If you have access to a GIS you could try analysis based on flow directions. Your starting
point would then be the elevation map (DTM: Digital Terrain Model or DEM: Digital Elevation
Model This is a grid covering your area of interest with elevation data for each grid cell. High
resolution grids for the entire earth are available, see www.terrainmap.com). From this DTM
you would calculate a flow direction map and a catchment boundary map, and then you would
have to separate all catchments draining into one ocean from all catchments draining into

another. I'm sure this has been done before, but don't know any links. Your starting point would
be elevation however, and not rivers.
* There is a fundamental difference between a steady-state and a transient simulation. When
you run the first stress period in steady state, MODFLOW will generate a set of heads that are
consistent with your boundary conditions in terms of a steady-state (i.e., infinitely long time
step) system. In that state, it could be that your boundary conditions and internal sources/sinks
would lead to some of your cells being dry. In the case of a transient simulation however, the
changes in the heads during the first time step may be quite small; they certainly would be much
smaller than the changes you would get with the steady state time step. Thus, the heads may not
move enough to get to the "dry cell" state you found with your steady-state simulation.
Furthermore, the transient stresses in your simulation may begin to affect your heads and
prevent the model from reaching the "dry cell" state.
There is another possible scenario: you may be experiencing "head overshoot". In some cases
MODFLOW will attempt to move the heads too far during one iteration of a time step (the
steady state time step in your case) and if the heads go below the cell bottom elevations the cells
will be marked as dry and turned off for the remainder of the simulation. You can test to see if
this is the case by changing your acceleration parameter (this has different names depending on
the solver) to a small number like 0.01 and running the model again. If the cells don't go dry in
this case, you know that it was head overshoot.
If I were you, I would run the steady-state solution as a separate simulation. Once you have
everything worked out, copy the computed heads from your steady-state run to the starting heads
array and do a normal transient simulation. This will allow you to test the head overshoot
theory. You certainly don't want to run your entire transient simulation using a small
acceleration parameter since it would slow down your solution.
* Your steady-state solution, with zero storage, moves immediately to the equilibrium head
distribution (if it closes). With the same parameters, boundary and initial conditions, the
transient simulation should be moving toward the same solution. The storage coefficient
provides a source/sink--the magnitude of the storage parameter determines how long the system
takes to reach equilibrium. The cells are probably not going dry because the simulation is not
run long enough.
I'd suggest you keep working with the steady-state model until the heads are reasonable (no dry
cells?), then use those for the initial heads in the transient model. Drying and re-wetting cells
can cause instability; sometimes it helps to treat all layers as confined early in the calibration
process. Another trick is to make a"pseudo" steady-state simulation by specifying a small
storage value, set initial heads ABOVE the target values, and running the model out until it
reaches steady-state (100 yrs?). This helps when you have a lot of head-dependent boundaries
and want to let the model approach the solution gradually. You are sort of using storage as
dampening factor. Of course, you can also use solver parameters to achieve a similar effect.
* There are some things you need to keep in mind regarding the MODFLOW binary files. The
first problem is that older versions of MODFLOW (e.g. MODFLOW88 and MODFLOW96)
were compiled by the USGS to write out FORTRAN Unformatted files. These files have end of
record markers and other bits in the file that make it hard to read by a non-fortran program. If,
on the other hand, you use the newer versions like MODFLOW2000 or MODFLOW2005, then
these files create generic binary files without those extra bits. Those should be readable by
Matlab/Delphi without too much trouble. You can see the various versions of MODFLOW at:
http://water.usgs.gov/nrp/gwsoftware/modflow.html

Also, if you are using our Groundwater Vistas or another commercial pre-/post-processor, then
those binary files should also be readable.
The format of the binary files depends on the type of binary file. Head and drawdown files have
one format and the budget files have another. If you know some fortran, I have uploaded a
simple utility I wrote to read the binary files and convert them to ascii. You can get that at
ftp://ftp.modflow2000.com/pub/bin2asc.for
Essentially each binary file contains a header record followed by a matrix of numbers. All
numbers are 4 bytes (4 byte integers and 4 byte single-precision floating point numbers). The
header record on the head and drawdown files contains:
time step number stress period number stress period time total simulation time 16-byte text
string number of columns number of rows layer number
This 44-byte header is followed by a matrix of floating point numbers representing heads or
drawdowns at each cell in the layer. They are read in row-column order. That is, you start at
row 1 and read each column from 1 to the number of columns, then move to the second row, etc.
The budget files are a bit different. The header on a budget file is:
time step number stress period number 16-byte text string number of columns number of rows
number of layers
This 36-byte header is followed by a matrix of floating point numbers representing flows in
every cell of the model. They are read like the head file above but you also read each layer
sequentially starting with layer 1 (top layer in model).
* The best way to see how data are written to the binary head (Fortran unit IHEDUN) and
drawdown (unit IDDNUN) files is to refer to the Fortran code that does the writing.
Unformatted files are opened in SGLO1BAS6OPEN (in source-code file glo1bas6.f) at
comment C4C. The options of the OPEN statement are defined in the include file openspec.inc,
which may specify various options, depending on the version of MODFLOW (versions 1.2 and
later use different options than earlier versions) and on the compiler being used. For versions
1.12 and later, and the Lahey LF95 compiler (used to compiled the version distributed on
http://water.usgs.gov/nrp/gwsoftware/modflow2000/modflow2000.html), the OPEN
specifications are:
DATA ACCESS/'SEQUENTIAL'/
DATA FORM/'BINARY'/
These specs code for the "unstructured, unformatted" file type which is supported by a number
of compilers.
Unformatted header records and hydraulic head data are written to unit IHEDUN by subroutine
ULASAV (in source-code file utl6.f) for each time step and layer for which heads are requested
to be saved. Here are the instructions that do the writing:
WRITE(ICHN) KSTP,KPER,PERTIM,TOTIM,TEXT,NCOL,NROW,ILAY
WRITE(ICHN) ((BUF(IC,IR),IC=1,NCOL),IR=1,NROW)
* Get the source code for the MODFLOW GUI from
http://water.usgs.gov/nrp/gwsoftware/mfgui4/modflow-gui.html. It includes a Fortran dll for
reading MODFLOW binary output and Delphi 5 source code that uses the Fortran dll.

* How to describe a river/stream in MODFLOW - The river bed elevation and the elevation of
the layer containing the river are different things and do not need to be the same. You can think
of the elevation assigned to the upper or lower surface of a cell as the average elevation of the
area covered by the cell and the elevation assigned to a river bed as the average elevation of the
portion of the river in the cell. Because the river is draining the surrounding area, the elevation
of the real river will typically be lower than the elevation of the surrounding area and similarly,
it wouldn't be unusual for the elevation assigned to the river bottom in a cell in MODFLOW to
be lower than the elevation assigned to the top of the cell. Typically, the elevation assigned to
the river bottom in a cell would be higher than the elevation assigned to the bottom of the cell.
However, everything in MODFLOW is just mathematics that you are using to represent some
real world phenomenon and if for some reason, it makes sense to you to assign a river elevation
that is above the top of the cell or below the bottom MODFLOW won't stop you or even warn
you that the data are atypical.
The roles that cell elevations and riverbed elevations play in your model are quite different. If
your model layer can convert between unconfined and convertible the top elevation of the cell is
compared to the head to test whether the cell should be treated as confined or unconfined. The
bottom elevation of the cell is also compared to the head to see whether the cell should be dry or
not. The river bed elevation is also compared to the head but the purpose of the comparison is
different. If the head is below the river bed elevation, it is assumed that there is a constant flux
of water from the river to the aquifer. If the head in the aquifer is above the river bed bottom,
the flux to or from the river depends on the head in the aquifer and the head you assigned to the
river.
* MODFLOW or FEFLOW - While both codes are capable of running solute transport
modelling problems, thus including nitrate, I would probably recommend NOT USING
MODFLOW !!! :-)
Feflow simulates multi component transport with reactions. The amount of component that you
simulate is not limited. Because Feflow is not a plug and play soft, the reactions between species
are not limited to any pre-defined schemes. You have to define your own reactions in terms of
reaction rates depending on the chemical reaction you want to simulate. Any species can react
with another. If your reaction is chemically well defined, then you won't have any problem to
enter the parameters in the feflow transport parameters.
But we still do not know what type of reaction you want to simulate. You can have a look at the
Feflow White Paper to which I contributed to see what can be done. Free download at:
http://wbalmo.de/download/feflow/manuals/5.2/white_papers_vol4.pdf
* It is not possible to have a finer grid in a small portion of a model, unless you do it all along
the rows and columns. When you add rows or columns to refine your cells you will have do it all
along the rows and columns. Having a small portion of finer cells some where in the model is
not possible with MODFLOW! This is a special case of finite difference method which
MODFLOW does not support. Try refining all concerned rows and columns so that you cover
your area of interest. In VMOD go to input menu -> edit grid -> choose edit rows or columns. I
advise you to use "refine" option so that you get cells of equal dimensions.
* I would highly recommend to have a look at a very good book "Applied groundwater
modeling" is very useful. The data depends on: What questions do you want the model to
answer? In general the data is Geological maps, cross sections, layers elevations top and bottom
or layers thicknesses (isopach maps). Topographic maps, the Google Earth is an excellent tool to
used for showing surface water bodies and divide (you can download it for free). Water level
(table) counter maps for all aquifers. Historical measurement of water level and chemistry,

abstractions, recharge and springs discharge (all sink/source). Pumping test analysis (hydraulic
conductivity for each aquifer vertical and horizontal) Boundary conditions for both flow model
and solute transport model. Initial concentration and longitudinal dispersivity. If you will use
PMWin 7 or 5 there is very good examples with documents.
* It would be better to go with SEAWAT. SEAWAT couples MODFLOW and MT3DMS
internally so the density effects to the flow can be simulated. Once you have the database for
MODFLOW/MT3DMS, you basically have everything that is needed for a SEAWAT model. So
why not go for it?
* I think the choice ultimately depends on whether the density is significant enough to affect the
physical definition of hydraulic head. If it is significant, then the concept of "equivalent
hydraulic head" becomes more valid. Basically, SEAWAT is a combination of MODFLOW and
MT3DMS with some important modifications made to MODFLOW; in MODFLOW fluid
volume is conserved rather than fluid mass. Also, SEAWAT uses the equivalent freshwater head
as the variable of interest.
I would go with SEAWAT2K or equivalent if density is say greater than 1.05-1.10.
* The Bulk Density parameter you refer to from PM Pro (MODFLOW + MT3DMS) is likely the
Soil Bulk Density, and it is used solely for the purpose of calculating the adsorption (retardation)
of dissolved solute on the porous media. As such, PM Pro with just MODFLOW and MT3DMS
cannot be used for density dependent flow simulations.
* A recent posting inquired as to whether one could vary the grids density in Visual Modflow. I
am recalling an older and simpler numerical modeling package called Flowpath, also designed
by Waterloo Hydrogeologic for 2D applications. I used Flowpath extensively, though
admittedly as my career shifted focus I was never compelled to make the shift to VM. (I now
worry more about far more mundane and trivial things like making payroll, generating business
in hydrogeologic consulting, mentoring staff...). I miss those days of technical challenges!
Anyway, my point is that Flowpath did facilitate grid variances nicely, with a warning about the
Peclet number. As I recall it, the Peclet point was that adjacent grids should not be more than
double or less than half the size of the preceding one. So, if VM has the facility to vary grids
(and Nillson Guiger and Thomas Franz are the BRILLIANT hydrogeologists and programmers
at Waterloo who developed Flowpath and similarly excellent products, so it must!), be careful
not to put vastly differing sized sells next to one another. Ease the variance, and Peclet (and
hence, defensibility) will not be violated.
* MODFLOW doesn't "know" units, it assumes that you are keeping track of everything. Make
sure that you are using consistent units everywhere (e.g. L = meters, Time = seconds). Your K
units would then be meters/sec and recharge is meters (per unit time, in this case one second).
Recharge is a specified flux, so what you see reported in the out file should be the result of what
you specified (meters of recharge * area receiving recharge = cubic meters) for the period of
time of your model (second). Yes, average annual recharge rate, adjusted to proper units, is a
good start for steady state models. Also, your other boundary conditions can control heads.
Make sure that you are not over constraining your model with aggressive boundary conditions.
* I've generally used steady state simulations under two sets of conditions. First, if you have a
system that responds very rapidly to stresses that remain nearly constant for a period of time
after their onset, then a steady state simulation compared to measured system responses would
be appropriate. Haitjema (1995) provides some discussions on identifying these situations. You
may also want to have a look at Anderson & Woessner (1992).

Another reason to simulate steady state is that you're removing storage and the time derivative
from the governing PDE. Hence, errors in these terms cannot mask errors in hydraulic
conductivity or spatial discretization. Calibrating to steady state conditions therefore provides
another way of verifying these aspects of your model. If you want to history match over a long
period of time where steady state conditions don't exist, you may want to try what we've done in
several large ground water modeling projects. That is to apply long term average stresses to you
model (boundary conditions, recharge, ET, etc.) and ensure that computed system responses at
least fall within the range of corresponded measured responses (preferable not too far from the
historical average). If you model doesn't pass this test, it would undoubtedly signify that there
are problems with either the model or the data.
* How to enter clay lenses in MODFLOW if not extended throughout the study area? Create
layers at the range of depth where the clay lenses are. Then you can specify that they are clay
lenses by assigning different properties (hydraulic conductivity, for example) just for the area
where the lenses are located.
* The answer appears to be in the question. A pumping induced groundwater divide will be
affected by a change in the ratio of pumping rates between interfering wells. The principle is
one of superposition of drawdown which occurs linearly for confined conditions. Analytical or
numerical solutions will demonstrate this phenomenon.
Analytical methods could be used to test whether the movement in groundwater divide is
significant for steady state. For highly stressed water resources it could be necessary to consider
transient conditions leading up to periods of drought in order to assess the impact of a change to
the groundwater divide.
Perhaps you need to find out if the groundwater divide is really pumping induced. This could be
done with a sophisticated analytic elements program, or by numerical methods. However you
will need detailed knowledge of leakage into the aquifer and a fully calibrated and verifiable
model to predict future conditions.
* I agree with the suggestions offered by others -- focusing on AEM and image-well-theory
methods. Yes, these would work fine. However, I would also note that the criteria for answering
the regulatory agency's concerns (i.e., "How much drawdown is 'significant'?" and "How much
of a shift in the divide is 'significant'?") need to be defined quantitatively before you can
determine whether your fixed-divide approach is appropriate. This is because, theoretically, the
divide will change due to the added pumping -- as long as all other factors remain the same.
I think it's also worth noting that your assumption of a fixed-location, impermeable divide would
lead to prediction of a larger drawdown at that fixed-divide location than if you were to allow
the divide to shift -- because you would be, in effect, preventing groundwater from flowing from
beyond the divide, thus increasing the amount of groundwater being captured from within the
divide. Therefore, you may want to determine first which criterion is the more important (i.e.,
drawdown or divide-location) before deciding whether to model the situation using image-well
theory or an AEM package.
* If the wells fall within a cell block (computational block), then you would need to group them
together. On another note, it is always an issue of scale. If the radius of influence is 1 km and
you are looking at the problem at the 50 km scale, then grouping the wells would not affect the
result. But locally you could dewater the aquifer (artificially) if you group the wells.
* Parsimony would dictate no boundaries as a default assumption when you do not know much
about the aquifer system. Boundaries constrain the outcome; the absence of boundaries satisfies
the general case.

* A cell in a convertible layer is treated as unconfined if the head is below the top elevation of
the cell. In a confined layer all cells are treated as having constant transmissivity regardless of
the saturated thickness and cells are not allowed to go dry. Are the initial head in the nonconstant head cells less than or equal to zero? If so, those cells would go dry on the first
iteration.
* You may want to consider running your model in a predictive analysis mode using the PEST
software. It can help to assess the accuracy and uncertainty of model-based predictions.
Additionally, the use of any inverse parameter estimation technique to calibrate the model can
give you insight into how much you really know about your input parameters, given the amount,
distribution and quality of your history matching data.
* If the head is above the top of the layer, the cell is treated as confined.
* I believe Visual MODFLOW supports the MGO code for model optimization using a variety
of methods. Although it doesn't integrate with the SEAWAT code, you can define water levels
(and maybe drawdown too...I don't recall) as criteria for the optimization, and in this way you
can try to optimize pumping schemes to maintain a minimum hydraulic gradient towards the
coast.
* It seems that you have unintentionally explored the two primary options for representing a
confining layer in MODFLOW. The first way, setting an appropriate VCONT value as you had
done before, should still work. Using that method you have two layers in the MODFLOW
model, and vertical flow between the layers is controlled by VCONT without getting an explicit
representation of heads in the real confining layer. MODFLOW does not "know" that there is a
confining layer in the real aquifer system, it just calculates vertical flow between the two layers
according to the VCONT values. This is appropriate if you do not need the simulated heads in
the real-world confining unit for your project. You may need to go into the arrays in Visual
Modflow to adjust your VCONT values rather than using the values calculated by Visual
Modflow.
The second way is your new model, with three layers. Using that method, the confining layer is
explicitly represented. Now you have VCONT for the flow between layers 1 and 2, and a
different VCONT array for the flow between layers 2 and 3. MODFLOW does not need to
"know" that the second layer is the confining unit because it is calculating vertical and
horizontal flow through that unit explicitly, just like it does for layers 1 and 3. In this case, the
values in the two VCONT arrays calculated by Visual Modflow may be adequate. Now you are
getting the simulated head information in that layer, which wasn't possible when the confining
unit was only represented with VCONT values. This method gives you more control over the
parameters used to represent the confining unit, but you may need more data to set the values of
those parameters.
In my humble opinion, either method is fine as long as the one you choose is appropriate for the
intended use of the model output and the level of data available for parameterization and
calibration.
* The Layer Type settings you have entered are correct as you have described them. The
determination of head values in the confining layer will be governed by the boundary conditions
you have assigned, where you have assigned them, and the internal stresses you have on the
system (e.g. pumping), the hydraulic properties of the layers, and whether or not you are running
a transient or steady state solution. Generally speaking, the hydraulic conductivity of the
confining layer (Layer 2) will be three or more orders of magnitude less than the hydraulic
conductivity of the aquifers.

If you have a simple gradient across the model with little vertical flow, then it is reasonable that
the head in the confining layer will be the same as the head in the upper unconfined layer. If
you introduce some pumping in the lower aquifer (layer 3) then you will likely see some
differences in the head values calculated in Layer 1 and 2.
* To calibrate the model using PEST, we need to prepare the template file, instruction file and
control file. The template file allows the users to identify the parameters to be included in the
optimization. The instruction file allows users to identify the observations (i.e. measured flow
data) from the output file. The control file provides PEST with the model name, parameter initial
estimates, field or laboratory measurements to which model outcomes must be matched. The
problem you meet is probably due to the failure of reading the model output file by the
instruction file. You have to know what is your model output file name is or you should run the
model once first to generate the output file(s). Specify the output files to be read (if this function
exists in modflow), so the instruction file able to read the simulated results from output file and
compare it to your measured data.
* MODFLOW only simulates pumpage in active cells. CHD cells are specified head cells not
active cells so pumpage is not simulated in them. In the CHD package, IBOUND for all CHD
cells is set to a value less than zero. The following lines in the well package subroutine
GWF1WEL6FM then check IBOUND and skip the inactive and specified head cells
C2A-----IF THE CELL IS INACTIVE THEN BYPASS PROCESSING.
IF(IBOUND(IC,IR,IL).LE.0) GO TO 100
C
C2B-----IF THE CELL IS VARIABLE HEAD THEN SUBTRACT Q FROM
C
THE RHS ACCUMULATOR.
RHS(IC,IR,IL)=RHS(IC,IR,IL)-Q
100 CONTINUE
Because MODFLOW does not simulate pumpage in the specified head cells, no pumpage term
for those cells is written to the budget file that ZONE BUDGET reads. To resolve this problem
you should avoid having wells or other flux or head-dependent flux boundaries in specified head
cells.
* A groundwater model shows highly non-linear behaviour under density-dependent conditions.
So if a model converges well with a density ratio of 0, it might not be as stable with a density
ratio applied. I would recommend that you run the model for a while in transient mode until it
reaches the steady state. That might be required for all the model runs, depending on the
complexity of the model. Density-dependent models will only converge in steady state mode for
relatively simple cases.
* The Stream package (STR) allows a channel to go dry and rewet (if applicable). You could
make the stream in 2 segments, with the 2nd segment starting where the GW is discharged back
into the stream. This Q can be specified at the top of the stream reach. Stream bed conductance
can be adjusted as necessary to make sure the channel dries up (i.e. induce more leakage to the
aquifer by increasing conductance). The RIV package specifies only a river stage (and therefore
functions similar to a constant head boundary), whereas the STR package can calculate stage
based on incoming flow and conductance. Since you have a specified Q at a certain point (GW
pumping discharge) and if you can characterize the upstream Q, I think the STR package would
be much better suited for your application.
* Visual MODFLOW will generate a file with the extension .OT that is the output file of MT3D
and includes the results of the mass transport calculations and a mass budget for each transport

time step. This is an ASCII file so you should be able to view its contents using a text editor. At
the end of the file you will find the data you are looking for, but make sure to check what units
they are in. This may be found at the very beginning of the file.
* It depends on whether the faults act a barriers to flow or as conduits. If they act as barriers, you
can use the Horizontal Flow Barrier package. If they act as conduits, you could try modeling
them as zones of high hydraulic conductivity. Alternatively, you could contact Eve Kuniansky
at the USGS about the forthcoming CAVE package for MODFLOW.
* In my experience, first you need to check your conceptual model which is the prime factor that
influences everything from start to end. If you find it right, then move ahead;
Obviously you are having dry cell problem in the unsaturated top layer; I suggest you to recheck
your major input data such as; recharge, gw level, K and S, make sure that each and every input
cell value is perfectly alright;
If it doesn't help, go to Run>Modflow>Rewetting settings and try changing wetting threshold,
interval, head and method and see if it helps;
If rewetting doesn't solve your convergence problem, here are a few essential things to check:
1. How is recharge assigned? In the MODFLOW Run settings for Recharge, try assigning
recharge to the "highest active cell in each vertical column". This will allow the incoming
recharge to bypass inactive or dry cells in your upper layers, and may improve convergence.
2. Layer thickness: If you have a top layer that is thin, and dries out quickly, consider reassigning the layer elevations, or combining this layer with the layer below. This will increase
the total layer thickness, and will likely reduce the probability of dry cells occurring.
* The objectives of the modelling exercise will determine whether you build one large model or
split the whole area into few smaller models. If you have o model the whole watershed of that
size than probably 2D model should be OK. If you decide to build a 3D model than you can not
pinch the layers because MODFLOW does not have such capability. Instead you may either
make the layer that pinches-out very thin, or just simply change the hydraulic parameters of the
model layer to the parameters representing the aquifer that within the given space replaces the
one that pinched-out.
V-MODFLOW refers to Visual Modflow that is to the graphic pre/post processor (or GUI) for
MODFLOW, and not to a different modelling software. There are few other GUI's like GMS,
PMWIN etc that also use the same MODFLOW as a modelling engine, and can do the same job
as V-MODFLOW. This also mean that you can generate the ground surface in all other GUI's
not only in V-MODFLOW. Just remember that this is only 'cosmetic' difference because
MODFLOW is only a saturated flow model and for MODFLOW there is no such thing like
topographic surface. If you assign the top layer in the model as an unconfined layer (as you may
have to) then MODFLOW will assume that the top of your layer is infinitely high.
* You may wish to consider using the Hydrogeologic Unit Flow (HUF) package instead of the
BCF or LPF flow packages. It allows you to specify the hydrogeologic units separately from the
model layers. It is especially useful for dealing with complex geology and pinchouts.
* Most transient simulations should be initialized with the results from a balanced
(inflow=outflow) steady-state simulation. One exception is for a transient that simulates a
period of time that results in nearly zero change in storage, so that inflow = outflow.

* If you are most interested in a particular period of time within the simulation, or a subset of
wells in the model, you might want to calculate the RMS for that time period or the subset of
wells.
* Convergence problem in a high gradient system - One way to avoid the convergence and drycell problem is to define the model layer as confined, but use a storage coefficient appropriate
for an unconfined system's specific yield. This prevents cells from drying and makes
convergence more likely. However, this will also result in the transmissivity of the layer being
held constant. If the saturated thickness and therefore transmissivity is expected to change
significantly in the real aquifer, you may need to account for that in your model interpretation.
* Convergence problem in a high gradient system - Probably the most common problem
encountered with modflow. The solution depends on your grid, material properties, boundary
conditions, what solver your using, etc, so it is very difficult to give specific advice. Depending
on your situation, you could switch to a more robust model like FEFLOW. You might consider
the following:
- smaller cells to better represent the gradients (this may create cells with poor aspect ratio in
outlying areas which will also cause problems if not addressed)
- use constant-elevation layers rather than a vertically deformed grid; probably would need more
layers in the model (overall, a model with equal spacing the the x, y and z directions works best
from a numerical viewpoint)
- transient flow, small time steps (if used properly, a steady-state solution of better quality can
be obtained)
- re-wetting option with great care
- SAMG solver (AMG would be better)
* Other approaches should be implemented before a re-wetting "fix", but Doherty's re-wetting
function would probably do a better job in the case of re-wetting (which should be used in
transient cases for rising water table, generally not to fix a dry-cell problem).
* In MODFLOW, defining a layer as confined does prevent all active cells in that layer from
going dry, as Walter says. And the approach he suggests is reasonable. Another option, if you
feel you need to allow the transmissivity to vary with head, would be to try using the GMG
solver with the adaptive damping capability obtained by setting IADAMP=2 and using a
suitably small value for CHGLIMIT, which allows the user to put a hard limit on head change in
each Picard (outer) iteration. You'll need at least version 1.17.00 of MODFLOW-2000 or
version 1.4.00 of MODFLOW-2005 to use this capability.
* Depending on how the refinement matches the original grid, the refined grid may simulate a
larger or smaller volume compared to the original grid, which would affect storage calculations.
* Specification of constant-head and general-head boundaries is by cell, not by layer. Any cell
in a MODFLOW model can be assigned as either a constant-head boundary or a general-head
boundary. The specified head value for each boundary cell (and, for GHB cells, the conductance
to the external head) may be assigned individually.
* How to delineate watershed and drainage patterns from DEM - (1) You can use Arc Hydro its
an automatic delineation tool. You may need to create TIN. ArcHydro can be used with GIS. it's
simple step by step process (2) I think the best way to delineate the catchment is to use the WMS
software but I think you should have the SRTM files for you region (Surface terrain model)
which will help you to do what you want. I think it is easy to get these files from the net, just
search by keywords SRTM data and you will find what you want.

* You cannot remove some cells in MODFLOW. Layers will cover the whole model area. What
you can do is; assign the properties of layer above or layer below to the cells of layer where sand
doesn't exists. See the "airport tutorial exercise" of Visual MODFLOW, you will find the answer
to your question.
* Negative Concentrations - You have a lot of numerical dispersion occurring in your
simulation. This can occur if your time step is too large, dispersivity is less than or equal to
model cell size, imbalances in the flow due to poorly converged flow simulation, etc.
Depending on the model, flow discrepancy should be less than about 0.01%. Abrupt changes in
material properties or stresses will cause flow imbalance, so look for ways to limit such changes.
Force MT3D to use smaller time steps by reducing the courant number. Try using a different
transport solver.
* Required data for MODFLOW:
- base map of study area
- location of Hydrograph Stations(water level monitoring tube well) and its filters' elevation(m
amsl)
- water level data for last 5/10 years
- location of abstraction tube Wells and its its filters' elevation(m amsl)
- daily discharge of tube wells
- rainfall data for last 5/10 yr
- Recharge(calculated) data
-evapotranspiration data
-River stage data for last 5/10 years (If river boundary condition employed) & river Cross
section
-Aquifer parameters (hydraulic conductivity, porosity(effective & Total),specific storage(for
confined aquifer), Specific yield (for unconfined aquifer )
etc....
* The starting heads in a gw. model do not impose any constraints, Their only meaning is to act
as a starting point for the calculations, i.e., to guide the solver during its first iteration. The
conditions that really influence the solution are the boundary conditions and the model
parameters. I suggest to review the boundary conditions first (e.g., constant head, river, recharge,
etc.) as I assume your starting heads conflict with the boundary conditions (i.e., they are not
consistent).
* It depends on the size and flow of the springs and the connectivity with the aquifer. The main
difference between river and drain packages is that drains always act discharging the aquifer,
while river can also recharge it. The drain cells become inactive (as a BC) if the aquifer water
level goes down below the drain elevation head. For river cells, the same situation causes the
reversion of the flow, from the aquifer to outside. The analysis of the flow and water level
variation in the springs can help you to make your decision and to verify latter if the model is
behaving as should.
* Discretization - If you want to keep the same number of cells, than you should use the grid
editor tool. go in grid, edit column or row spacing and assign the new value for the row and
columns you want to change.Calculate the length and width lost on your grid and divide it by
the number of columns or rows you have not changed, and then add this value to the spacing of
each unchanged column and row to compensate for the gap created.You will have a grid the
same size with the same number of rows and columns. Easiest and fastest way (to my
knowledge).

* The drain boundary package in MODFLOW is designed to simulate the effects of features e.g.
agricultural drain, which remove water from the aquifer at a rate proportional to the difference
between the head in the aquifer and the median drain elevation (assuming the drain is partially
full), so long as the head in the aquifer is above that elevation, but which have no effect if the
head of the aquifer falls below the median of drain elevation. So if hydraulic head (either water
table or piezometric head) in aquifer beneath the mine is below the head of river/spring (surface
water level elevation) then flow from the aquifer to the river/spring will show as ZERO. So I
think in this case, taking river/spring as "DRAIN boundary" is not appropriate. Your objective is
"to evaluate the impact of a mine in the water supply of the rivers & springs around the
mine"..so u have to account for the amount of flow in stream/spring around the mine and to
simulate the interaction between stream/spring & groundwater in the aquifer beneath the mine
...for which I think "STREAM boundary" will be appropriate for your objective. After running
the model u can get inflow/outflow to/from the model from "MASS BALANCE REPORT" from
which u can justify the effect of mine on discharges of its surrounding river/springs.
* Calibrate your steady state model through distribution of K-values and recharge in zonewise &
layerwise (for multiple layers). Also, check your input aquifer parameters (porosity, specific
yield, specific storage ). Then run the calibrated model and compare simulated heads with
observed heads and do it by trial-an-error till quite good match is achieved. But keep in mind
that the all input parameters should be relevant to the field parameters.
* If you want to use MODFLOW software to simulation groundwater flow or contamination, u
need the below parameters in the first step.
Parameter
Layer thickness
Kx,Ky
Kz
Dispersivity
Hor/long dispersivity
Ver/long dispersivity
Mol.diff.coeff
Bulk density
Kd
initial conc
Evapotranspiration
ss
sy
Eff.porosity
tot. porosity
recharge -normal
initial head
* Storage in steady state doesn't change (equal to zero). Storage comes into play with transient
models where initial heads are indeed important.
* I think the difference between one and the other is that a drain takes the water out of the
system and there is no interaction with the groundwater, while a river has a river bed
conductance so water can seep into the GW or vice versa, depending on the gradient. I would
start modeling the rivers as rivers (or streams) and check if you can calibrate the model. If that
doesn't work use the drains.
* Although Top may be assigned as land-surface elevation, there is no requirement that it be
assigned this way. Similarly, SURF commonly is assigned as land-surface elevation, but again,

this is not required. Each array is used for specific purposes as identified in the documentation
(http://water.usgs.gov/nrp/gwsoftware/modflow2000/ofr00-92.pdf): Top is used for several
purposes related to determining saturated thickness, transmissivity, and whether a cell is
confined or unconfined; It's up to the user to decide whether to use the same elevation data for
both arrays. SURF is NOT the head above which no evapotranspiration from the saturated zone
takes place. Instead it is the head at which evapotranspiration
reaches its maximum value.
* Top is the top elevation of layer 1. For the common situation in which the top layer represents
a water-table aquifer, it may be reasonable to set Top equal to land-surface elevation. SURF is
the elevation of the ET surface: the head above which no evapotranspiration from the saturated
zone takes place.
* General head boundary is better because Constant head boundary conditions can have a
significance influence on the results of a simulation and may lead to unrealistic predictions,
particularly when it is used in locations close to the study area.
* Usually surface water bodies are included in groundwater models as head dependent boundary
conditions. In other words the water levels in lakes or ponds are specified in the model input.
However in many instances it would be useful to use the model to calculate the water levels in
the lake, pond or void. In the past we have addressed this problem by including the size and
shape of void in the model grid structure and defined hydraulic parameters representative of a
surface water body (i.e. extremely high hydraulic conductivity, storage of 1.0 and recharge
defined as the excess of rainfall over evaporation) to the volume of the void.
* For certain types of input including multiplier and zone arrays, MFI2K requires the user to edit
Comma-Separated Values (.csv) files externally. This can be done with a text editor or a
spreadsheet program. The procedure is explained more fully in Open File Report 02-41, which
is available at http://water.usgs.gov/nrp/gwsoftware/MFI2K/MFI2K.html. See the "External
Editing Mechanism" section at the end of OFR 02-41.
* To have properties defined by a parameter for an aquifer that is represented in more than one
model layer, specify more than one cluster for the parameter. Each cluster codes for a
parameter's contribution to one layer, or if zones are being used, to part of one layer. But each
parameter can have as many clusters as you want, and different clusters may (but don't have to)
apply to different layers. In MFI2K, in the "LPF Hydraulic Data" window, click New or Modify
to bring up the "Array Parameter Definition" window. Each row in this window defines a
cluster. Define a non-zero value for "Layer" in as many rows as needed to specify all rows to
which a parameter applies.
* Model an unconfined then becoming confined aquifer - Set up the model with at least two
layers, as unconfined aquifer. Then, in the top layer, assign two conductivity areas: one with
high, for the unconfined part, and one with very small, for the confined part.
* SURFACT is a MODFLOW-based Flow and Transport code that successfully overcomes
several of the limitations of MODFLOW and its current transport counterparts. Examples
include rewetting of drained cells, handling of pumping wells, solute mass balance problems,
numerical dispersion and oscillations, and the implicit assumption of the negligible impact of
transient flow storage effects on transport. SURFACT solves the fully 3-D saturated/unsaturated
subsurface flow equations or alternatively solves enhanced equations for performing unconfined
simulations to rigorously model desaturation/resaturation of aquifers.
http://www.hglsoftware.com/ResourcesLibrary/modflow-surfact.pdf

For more information, you can call Software Sales at 1-(703) 478-5186 or
info@hglsoftware.com
* How to assign boundary condition for a constant horizontal flux - You can't find such type of
boundary in visual modflow. The thing u need to do is to calculate the head gradient based on
the constant flux u have and using Darcy's equation and other related theory to get the head
gradient. ( q=flux/A(area of your domain) and q=Ki(where K is hydraulic conductivity and i is
the head gradient). Then set one side of boundary head as a constant like 5m, and using head
gradient i times the length of your domain(horizontal length like x) then you have the constant
head boundary with the other boundary. So in this case, visual modflow will maintain the
constant flux.
* If you have a vector map with contour lines,you can use interpolation command in 3D analyst
extension in Arc GIS to convert your vector map to DEM.
* The input of rivers in modflow requires 3 parameters, none of which you have data for. So I
guess that means you will have to on the one hand convert your data into parameters applicable
in modflow and on the other hand use parameters to calibrate the model. The parameter
hydraulic conductance of the riverbed has to be calibrated using positive or negative values for
recharge to or discharge from the aquifer into the river. More on that is to be found in the
modflow manual. The parameters head in the river and riverbed elevation are geometric
parameters that might be converted from your river discharge values using the ManningStrickler formula:
vm = kStr * rhy2/3 * IS1/2
where vm is the average flow velocity [m/s], kStr is the velocity coefficient after Strickler
[m1/3/s] (i think it is a measure of roughness of the riverbed, values can be found in tables), rhy
is the hydraulic radius, (see diagram below) rhy = A/U with A: discharge area , U: wetted
circumference, ls is the gradient of the riverbed [-]. If you are able to get values for the required
modflow parameters, you can then interpolate in modflow between those 'endpoints'.
* It is not unusual to have problems getting parameter estimation to converge. For discussions
of typical problems encountered in parameter estimation and their solution, see USGS Open-File
Report 00-184 (Hill and others, 2000,
http://water.usgs.gov/nrp/gwsoftware/modflow2000/modflow2000.html) and/or Effective
Groundwater Model Calibration (Hill and Tiedeman, 2007, http://www.amazon.com/EffectiveGroundwater-Model-Calibration-Sensitivities/dp/047177636X). The parameter-estimation
formulation sees the parameters and observations you've defined, and the regression algorithm
manipulates parameter values in an attempt to minimize the sum of squares objective function.
It has no knowledge of the GW system being calibrated other than the parameters and
observations (and prior information, if you're using it). The regression affects the parameter
values; the model in turn is affected to the extent that the parameters being estimated
characterize, and control ground-water flow in, the system. The composite scaled sensitivity
statistics listed in the global file can be used to get a handle on the degree to which information
in the observations is useful in determining the estimated values of individual parameters.
Please refer to the publications listed above for discussions of composite scaled sensitivities.
You do not mention having any flow observations. It may be difficult to estimate recharge (and
other parameters) if you have no flow observations.
* If your computer runs Windows, there's no need for you to compile the programs; you can use
the executable files included with the downloads, available at

http://water.usgs.gov/nrp/gwsoftware/modflow2000/modflow2000.html and
http://water.usgs.gov/nrp/gwsoftware/modflow2005/modflow2005.html.
If your computer runs another operating system, you'll need a Fortran-90 or Fortran-95 compiler.
If you want to use the GMG solver, you'll also need a C compiler and do a mixed-language
compilation. Some information available here:
http://water.usgs.gov/nrp/gwsoftware/modflow2000/MFDOC/index.html?suggestions_on_comp
iling.htm may help.
For instructions for preparing input for MODFLOW-2000, refer to USGS Open-File Reports 0092 and 00-184. For MODFLOW-2005, refer to USGS Techniques and Methods 6-A16. These
and other reports that document specific packages for the two programs can be down loaded
from the first two links.
* Packages that VMF (or any other GUI like it) does not support must be prepared separately
using a text editor or other suitable program. The documentation for these packages can be
found on the USGS web site water.usgs.gov. I create most of the model in VMF, then after
translating the files to MODFLOW, edit in the necessary information into the MODFLOW files
to include the packages it does not support, then run the model using the appropriate VMF
modflow engine (or other suitable compiled version). I know of no other easier route. An
alternative to the lake simulators is to use cells with very large K and S values to mimic a lake.
While this can cause numerical problems, it can work under the right conditions.
* The LAK (LAK3) and RES packages are not currently supported within the Visual Modflow
interface. However, if you have the <projectname>.LAK and <projectname>.RES files in the
Visual Modflow project folder, Visual Modflow will check to see if any unsupported files are
present. The default Modflow run setting is set to Run, so Modflow will run the simulation
using these files. However, it may not be possible to view the LAK and RES ouput within the
Visual Modflow GUI even though they are included in the Modflow simulation run.
* It's been a while since I used Visual MODFLOW, but I don't think it has changed wrt to
handling of the STR data. Although VMF does support the STR package, it does so using an
object-oriented, grid-independent approach rather than a cell-by-cell approach. As such, the
original cell-by-cell data provided in a standard MODFLOW data set cannot be imported into
the stream objects supported in Visual MODFLOW. However, if you place the original STR
file in the project folder, Visual MODFLOW will recognize it and use it when you run the
simulation. Unfortunately, it will not allow you to display the data or edit the data file using the
Visual MODFLOW graphical environment.
* I think visual modflow can do the unsaturated zone if you use the modflow-surfact solver (but
I could be a little bit expensive, depends on your budget). I think SEEP/W which is part of
GEOSTUDIO (www.geo-slope.com) it is an option for saturated/unsaturated flow that you
might consider but you can only simulate 2D flow.
* Visual MODFLOW can be used to model the unsaturated zone with MODFLOW- Surfact.
You may also consider using MODFLOW-Surfact without the Visual MODFLOW integration,
but it lacks the user interface that Visual MODFLOW has. FEFLOW could also be considered
along with a few other groundwater modeling software products. Each of these products will
model groundwater flow and transport in 3D.
If you are considering something in 2D, UnSat Suite maybe be an option. This includes
different modules to use depending on the problem you are addressing from infiltration rates to
predicting the transport of organic solutes.

* For areas where boundaries play an important role in recharging or discharging the model
domain, defining the appropriate boundary condition is necessary. Through GHB boundary you
can adjust flux via boundary by defining a suitable conductance, but constant head transmits as
much water as needed, whether it satisfy real condition or not. So again care should be taken in
defining boundary condition and it seems you also need more field data.
* It seems, in terms of mass balance, that the constant heads that were representing your lake
were providing a significant inflow to the model. When you take that out, no more inflow and
the water levels go down. To keep your groundwater levels, you can either:
1. Decrease your outflow - by decreasing parameters such as hydraulic conductivity, or
boundary conditions conductance, such as drains (if this is the case).
2. Increase your inflow , and in this case increased recharge possibly is the best option. You will
have to play with two options until find a good result.
Bear in mind that the secret will be to "fix water deficit" that was generated when you took the
constant heads out. So either put more water or let the model release less water.
Regarding your question on the general head conditions (GHB) and constant heads. The
constant heads define the head in the cell and thus, the head in these cells is not calculating
during the simulation. For the GHB, and inflow/outflow is applied to the cell where you define
it, according to the difference of the GHB head and the cell head, multiplied by the conductance.
If you use very large values (tend to infinite) of conductance, then it will behave very similarly
to a constant head, otherwise it will be just another inflow/outflow source according to the head
gradients.
* You've had couple good replies to your question. Here's more to think about. Are the lakes
really perched? That implies a poor connection to a larger groundwater flow system. Perhaps
there is a layer of silt in the bottom of the lakes that limits recharge and allows water to pond.
Perhaps there is some other layer or process to consider. If they are perched, there would
probably be an unsaturated zone beneath them that you may need to consider in your modeling.
Its possible that there's lower infiltration from the lakes, which implies lower outflow from your
model domain and lower hydraulic conductivity between inflow and outflow areas. But it
depends on the data available to figure out what is actually happening.
* If the lake stage is controlled by factors other than ground-water flow into or out of the lake,
then simulating it with a constant head boundary is appropriate. If the lake stage is strongly
affected by ground-water flow into or out of the lake, then you could simulate the lake with the
lake package. If you want to simulate the lake with a general head boundary, you may need to
set the conductance for the boundary to a higher value.
In a constant-head boundary, the head in the cell is fixed and the amount of water flowing into
or out of the cell will be determined by the heads in the neighboring cells and the conductance
between those cells and the constant head cell.
In a general-head boundary, there is a constant head that is outside the model. There is a
conductance between this constant head and the general-head boundary. The difference in head
between the constant head outside the model and the general-head boundary and the
conductance and the general-head boundary determines the flux between the general-head
boundary and the external head. Thus the difference between a general-head boundary and a

constant-head boundary is that in a general-head boundary, the constant head has been moved
outside the model.
* I wouldn't bother with MODFLOW-96. It is no longer maintained (the last update was in
2000) and the data input does not support definition of parameters, which in the long run is a
nice way of thinking about model input. MODFLOW-2000 and MODFLOW-2005 have nearly
identical data input. MODFLOW-2000 has capabilities that are not supported in MODFLOW2005 (specifically, the Sensitivity and Parameter-Estimation Processes), but you don't really
need these to get started in ground-water modeling. As a result, where there are differences in
input, the MODFLOW-2005 input is slightly simpler. MODFLOW-2005 was developed
particularly to support local grid refinement, but that is a capability you won't need as you are
starting out. If you decide to start with MODFLOW-2005, it would be good to have USGS
Techniques and Methods 6-A16 by Harbaugh as a reference, available at
http://water.usgs.gov/nrp/gwsoftware/modflow2005/modflow2005.html.
* In a quasi-3D model, the confining units are not represented by model layers. Instead, the
vertical conductance between the aquifers is set to a low value to simulate the resistance to flow
due to the confining units.
* Quasi-3D usually means that the model represents leaky, confining layers with purely vertical
(1D) flow connections between the aquifer layers surrounding each confining unit. The
equations governing the simulated flow rely upon specification or computation of "leakance"
(equal to vertical hydraulic conductivity of the confining unit divided by the vertical thickness of
the unit), area-of-flow (i.e., the plan-view area of the grid cell), and the difference in head
vertically between the aquifer units above and below the confining unit.
Fully-3D means that each confining layer is represented in exactly the same way as each aquifer
layer. The porous media being simulated are continuously discretized and represented by the
standard governing equations, written in 3D form.
* As far as I understand, you don't actually model river flow using MODFLOW, you have to
model river stage. If you know the channel dimensions you'll be able to work out stage from
discharge.
* That's right: MODFLOW ignores the river flow. To simulate a river you have to measure (or
derive from maps), among other data, its stage at different locations. Your flow observation is
indeed precious for model calibration for it is a measure of how much water is exchanged from
the river to the aquifer. Compare it with the flow resulting from the mass balance computation
and youll have an idea on the goodness of your model.
* Yes: 20 l/s should be the flow supplied by the aquifer to the river (if the river flows east to
west) as calculated by the model through the whole river extension. You can use the riverbed
conductance as a calibration parameter in order to get the measured exchanged flow.
* If you use the RIV package, probably the single 20 l/s is appropriate. If you use the STR
package, you might use 120 since that package attempts to account for flow in the stream,
whereas the RIV package assumes the river always has water in it. Using the STR package, the
100 l/s observation would be an input for the inflowing amount of water in the river.
* You are correct in that the "river observation" corresponds to how much flow is exchanged
between the aquifer and the river. It appears that you have a gaining river. Make sure you have
a river arc that begins and ends at the locations of the two gages and assign an observed flow
value of -20 l/s to the river arc. It should be negative since it represents water leaving the
aquifer. You should also make sure you convert the flow rate to the proper units (typically m/d).

After you run MODFLOW, right-click on the folder containing the solution in the Project
Explorer window and you will see a summary of the head and flow residuals. You can also
click on the river arc and the residual will be displayed at the bottom of the window.
* Feflow does not have a package like MODFLOW that simulates flow in rivers unless you
obtain the additional Mike11 (actually the modflow packages RIV and STR don't simulate river
flow; you need the modflow variant GSFLOW to simulate river flow). If using feflow without
Mike11 there is no direct way to account for the flow in the river, so people most commonly use
either a cauchy (3rd) kind or head (1st) kind to simulate the groundwater component. The 3rd
kind is similar to modflow's River package. Setting of the observation (20 l/s) would be similar
to modflow; you set up a reference group that records the flow from/to the river nodes. With
feflow you have the added ability to constrain the flow such that it cannot gain and/or leak more
than a specified amount.
* It is important to distinguish between transient and steady-state analysis. If you are calibrating
a steady-state groundwater model to annual average stream baseflow, then yes it is probably a
waste of time to include a river model. However, river flow rates are inherently transient and
groundwater-surface water exchange is not a linear function of water depth. The river bed area
changes significantly and very non-linearly with flow. Calibrating to actual transient river levels
allows you to calibrate groundwater processes such as bank storage and near-stream infiltration
that depend on groundwater parameters (e.g. K in the top groundwater layer) that deeper
borehole observations are not very sensitive to. So, including rivers in a more realistic manner,
can indeed improve your groundwater model. The resulting model is more robust with respect to
scenario analysis were baseflow conditions may be substantially different.
* You seem to be implying that one should ignore the baseflow data, which not a good idea.
Perhaps I misunderstand you. Perhaps when you claim that "It certainly wont make the
groundwater component any more accurate" you mean that from the stream's point of view
nothing will be gained. However, from a groundwater perspective, including the baseflow
component of the stream flow as an observation in a groundwater model for calibration purposes
is not a waste of time. In fact, its rare that one has such data at the right scale, and in my
experience the baseflow data can be more important that groundwater level data depending on
the focus of the model. Calibrating the model to the flux to/from the stream will make the
groundwater model more accurate (assuming the modeling is done correctly).
The STR package of modflow routes the stream flow only. The only benefit of using it is that
the model "knows" when the river is dry, so that flow from the river to the aquifer is zero. The
RIV package of modflow ignores this and assumes that there is always flow in the river. If the
river never dries up or there is no reason to think it would in a simulation, then there is no point
in using STR (is that your point?). One must consider the modeling objectives, scale of the
problem and the data available before selecting and implementing a fully-coupled groundwatersurface water model.
* Yes, I think you misunderstood my point. I am not suggesting that the observed streamaquifer should be ignored. I am suggesting that one shouldn't bother with a streamflow-routing
package/add-on unless it is truly warranted by the modeling objectives. I think we are saying
the same thing.
* Depending on the version of MODFLOW you are running, it should be relatively straight
forward to import the MODFLOW-2000 (or later) data files generated by GWVistas in to a
Visual MODFLOW model. If you are running MODFLOW-96 or earlier versions of
MODFLOW, then it won't be so straight-forward and some information may get lost in
translation if the model has confining layer types. One thing to note is that Visual MODFLOW

will not import the Stream or Flux boundary package data sets for editing in Visual
MODFLOW, but if you have the original data files, Visual MODFLOW will recognize they are
present in the project folder and include them with the computation.
* The amount of impact on the river from the mine does not matter. What matters is where the
impacts occur. If the model is too small, the model will predict that all of the impact occurs at
its boarders. The model should be large enough that most of the groundwater drawdown occurs
inside the model domain. Beyond this size, it won't matter much what type of model you use
because the model will only simulate groundwater impacts where drawdown occurs. Outside
the area of drawdown, users located downriver will see a net impact on river flow of 20 l/s, and
there will be no further impacts upriver.
* If the excavation will become a "pond" or surface water impoundment, then you can simulate
the recovery by specifying a K that is 100 to 1000 times greater than the K of the surrounding
material (easier), or you can use the lake package (more difficult and perhaps not more
accurate). If not an impoundment, then your options depend on what happens to the excavation
in the future. Drain elevations can change with time.
* The conductance should be set to the hydraulic conductivity of the riverbed material
multiplied by the product of the length and width of the river reach in the cell divided by the
thickness of the riverbed material.
* Whether the conductance value is equal to bedrock may not be important if you have target
flows to match or other calibration considerations.
* Oscillations are common especially in complex models; whether they are important depends
on the whether the oscillations decrease to values small enough to be of no concern and also if
the mass balance of the model is acceptable (e.g. small compared to total inflows and outflows).
* There are problems of stability. You should check the model before running it. I suggest a
couple of checks: at first run the model in steady state and check if it converges and that the
balance (IN-OUT) is fine for your problem, otherwise you have to control your input, the
number of layers vs deep, mesh etc. then I would rehash the steady state solution and I would
run the new model in transient condition if that does not work, I would check again the mesh
near well points and verify how the model works without wells.
* Can I use a Multi-Stage Pump test to determine the hydraulic conductivities of the aquifer,
with MODFLOW, using a three dimensional model domain? I want to do it in that way to take
into consideration the faults and conduits effect - Yes, as long as the conduits and faults are
saturated, MODFLOW may be used, but you might end up with a very large model depending
on how the system must be discretized to accurately represent necessary processes. FEFLOW
would be a better choice.
* Would look at your .lst file and see if the simulation completion. Check at the very bottom of
this text file to see if you are given a budget for the last period of the simulation. If you do that
means that there is an error in the output control and you are not saving to a file with extension
.out. Open the text files with extensions .oc and .nam. At the top of the .oc for: HEAD SAVE
UNIT 45. Only the number is going to be different. Find that number in your .nam file and it
will correspond to the file with your output.
* Model without boundary conditions
(a) I tried this without boundary conditions and with different boundary conditions. It is a great
learning experience. The whole model depends on boundary conditions. If we do not know the

real hydrogeological conditions of the area and with out much field experience, the model would
fail. I see many models prepared by simple computer experts, who do not understand the
underlained hydrogeology giving funny results, where in the water table contours crossing hills
etc.
(b) Normally any model has a default NO FLOW boundary conditions if you create a model
without having B.Cs.
(c) Your model boundaries may be far away from the pumping wells, but a groundwater model
still needs boundary conditions. This is a condition both of the numerical solution and the
underlying differential equations. Setting boundaries far enough from the region of interest so
the boundary conditions do not affect the solution in that region is one way to minimize the
errors that can occur from imprecise knowledge of those boundaries.
(d) The default boundary condition at all lateral boundaries, including top and bottom, of any
model is no flow. It is impossible to build a model without BCs. In your setup, the wells are
also BCs. If your model has no flow cells at the top and bottom, and the wells are the only other
BCs, your model will behave as follows: (1) If the sum of the pumping at the wells extracts
water, the model will eventually dry out; (2) If the sum of the pumping at the wells injects water,
water levels will increase indefinitely. In either case, if you try to run in steady state the model
will probably crash or may not run at all.
(e) 1. The wells are boundary conditions.
2. If this is a steady-state model, there is no source of water for the model so the model will be
unable to find a solution.
3. If this is a transient model, the heads will never reach a steady state because there is no source
of water for the model.
(f) Since there is no water being added to the model (no recharge, no flow boundaries) then the
model will eventually go dry. There needs to be some source to counterbalance the water being
withdrawn. The transient case may work for a while until drawdown starts intersecting the
distant no-flow boundaries, then things will definitely not reflect reality.
(g) Having a model without boundaries is a bit like sustainable mining or sustainable landfilling
(an oxymoron).
(h) I agree that wells are a BC. But I don't necessarily agree that the transient model has to reach
a SS condition. If you wish to model the extraction rate and have what you consider to be no
flow boundaries at some distance and wish to know how long water from storage will fulfill
your extraction requirement, then this sounds like a legitimate setup. But it is critical that you
have realistically modeled the distance and reality that those BC are no flow so that if the
drawdown hits those boundaries, you have a realistic timeframe for extraction (or, life of
wellfield is realistic).
(i) As currently configured, the long term drawdown depends on the size of your model and the
storage coefficient (or specific yield if the confined aquifer is allowed to become unconfined)
you specified. The model will eventually dry out and will crash if run long enough (some codes
allow heads to decline indefinitely in which case the precision of the model code will govern
just how low the heads will go, then the model will crash). Prior to complete dryout of the
model, as long as the water balance is sensible, the drawdown simulated by the model is OK.

The deep confined system: the water came from somewhere. The recharge source may be
outside your model domain, so you should specify the inflow at SE boundary that accounts for
the recharge (Tim Glover's suggestion would work). You should specify a corresponding
outflow too (NE boundary). From your notes, the SE head = 200 and the NE head = 100. Run
the model in steady state without wells to get a initial water levels for the follow-on transient
model with pumping.
There may be significant vertical leakage across confining beds especially near the wells which
you may want to include in your model.
Check the change in flows at NE and SE boundaries over time. If larger than expected, perhaps
your model is not big enough or you may choose to limit inflow and outflow using Cauchy BC
(MODFLOW General Head Boundary). In the current model, you are simulating one endmember that predicts maximum drawdown at the wells. Constant head will simulate minimum
drawdown and drawdown with GHB will be somewhere in between. Which approach you use
depends on the goals of your project.
(j) Assuming you are using MODFLOW, and assuming the model boundaries are far enough
away from the pumping so as not to significantly affect regional gradients at the lateral
boundaries, you could set up the boundary conditions at the upgradient and downgradient sides
of the model using either:
Constant head: assumes infinite source (or sink) of water to maintain the head
Constant flux (entering the upgradient side, and leaving the downgradient side): assumes infinite
source (or sink) of water to maintain the gradient required to drive the flux
General Head: allows head and flux to fluctuate in response to the modeled system
If you do not specify any source of water entering the model via one of these mechanisms, then
the model will eventually blow up.
* If you run MODFLOW-2000 with the sensitivity process you can generate grid sensitivities
and contour them. This will indicate which areas of the model have more/less sensitivity to
particular parameters. But this will not account of the observations that you are already using to
calibrate the model. OPR can account for this and can tell you which observations are important
for a particular model prediction (and which ones are not so important). Then you can focus
your sampling efforts on the more important observations.
Some disclaimers - this is a linear approximation of a nonlinear process; the results are based on
your model representation of the system- that is, a different model of the system (different
assumptions, different boundary conditions, etc.) might indicate different observations are more
important...).
* Solving the flow equation gives you 1. head (i.e. pressure). From head you can also calculate
2. Darcy velocity (by Darcy's law) 3. moisture content (according to unsaturated zone curves).
Depending on the form of the transport equation you are using, head, Darcy velocity and
moisture content appear in the transport equation. If the flow is density dependent, the flow and
transport equations are coupled both ways, because density (which appears in the flow equation)
is a function of concentration (which is the solution to the transport equation).
* Visual MODFLOW is a graphical user interface that has implemented the USGS MODFLOW
engines to run the flow model simulations. Visual MODFLOW takes the model inputs

(boundary conditions, properties etc.)assigned and translates those inputs into MODFLOW
format files, then runs the simulation using the MODFLOW engine. The outputs are then
displayed in Visual MODFLOW.
You may want to ensure you were provided with a copy of the translated files - the MODFLOW
input files that was generated by Visual MODFLOW. If you are using MODFLOW 2000, you
will also want to ensure the MODFLOW input flow files you have are in MODFLOW 2000
format (not MODFLOW 96).
The *NAM, *DIS, *BCF, or *LPF, and *BAS files are an example of some of the MODFLOW
input files you will be looking for. Depending on the project inputs there will be a variety of
other input files to be used.
For a list of the numerical model input files for MODFLOW you may want to check the USGS
MODFLOW 2000 document at: http://water.usgs.gov/nrp/gwsoftware/modflow2000/ofr0092.pdf
The *CLB file is the MODFLOW calibration output file; *WHS is the WHS solver data file and
*NDC is a PEST file. Visual MODFLOW also supports importing MODFLOW 2000 flow input
data sets to open an existing MODFLOW project in Visual MODFLOW.
* As far as XP vs Vista goes, I doubt you will see much difference between them in terms of
how Argus ONE, MODFLOW, or SUTRA perform. However, getting a dual processor system
can be helpful even though the programs are single-threaded because when the models are
running, they tend to take up a lot of processor time. If you only have one processor, anything
else you try to do at the same time might be very sluggish. If you are going to run long transient
simulations, a large disk drive will be helpful because the output files can get very big. This is
especially true if you want to do solute transport using MT3DMS because MODFLOW has to
write a file containing all the flows in every time step. That file is used as part of the input for
MT3DMS.
I'm running Argus ONE on a Windows XP Professional laptop with a dual 2 GHz processors
and 4 GB of RAM. I've never had problems running Argus ONE on this system. You can
certainly get by on less than that. On 32 bit operating systems, 4 GB is the maximum amount of
memory that the computer can use. The operating system uses some of that memory so, in
practice, there is less memory than that available for programs. With a 64 bit operating system
with more than 4GB, 32 bit programs can use up to 4GB of memory because they don't have to
share it with the operating system. That is true for both XP 64 and Vistas 64. Argus ONE,
MODFLOW and SUTRA are all 32 bit programs so they can't use more than 4GB of RAM. (It
might be possible to recompile MODFLOW and SUTRA to be 64 bit programs. However, I
advise against trying to do that unless you really have a pressing need and are willing to invest a
substantial amount of time and effort in the process.) Argus ONE will run on 64 bit operating
systems but unless you are running really large models, you are probably better off just getting a
32 bit system.
* You might also want to consider purchase of an external hard drive. They are very
inexpensive these days. I usually dedicate one to each model project. Keep the latest run on the
main drive, for speed. But then offload the previous run to the external drive. This also gives
you redundancy in case you need to revert to a previous run, but you do not lose a month's work
if things crash.
* Switching to MODFLOW-2005 is unlikely to help. Try changing WETDRY to a a larger
value.
The following is copied from the help for the MODFLOW GUI

Stability Problems in MODFLOW

Use of the wetting capability (first implemented in BCF2 and retained in BCF3, BCF5, LPF and
HUF) can result in non-unique solutions because the head in a cell must be higher than some
wetting threshold. If a cell starts off wet, it can remain active even if the head drops below the
wetting threshold. However, if it starts out dry, it may not be wetted because the head in the
neighboring cells may be too low.
Use of the wetting capability can cause serious problems with convergence. You can try to avoid
this by several methods.
1. If you know a cell should never become wet, make it an inactive cell rather than a variable
head cell.
2. You can adjust the value of the wetting threshold in WETDRY. (Higher is more stable but
may be less accurate.)
3. You can decide which neighbors will be checked to decide if a cell should be wetted using
WETDRY. Often it is better to allow only the cell beneath the dry cell to rewet it.
4. You can use IHDWET to determine which equation is used to specify the head in newly
wetted cells.
5. You can vary the wetting factor WETFCT.
6. In steady-state conditions you can adjust initial conditions to values that are close to your best
guess of the final conditions to improve stability.
7. You can choose a different solver. The SIP, PCG1, and PCG2 solvers will work with the
wetting capability. The SOR solver doesn't work well with the wetting capability. Note that cells
can not change between wet and dry during the inner iterations of the PCG1 and PCG2 solvers.
The PCG1 solver is no longer included in the USGS version of MODFLOW and is not
supported by the MODFLOW GUI.
8. When using the PCG2 solver, you can set RELAX in the range of 0.97 to 0.99 to avoid zero
divide and non-diagonally dominant matrix errors. (However, this is an infrequent cause of
instability. If such an error occurs, PCG2 prints an error message in the output file and aborts the
simulation.)
9. When using the PCG2 solver, you can set DAMP to a value between 0 and 1.
10. Unrealistically high conductances on boundary cells can contribute to instability. Check the
conductances in the Drain, Drain Return, River, Reservoir, Lake, Stream, Streamflow Routing
and General-Head Boundary packages. In the Evapotranspiration check the EVT Flux Stress[i]
and EVT Extinction Depth which together control the conductance of evapotranspiration cells.
11. Run a steady-state model as transient so that cells go dry in a more orderly fashion. You
would obtain the steady-state solution by running the transient simulation for enough time steps
to cause the storage budget term to approach 0.
The two most important variables that affect stability are the wetting threshold and which
neighboring cells are checked to determine if a cell should be wetted. Both of these are
controlled through WETDRY. It is often useful to look at the output file and identify cells that

convert repeatedly from wet to dry. Try raising the wetting threshold for those cells. It may also
be worthwhile looking at the boundary conditions associated with dry cells.
Sometimes cells will go dry in a way that will completely block flow to a sink or from a source.
After that happens, the results are unlikely to be correct. It's always a good idea to look at the
flow pattern around cells that have gone dry to see whether the results are reasonable.
* In general, "one well per cell" -- just add the flow amounts. The "dry cell problem" probably
has to be addressed in stages; start your model as steady-state and then expand upon that to get a
transient system that works and then make the pumping amounts more realistic. Details with
time steps and solvers do matter, solve them by going from simple systems to more complicated
in small steps. The documentation to all versions of MODFLOW have examples of applications
(most include wells).
* MODFLOW allows more than one well per cell. MODFLOW will do the adding for you.
* You can use the IBOUND array to designate any cell as an inactive cell.
You could use ModelMuse to do the river calculations for you. You would just draw lines to
define where the rivers are and set the conductance per unit length. ModelMuse can figure out a
separate conductance for each cell based on how much of the line intersects each cell.
* MODFLOW does not model solute transport just groundwater flow. Far a basic model, you
could use MODPATH in conjunction with MODFLOW to track advective transport.
1. As best you can, determine the geometry of the aquifer(s) into which the water will be
injected and the relevant properties of the aquifers such as hydraulic conductivity.
2. Identify discharge locations for the aquifers if any. Model them as constant head cells, rivers,
or drains as appropriate.
3. Estimate the recharge rate.
4. Use a steady-state stress period for the first stress period to determine predevelopment heads.
5. If needed, add additional transient stress periods for wells or other changes prior to the
introduction of your injection wells
6. Add your injection wells. Use MODPATH to track the movement of water into and back out
of the aquifer. You can use Model Viewer to visualize the results.
MODPATH does not model dispersion which might or might not be important for your
application. If you need to model dispersion, you can use GWT or MT3DMS. However neither
of those is currently supported by ModelMuse. if you decide you need to model dispersion, you
can use PHAST which is supported by ModelMuse. It can also do more chemistry than you are
ever likely to need should that eventually prove to be important.
* To the best of my knowledge, no GUI yet exists for the Conduit Flow Process. I'm not sure
which version of MODFLOW PMWIN supports, but if it is MODFLOW-2000, then you
probably would just have to add the input file for the Conduit Flow Process to those created by
PMWIN and then add it to the name file. If PMWIN only supports MODFLOW-96, then you
would have to convert them to the form used in MODFLOW-2000 or MODFLOW-2005. There
is a program named mf96to2k.exe distributed with MODFLOW-2000 that can do the
conversion.
To create the input file for conduit flow process, you will need to carefully study the format for
the Conduit Flow process input file and create it with a text editor. You might also want to look
at the other input files for MODFLOW that PMWIN creates and compare them to the
documentation to see examples of how the files are organized. Online documentation of the

input files is available at

http://water.usgs.gov/nrp/gwsoftware/modflow2000/MFDOC/index.html.
* Is the pollution source associated with a source of fluid such as a constant-head boundary or a
well. If so, the source can be simulated in GWT by specifying the concentration associated with
the source.
If the pollution source is not associated with a source of fluid, you can use MT3DMS instead of
GWT and in Data Set D8 specify ITYPE = 15.
"For a special type of sources (ITYPE = 15), CSS is taken directly as the mass-loading rate
(MT^-1) of the source so that no flow rate is required from the flow model."
* You might be able to use PHAST to model the leaching.
http://wwwbrr.cr.usgs.gov/projects/GWC_coupled/phast/
http://water.usgs.gov/nrp/gwsoftware/ModelMuse/ModelMuse.html
* It sounds like a problem with rounding error. If so, it could help to identify locations where
there is a high contrast in hydraulic conductivity between adjacent cells and then put a cell with
intermediate hydraulic conductivity between them.
* Large volume balance error can result in a situation like this when the conductance is so large
that the difference between the river stage and the calculated head in the cell is small-approaching the head closure criterion. Very small changes (< the closure criterion) can then
result in large changes in flow to/from the river cell because of the large conductance. An
alternative in a situation like this is just to use constant-head cells instead of river cells.
* You may want to use a constant head rather than a river boundary where conductance is
expected to be high. If you do use river cells, you can interpret the conductance in more than one
way. If the conductance of the riverbed itself is considered to be the limiting factor in
determining leakage between the river and the ground-water cell, then in the formula
Criv=KLW/M, M is the thickness of the riverbed and K is the hydraulic conductivity of the
riverbed.
If the conductivity of the riverbed is assumed to equal the conductivity of the aquifer material
represented by the cell, then M (as you suggest) would be the distance from the river bottom to
the center of the cell and K would be the aquifer hydraulic conductivity. Generally, I would
think it would be appropriate to use the vertical distance between the river bottom and the cell
center as M, although some situations may call for using an alternative value for M. M might
equal 1 if the cell thickness is 2, but otherwise, I do not see the logic of assuming M equal to 1.
* With regard to #5, a common way to model a discontinuous horizon is to treat only part of the
layer as representing the discontinuous horizon. The remainder of the layer can be used to
represent part of the horizon above or below the discontinuous horizon. In the text below, each
line represents a model layer and each different number indicates which horizon it is part of.
Horizon 2 is discontinuous so in the places where it is absent, horizon 1 is split between two
different model layers. There is no need to make the part of horizon 1 that is in layer 2 have a
thickness of zero and personally, I would be leery of doing that. I also would not make those
cells inactive because that would prevent any vertical flow between horizons 1 and 3.
11111111111
11111222222
33333333333

Another way is to use the Hydrogeologic Unit Flow (HUF) package.The HUF package might
not be supported by Processing Modflow. If I remember correctly, your version of Processing
Modflow is for MODFLOW-96 whereas the HUF package was first introduced in MODFLOW2000. If you wanted to use HUF, you could consider switching from Processing Modflow to
ModelMuse as your graphical user interface for MODFLOW.
(http://water.usgs.gov/nrp/gwsoftware/ModelMuse/ModelMuse.html)
With regard to #6, you do not need to make the cells smaller just to match the dimensions of the
drain. The dimensions of the cell have no effect on the amount of flow through the drain. The
amount of flow is determined by the difference in head between the cell and the drain and the
conductance of the drain. However, speaking of conductance, how are you calculating the
conductance? Be sure to read the section of the MODFLOW manual where conductance is
discussed. The dimensions of the drain (not the cell) are used in calculating the conductance and
that calculation is done by the modeler outside of MODFLOW. While there is no need to refine
the grid to match the dimensions of the drain, refining the grid, might (and might not) help with
the model convergence.
With regard to model convergence, it sounds to me like too high a conductance in the drains
may be the cause of your convergence problems. I suspect that what happens is that one one
iteration the water level is high enough for some of the drains to be active. However, the flow
out through the drains is so high that on the next iteration, the water level drops below the
bottom of the drain and they shut off. That allows the water to rise above the drain elevation on
the next iteration. If that is the case a lower drain conductance might help. You could also try
varying the DAMP or RELAX parameters in the PCG package or the ACCL parameter in the
SIP package. Try looking at the locations of the cells that PCG reports having the highest head
change or flux residual and see if those are drain cells.
With regard to #4, typical ways of assessing the quality of the model would be to compare both
the heads and fluxes to observed values. Heads alone often do not have enough data to
distinguish between models with high flux and high hydraulic conductivities and models with
low fluxes and low hydraulic conductivities.
With regard to #3, the percent discrepancy in your model is far too high to be acceptable. You
should get it below 1%. Note however, that although a percent discrepancy greater that 1% is a
clear sign that a model isn't working, a percent discrepancy less than 1% doesn't guarantee the
the model is OK.
* I suggest using the hydraulic conductivity of the aquifer in calculating the drain conductance
rather than the hydraulic conductivity of the pea gravel because the hydraulic conductivity of the
aquifer will likely limit the amount of water that can leave through the drain. The length of the
cell is probably a good first-order estimate of the length of the drain required for the calculation.
Drains are not required to be all in one layer.
With regard to the error message from SIP, I think that means that one or more cells are
completely surrounded by inactive cells. A cell can become inactive if the head in the cell drops
below the bottom of the layer. Only cells in convertible or unconfined layers can become
inactive.
* If the water table rises as much as you think it will, will this cause some cells that are dry
initially to become wet? If so, you will need to have the wetting option active in MODFLOW
and set the WETDRY data set appropriately. You may also wish to consider using a different
solver. The PCG solver is generally preferred over SOR.

* I would use Surfact for the recovery prediction for the reason that Richard explained (dry
layers/cells may become saturated). But keep in mind that the initial heads you would use must
be consistent with the engine you use. In other words you have to re-run with surfact the
previous models to get the initial heads that are compatible for future simulation using surfact.
* It is important if you are running a transient simulation dealing with a confined aquifer. For
unconfined aquifers you have to assign the specific yield (Sy). These hydraulic parameters have
to be calibrated but you can get some initial values from pumping tests if available. The
sensitivity of the models with the Ss or the Sy is very important. Depending on what you are
simulating but it can change a lot the volume of storage (in and out) in your model. Especially
dealing with dewatering, a model can give you different results.
* It shouldn't be a problem if the river bottom or river head is below the bottom of the cell so
long as the cell doesn't go dry. However, you could put the river in the next layer down instead
of layer 1. If the cell goes dry, the river will no longer be part of the model and will no longer
contribute to the water budget. In the SFR package, you can specify that a stream is in the top
active layer for the particular row or column containing the stream reach. If you are concerned
about the river cell going dry, you could consider using SFR instead.
* In specified head cells in convertible layers, the initial head must be above the bottom of the
layer. Other active cells in convertible layers can have initial heads that are below the bottom of
the layer but they will immediately convert to inactive cells.
* Zero concentration gradient (if that is what you want to simulate) implies the constant
concentration should be .0001 kg/m3 or that the initial background concentration is really .0006.
Also, the amount of mass coming in depends on the length of time step. Long time steps can
cause large numerical dispersion (but this also depends on cell size and rate of water movement).
* To simulate vertical gradients better, more layers will be needed. If the vertical elevation
changes in the model are very large, it may be better to simulate the system using many
constant-elevation layers rather than layer of varying thickness and elevation. Transient
simulation would also reduce dry-out problems, as wells as using a model that simulates the
water table more realistically.
* If you are working in Visual MODFLOW, my suggestions are given below:
Problem 1. Dry cells on higher topography: What boundary conditions you were assigned? If
it is River head or General Head or Constant head, the bottom of cell elevation (1st layer) should
be lesser than the constant head values, and To avoid the dry cells in your model you can use
Cell wetting threshold for transient simulations.
Problem 2. For your 2nd problem that you mentioned, you can assign suitable boundary
conditions for second layer, and you mentioned that you are expecting higher flow at where the
two reefs and few dykes and faults are intersecting. Here you may assign different zones that
yields different amount of water to the aquifer, hydraulic conductivity for different zones and
prefer constant heads boundary at expected locations water inflow in intersection regions.
* I suppose the weathered layer has a much higher conductivity than the rest of the underground.
That would mean that it remains saturated, even if you do some mining activities in the less
permeable deeper part of the mountain. First begin with a model only containing the weathered
layer and some other layers underneath. Give the weathered layer a thousend times higher
permeability than the other layers. Prescribe the head at the weathered layers boundaries. Do
You manage now to keep the weathered layer saturated? If not, then you must forget saturated
modelling. If it works, the You can introduce the mine. Do not lead the mine to the weathered

zone. Prescribe a head in the mine that is above the ceiling of the mine to achieve saturated
conditions. If this works You can begin playing around with faults and dykes. But do not expect
too much from your model.
* E-L codes are subject to numerical dispersion: the partly arbitrary logic that governs particle
handling, e.g. when a clean cell should be populated with particles due to dispersive transport,
and how many to "create" in that cell. My experience with E-L is with MT3D MMOC, HMOC,
etc. I've heard modelers complain about problems at boundary conditions with E-L, so there
might not be a programming error, it might be numerical dispersion. If you can switch to nonEL method, that might be helpful. You can also set dispersion to zero to cut dispersion out of
the equation as a check.
* MODFLOW does not place any limits on the dip of a model layer. However, MODFLOW
also does not account for the dip of beds when calculating the conductance between cells. For a
bed dipping 40 degrees, the conductance might be 25% less (1 - COS(40 degrees)) if the dip
were taken into account. The uncertainty in hydraulic conductivity could easily be more than
this.
* I just finished my project work recently (master's project) and I had a physical model. In the
physical model, the biggest K value is 1m/s and the smallest K unit is 10E-7m/s. I think the
problem is, with such extreme values, when I simulate solute transport using MT3DMS, it will
appear negative values, even I modify the time step size and the concentration criterion closure.
So, because of the existing extreme values, the codes may become unstable. This is my
experience with PMWIN. And also, MODFLOW is sensitive to the extreme values. You can try
use different solvers. I also have an experience that sometimes only MIC package can solve the
flow problem while SSOR may be not.
* Modelmuse is a very good way to do your modeling. But regardless of the GUI you use, the
river conductance value is something you can not practically know. (ie. you can not practically
do an insitu test of riverbed sediments to find the right value) You have to try different values
until your model calibrates. So you must have some ground water level field data in the area of
the river to use in order to find the correct conductance value. If you don't have any real field
data near the river you will be guessing and you will not know if you model is correct.
Start with a conductance value that results in less flux from the river to the formation than you
would get if you calculated the flux using the hydraulic conductivity of the underlying
formation. It is a value you must calculate and input. Then keep reducing it until your modeled
groundwater levels calibrate with the field data. The conductance term should never yield more
flow from the river than the underlying formation K would allow.
* The river bed is the material that separates the water in the river from the underlying aquifer.
The river bed would typically be saturated so the river bed is not the same as the unsaturated
zone.
I'm not sure I understand your second question but it sounds like the problem is that the heads
are unrealistically high. In some cases, this is due to the specified recharge rate being higher
than the rate at which water can actually flow into the aquifer. Some modelers have dealt with
such situations by including drain cells at the ground surface elevation over the entire top of the
model. Then, if the recharge rate is too high in a cell, the extra water is removed by the drain
cell.
* Convergence problem - It could be any number of things. Dry cells, head/layers elevations,
etc... If using PMWIN, a good way to check is the 'Check Model' tool. This highlights any

problems in terms of the grid geometry, e.g. layer elevations vs hydraulic head, e.g. head in cell
xx, xx is lower than the layer elevation...
The quickest and easiest way would be to change your solver settings (e.g. PCG solver).
Increase your convergence criteria values (head change and residual), that should help. I would
advise you don't go any higher than 1, 1 as the simulations will start to become less accurate, but
are helpful as it will at least allow you to run the model.
If the model still fails to converge, check your maximum residuals listed in the output file. They
will be high in the cells that are causing you dramas and you should be able to see if you can
pin-point the group of cells that may be causing you dramas.
* To calibrate the model, you might have to change/calibrate:
1) hydraulic parameters (in Steady State K only)
2) recharge rates
3) evaporation rates
4) boundary conditions: CH, GHB, River and so on
* You should simulate the spring with the drain package, calculate the volumes you get from the
drain and compare them with the measured volumes from the existing spring. If the two volumes
(calculated and measured) are pretty muche the same with a reasonable difference, it means that
your model is not that bad :) If not you have to calibrate the model to match the volumes.
* Ss and Sy are not necessary for steady state simulations.
* If the head is changing during your observation period, try to find whether it is possible that
the soil aquifer become confined/unconfined. And if the contaminant is not NAPLs, maybe
sometimes should consider the density effect in unsaturated zone. But I dont think MODFLOW
can deal with the situation that density flow in unsaturated zone. Try to simplify the
physicochemical procedure.
* You would need to use a calibration program such as UCODE or PEST. Both programs work
in similar ways. You instruct the program how to replace parameters with new parameter values
and how to extract the simulated equivalents of your observations from the output. Then the
programs run MODFLOW repeatedly with different parameter values in an attempt to find the
optimal parameter values to match your observations. You will need to generate the input for
UCODE or PEST outside of ModelMuse.
* The LIST and GLOBAL files are the output files produced by MODFLOW. The DIS package
contains the model discretization (spatial and temporal) info and the BAS6 file contains the
Initial conditions and some of the boundary conditions. The online guide to MODFLOW has
most of the information you are looking for like formatting and variable descriptions.
http://water.usgs.gov/nrp/gwsoftware/modflow2000/MFDOC/index.html
I believe the documentation has a number of test problems that could use. Also, as you may have
realized notepad is not good enough to view large files. So you may want to use a more heavyduty text editor that is compatible with linux. I use textpad on windows but any good editor
would suffice.
* You always need to list in the name file:
LIST (or GLOBAL, or both. Starting out, just use LIST)

BAS6
DIS
A flow package (one of LPF, BCF, or HUF2)
A solver package (one of SIP, DE4, SOR, PCG2, or GMG)
Other files are listed to activate stress packages or if you want to provide array data in separate
files or to use various other options. In general, prepare all input files as ASCII text files.
Spreadsheet files in their native format will not be read correctly. Your text editors should be
able to "Save As" in ASCII. The line-ending convention is operating-system dependent...use the
native convention for your operating system. For most predictable results, do not use tab
characters; separate input values with spaces.
Formats for numeric inputs vary, but most input can be in "free" format if you specify the FREE
option in the Basic Package (BAS6) input file. In the MODFLOW-2000 distribution, the test-run
directory contains test data sets, which you may find instructive. For getting started in
MODFLOW-2000, you also may find MFI2K useful, although it only runs under Windows.
Find MFI2K at http://water.usgs.gov/nrp/gwsoftware/MFI2K/MFI2K.html
* As others have suggested, you might find ModelMuse helpful.
http://water.usgs.gov/nrp/gwsoftware/ModelMuse/ModelMuse.html
The Global file is not required. You can use the global file with MODFLOW-2000 but not
MODFLOW-2005. When transferring text files from Windows to Linux, you need to make sure
that the line endings get converted properly because Windows and Linux use different
conventions for marking the end of the line. EditPad Lite is one program that can make the
conversion for you.
http://www.editpadlite.com/
It is important to set the Options data set in the basic package properly. Of you include "FREE"
in the options you can use free format for most of the data in MODFLOW. Otherwise, most of
the numeric fields are 10 spaces long.
* I will have a look at model muse. Maybe it is better than the PMWIN GUI i am using at the
moment.
>Also, as you may have realized notepad is not good enough to view large
>files. So you may want to use a more heavy-duty text editor that is
>compatible with linux. I use textpad on windows but any good editor would
>suffice.
I think you misunderstood me. I am already using a "heavy duty" editor (notepad++ in my case),
but the problem seems to be that this editor is "intelligent" enough to read about any file
correctly, no matter which operating system or program it came from. Windows stock notepad
however does often show "artifacts" such as missing line breaks, and those files are the ones i
run into trouble with in modflow/PMWIN.
> When transferring text files from Windows to Linux, you need to make
> sure that the line endings get converted properly because Windows and
> Linux use different conventions for marking the end of the line.
> EditPad Lite is one program that can make the conversion for you.

http://www.editpadlite.com/
Yes, i think that might be one of my problems. However Matlab on windows can also produce
files that wont get read correctly. So i will have also to look into tab vs. space, and if they are
encoded in ASCII.
> It is important to set the Options data set in the basic package
> properly. Of you include "FREE" in the options you can use free format
> for most of the data in MODFLOW. Otherwise, most of the numeric fields
> are 10 spaces long.
I guess this has to do with the fact that modflow is written in Fortran? From the documentation i
have read so far, it seems like it is assumed that people who want to use Modflow are fluent in
Fortran.
So if I understand this correctly, with nonfree format every value hast to use a field of ten spaces
length. That means "1" would become "space space space space space space space space space
1" and "10000000000" "10000000E3", whereas free format would simply allow me to use "1"
and "100000000"?
* You are correct that with non-free format 1 would be written as "
1". However, if
1000000000 represents a real number rather than an integer it could be written as
"10000000000", "10000000E3", " 1.0E3", or a number of other variants.
* I would think MODFLOW will consider both the layer definition methods same. Using either
of the methods (10 layers or 1 layer discretized into 10) you are basically defining your 3D grid
geometry. MODFLOW obtains this 3D gird geometry from the DIC Discretization file. For
either of the two methods, ModelMuse will generate same DIS file, so it should not affect your
model results.
* When you divide up a single layer group into several layers, you aren't able to have the
individual layers vary in thickness in a way that differs from any of the other layers in the group.
For example, if you had a layer that was thick in the west and thin in the east and another that
was thick in the east and thin in the west, you wouldn't be able to do that using a single layer
group but you would be able to do it if each layer was a separate layer group. On the other hand
if you want layers of uniform thickness, that is easier to do by subdividing a single layer group.
* Choosing the constant boundary head - depends on your geology. If you have a constant head
boundary, such as a river or a stream whose waterlevel is changing seldom, you can consider it
as a constant head boundary. Suggest you to see some modeling books. Sure you can take
Kx=Ky=Kz if you dont know the media is isotropic or not.
* You should remember what the purpose of your modelling is. If you set all boundaries as
constant head, you remove any possibility to use the model to study different effects on it. With
constant boundaries all around you create a set flow field first, where usually modelling is used
to change the few known parameters to create a flow field which is aimed to be as similar to
reality as possible. You should also make sure that any 'disturbances' within the model domain
(e.g. groundwater abstraction wells) do not reach far enough to get close to the boundaries. In
this example, how far does the cone of depression reach? You can take kx=ky=kz, but often at
least kz is taken as 1 order of magnitude smaller if the geology is known to be of sedimentary
origin, which is often the case in groundwater modelling.
* Addressing the radius of influence having different value please try to

1) Extend the boundary to more than 2km from the well. Your boundary conditions will not
allow the well to have such a radius of influence.
2) Try to calibrate the hydraulic conductivity against the head measurements. The hydraulic
conductivity from the pumping tests gives a value of specific region and is not representative of
the model cell taken into consideration. Usually the hydraulic conductivity is lesser than found
during these pumping tests.
* I agree that constant head cells must be much further away. You should check different
distances when calibrating your model to make sure the constant head cells don't affect the
results. However, be careful when you adjust the K. Your best information is the real-life pump
test data. If you adjust the K in other areas of the model without other field-test data you are not
producing a defensible model. You can make the model match your data by various methods,
but that does not mean it will be true! Another thought......... if the model is over estimating
seepage from your canals and the sea, then it might give you a smaller radius of influence. Then
again it would give a small radius if the cells near the well went dry and it couldn't pump the
proper amount of water!
* I will suggest you that in case you river is in the middle of the model instead on one side then
you should take the river boundary condition into account. The river boundary condition is very
often treated as a calibration parameter which can be used calibarted to simulate the observed
heads. River boundary can release/extract water into the system depending on the river stage.
Calculating flux can be found in the journals. Also after each time step the water coming inside
the model or moving outside the model is calculated in the *lst file. This information can help in
calculating flux. The whole point is that you just cannot start making the groundwater
knowledge without having prioir knowledge of intial heads/boundary conditions/ groundwater
flow direction etc. Try to get the best information of the site and then start with making model.
* Based on what you have described, I would model this with five layers
Unconfined or convertible aquifer
Aquitard
Confined aquifer
Aquitard
Confined aquifer
I would ignore the bottom aquitard unless I thought that flow through that aquitard was going to
be important for my model results. If all the bottom aquitard does is to act as a no-flow boundary
with the overlying aquifer, I don't need to include it because the bottom of the model is
automatically a no-flow boundary in MODFLOW.
The biggest difference between a confined and an unconfined layer in MODFLOW is that in a
confined layer, transmissivity is a constant whereas in an unconfined layer, transmissivity is
calculated at each time step as the product of the hydraulic conductivity and saturated thickness.
The saturated thickness is calculated as the head in the aquifer minus the elevation of the bottom
of the layer. Because the elevation of the water table changes at each time step, the
transmissivity in unconfined layers changes at each time step.
A convertible layer is one that can switch between being confined or unconfined. The modeler
specifies the elevation of the top of the layer and if the head is above that elevation, the layer is
treated as confined and if the head is below that elevation, it is treated as unconfined.
Confined and unconfined layers also differ in how storage is treated in a way similar to how
transmissivity is treated but I won't go into that here.

For a more technical description of the differences between the various options, see the
explanation of LTYPE on the following web page
http://water.usgs.gov/nrp/gwsoftware/modflow2000/MFDOC/index.html?bcf.htm
I have copied the relevant potion below.
* 0 - confined - Transmissivity and storage coefficient of the layer are constant for the entire
simulation.
* 1 - unconfined - Transmissivity of the layer varies. It is calculated from the saturated thickness
and hydraulic conductivity. The storage coefficient is constant. This type code is valid only for
layer 1.
* 2 - confined/unconfined - Transmissivity of the layer is constant. The storage coefficient may
alternate between confined and unconfined values. Vertical flow from above is limited if the
layer desaturates.
* 3 - confined/unconfined - Transmissivity of the layer varies. It is calculated from the saturated
thickness and hydraulic conductivity. The storage coefficient may alternate between confined
and unconfined values. Vertical flow from above is limited if the aquifer desaturates.
* How to import initial heads without interpolation in Visual MODFLOW - One way is editing
the VIH (initial head file) file directly. You may need to do some testing and see how rows and
columns are counted in VIH as it is not documented in the user manual. Then you may need to
write a script (e.g. macro) to convert your initial head data into appropriate format. Another
simplier way is using Groundwater Vistas. Its import and export functionality is much better.
You can simply import you initial head data into Groundwater Vistas and then export it as a
head file. Then you can use the head file as initial heads in VIsual MODFLOW directly.
* That is all pretty easy using Model Muse the USGS's new free GUI for MODFLOW. You can
just choose which location(s) and which output file and it will show you the data for those
locations without sorting through the actual MODFLOW output files to find what you need.
* Steady-state model and transient model are different. In a steady-state model, the system is
assumed to be in equilibrium, which means there is no change in storage. In a transient model,
however, stoage changes with time. Therefore, a steady-state model does not consider storage
parameters (specific storage and/or specific yield) but a transient model does. You can
understand that as these two types of model are solving different euqations. Therefore, even with
the same setup, a steady-state model will not give the same result as the transient model does. As
you mentioned you have transient recharge too, which further deviates the transient results from
the steady- state results.
In general, the way I calibrate a model is by: (1) changing hydraulic conductivity (K) in the
steady-state model to match observed data (2) playing around with storage and recharge in the
transient model to see which parameter is sensitive to the model (3) changing storage and
recharge in the transient model to match observed data
One needs to realise that there are many ways to get the model calibrated. For example, K=10
m/d and Recharge = 100 mm/yr and K = 5 m/ d and Recharge = 200 mm/yr may give you very
similar results. Therefore having your model calibrated does not necessarily mean that your
model is correct. In fact, Mary Hill (author of UCode) stated that all models are wrong, but we
need to pick the ones that are useful. From my experience, it is very important that your model is
denfensible. Using the previous example, if you pick K = 5m/d and recharge = 200 mm/yr, you

better obtain some climate data and geological information to support why these values are
reasonable. Sometimes how you present/report your model is more important than how you set
up your model. A model is never useful if it is poorly reported.
By the way, calibration is a very time-consuming process. It usually takes up to 50%-70% of
time of a modelling project. You may consider applying for extension if you are running out of
time. Also, you may want to talk to your client/lecturer to see what they mean by calibrated.
Calibration is a never-ending process if you do not set up goals such as root-mean-square error
(unless you are using tools like PEST).
* According to the law of conservation of mass, ideally IN-OUT should be zero (i.e. the amount
of inflow should equal the amound of outflow). However, to put it in simple words, the
governing equation is hard to solve and therefore most current solvers use an iterative approach
to solve the equation. I assume you are using PCG solver, which is the standard in South
Australia (where I am from). The PCG solver keeps 'guessing' the solution until certain criteria
are met - the head change (Head in current time step - head in last time step) criteria and residual
(IN-OUT) criteria. If these criteria are too low (e.g. 0.00001), the model may not converge. If
these criteria are too high (e.g. 1), the accuracy may be insufficient. In your case, you may want
to decrease your head and residual criteria to get a better IN-OUT value. In South Australia, our
mass balance error must be <1% for all times.
* When ModelMuse creates the input files for MODFLOW-2005, one of the files it creates is a
"PVAL" file which contains all the parameters and their values. This file is the one that
UCODE would typically modify when calibrating a MODFLOW-2005 model.
* I'm not sure how visual modflow handles this but in MODFLOW, if you set the value of the
IBOUND array to a number less than zero, the cell will be a constant head cell and the head in
the cell will be the initial head.
* Currently there are no array variable option (such as $DX. $DY ect.) available to use initial
heads for assigning heads for boundary conditions. However you may consider creating a
contours of your initial heads after the import and assign your constant head boundary
conditions based on head contours in that layer.
* With the two-layer model, there are several new additions to the model that could affect
simulated drawdown:
~ if you use anything other than unconfined for layers, the layers with head above the top of the
layer are confined and behave according to the storage coefficient, not specific yield
~ vertical gradients are calculated in the two layer model that cannot exist in the one layer model
~ there could be abrupt changes in saturated thickness when upper layer cells dry out if the
model time-stepping or grid is too coarse
You might be able to get the two-layer model to approximate the one-layer model, but they will
never be exactly the same.
* That depends on several things, but layering is often introduced to account for
~ vertical anisotropy
~ heterogeneity
~ how the well was completed (multiple screens versus one or a screen that is open to only part
of the aquifer)

A one-layer model only simulates horizontal flow, an assumption that may not be realistic near
the well or at short times. If you are interested in long-term drawdown or or drawdown far from
the well, the one-layer model might suffice. If not, then a multilayer model is more accurate.
* It certainly sounds like ModelMuse is working but MODFLOW is not working. There are
several possibilities why MODFLOW isn't working.
1. The input is incorrect.
2. The compiled version of the program is incompatible with your hardware.
3. MODFLOW may not be running under WINE even though ModelMuse is running under
WINE.
The first thing to do in figuring out what is wrong would be to try to run MODFLOW with input
that is known to be correct. The MODFLOW executable for Windows comes with input files
for several models. I believe the UNIX source code also comes with those same example
models. You didn't say whether you compiled MODFLOW yourself or are using the Windows
executable under WINE. Whichever you are using, I suggest trying it out with input files from
both the Windows and the UNIX distribution. I think it is likely that the examples with the
UNIX distribution will work with a version you compiled yourself but that it won't work with
the input files from the Windows distribution. The input files from the UNIX distribution
probably won't work with the Windows executable run under WINE but should work with the
examples from the Windows distribution. The difference between the two sets of example input
files has to do with how line endings are defined in Windows and UNIX. The two operating
systems use different conventions and won't necessarily recognizing line endings if they are in
the wrong format. If you can get MODFLOW to run with at least one of the example input data
sets, that will prove that the compiled version of MODFLOW is compatible with your hardware.
If it doesn't run with any of the examples, than the compiled version is probably incompatible
with your hardware.
If you can get MODFLOW to run, the next step would be to determine why it isn't running with
the input generated by ModelMuse. If you are using a version of MODFLOW that you
compiled yourself on Linux, the line-ending issue may be the culprit. If you are using the
windows version of MODFLOW and you can get it to run under WINE, then the problem may
be that when ModelMuse tries to start MODFLOW it doesn't try to start it under WINE but
instead tries to start it as a native Linux executable. If that is the case, you may be able to get
MODFLOW to run if you start it yourself under WINE. Because ModelMuse is a Windows
application, there is no guarantee that you will be able to get it to work the way you want under
WINE.
* Into which graphical user interface are you attempting to import the Shapefile? (MODFLOW
itself does not have site maps or know anything about Shapefiles so you must be trying to import
it into a graphical user interface for MODFLOW). If you imported the Shapefile into
ModelMuse, select "Navigation|Go To..." and then select one of the objects that was imported
from the Shapefile.
* My experience (Groundwater Vistas) is that the best way to change boundary conditions is to
delete the current BC and add a new one. Somehow the program allways has more problem with
changing the BC than with deleting or adding something.
* I think that it's hard to simply change BC Type from Constant Head to Well. In first case you
have, indeed, an head information, while in the second you have a different one, a flux
information. I think that you have to delete an recreate the BC Type, To make this, you can
export CH cells in a shapefile, modify them easily by a GIS by adding a Column with Well
Flux, and then reimport like Well cells.

* In the river package, the river is considered as external to the model. Thus there is no cell
laterally adjacent to the river itself because the river is not a cell. The river interacts only with
the cell specified in the river package input file using the conductance specified in the river
package input file. There can be groundwater flow from that flow to other cells as determined by
the flow package (LPF, BCF, or HUF).
* Yes, multiple time steps can be necessary even if you are not interested in an intermediate
results. To understand why consider a simpler example. Suppose you wanted to calculate the
course of a projectile launched into the air at a 45 degree angle. One way you could do it would
be to look at the speed and direction of the projectile at a point in time and calculate where it
would be if it went in that direction for a short period of time and then recalculate it's speed and
direction. If you used a long time step, the calculated position of the projectile might end up
being too high - higher than the maximum elevation it could really ever reach. By using shorter
time steps, you would give you a more accurate calculation of the path of the projectile. You can
get a similar overshoot in MODFLOW if the time step is too long.
* Anything is possible when you don't have much calibration data to be concerned about, but
your results will only be as reliable as the uncertainty of the model input data, and in this case
the uncertaintly is considerable. Since you don't have any time-series of information, you will be
forced to prepare a steady-state groundwater model to try to match the few static water levels
you have. In this case you have a pretty simple setup with the surrounding water levels acting as
a fixed head boundary, and then you will be able to modify the recharge and hydraulic
conductivity values within pretty large ranges of reasonable values and still acheive a pretty
decent calibration. So the results you get from any predictive modeling of drawdown due to a
new pumping well will need to be bounded by the range of uncertainty of the R and K values.
* Without much data, it is possible to use large K and large R or small K and small R, and
achieve equally good match to your limited data.
* Of course, this is a generalization because I don't know anything about the subsurface
characterisation of the island hydrogeology or surface hydrology, but in general, with simple
unconfined systems, it is possible to use large K and R or small K and R to achieve similar result
water levels in the system. The reason this is important to recognize is because it can influence
dramatically different results when you are evaluating the potential sustainable yield of the
aquifer. Using low K and R would give you a very conservative estimate of how much water
you can extract, while using a large K and R would give you a very optimistic estimate of how
much water you can extract.
* If the time steps are uniform in length, there are no changes in the stresses, and the total
number of time steps is the same, it doesn't matter whether those time steps are part of one stress
period or several. The level of time discretization is problem-dependent; You would typically
make it finer until your simulated values of interest are no longer sensitive to the time step size.
If you stress periods are shorter than the critical length from Anderson and Woessner, you would
not anticipate needing multiple time steps. However, it would still be prudent to check and see
whether using multiple time steps affects the simulated values of interest.
* MODFLOW allows you to use columns and rows that vary in size. You can have one part of
the grid with rows and columns with small widths and other places where the columns and rows
are wider. However, it is best to avoid sudden changes in the size of adjacent rows and columns
because that can cause numerical problems. A ratio of 1.5:1 is typically cited as an appropriate
limit. The following link is for a video that shows how you could set up a refined grid for
MODFLOW using ModelMuse.

http://water.usgs.gov/nrp/gwsoftware/ModelMuse/GridTip4/GridTip4.html
* The storage in/out value will be higher initially when you start from an initial head far away
from the real initial heads of the system. Till the time the model stabilises itself you will see
these effects. Also when some source/sink condition is introduced in the model in the transient
steps, the same can happen again.
The effect of parameters can be visualized via the sensitivity analysis of the model. Try seeing
the output files of calibration/sensitivity analysis carefully.
In case the heads are over/under estimated, try changing the structure of the model itself for e.g.
different hydraulic cond zones etc or sometimes even the constant head boundary or the
boundary conditions. Try to see what the scenario you are trying to model and what model have
you made. when you expect the head values to fluctuate in model then what causes it in the
nature should be known and how can you produce them in model is the application part. For
e.g. if you have a const head bndry close to observation then do not expect the model to show
fluctuation in head values because of boundary effect.
* It sounds like you could make the first stress period a steady-state stress period instead of
having a long transient run before the beginning of the "real" simulation. However, if you need
to simulate oscillations in the stresses such as seasonal variation, you would have to have to use
the transient approach that you use for starting up the simulation.
* If you use a long transient simulation to reach a steady state, the change in storage should be
zero when it reaches the steady state solution. Thus you were correct in your initial expectation.
* MODFLOW is a command-line program, you wouldn't expect graphs to appear just by
running it. If you were using a graphical user interface, graphs might or might not appear
depending on which graphical user interface you were using. You need to say which graphical
user interface you were using if you were using one. You could use GW_Chart to make plots of
head or drawdown vs time based on the output from MODFLOW.
http://water.usgs.gov/nrp/gwsoftware/GW_Chart/GW_Chart.html
After starting GW_Chart, change the chart type to Hydrograph and then go from there.
* The henry problem input files are distributed along with SEAWAT. If you could import those
files into a separate Visual MODFLOW project and then have Visual MODFLOW regenerate
the SEAWAT input, you could compare those files with yours to see what the difference is. You
could use something like "diff" to speed up the comparison.
http://en.wikipedia.org/wiki/Diff
* How big is the budget file? If the budget file is larger than 2 GB, that could be the source of
the problem. 32-bit programs typically can't handle anything more than 2 GB in size. I think
there is a way around this by using a 64-bit operating system but I'm very vague on that so don't
go out and change your operating system based solely on this message.
* Henry classic benchmark problem - A couple of things you could try:
1. Try setting the constant head BC in last column to 1 m & constant concentration at 35 kg/m3

2. You did not mention the time stepping for the transport step: try setting the initial time step
for transport at 0.001, with a multiplier of 1.5, you can set the maximum time step length at 2
days which is the total simulation time so you're time step length will not be limited
PS: The toe should hit 1.4 m (from the freshwater boundary) for the parameters you have listed.
There is another version of the problem where the D = 0.57 m2/d with different results.
* For a perfect match, all the C/Co contours from the numerical output should match results
from the semi-analytical solution (Henry's solution). However, to make the job easier (and
cleaner), researchers use a select few contours. 4 seems to be good number to plot so they select
0.25, 0.50, 0.75 and 0.99. You can choose your own contours to match with Henry's output.
However, if you are conducting an inter- code comparison, the results available in literature are
generally limited to these four contours therefore subsequent researchers matched what was
generated earlier to be consistent.
* Henry's problem - For what concerns time steps and the total simulation time, I'm already
using these values. An information that can help is the following one: setting in the last column
the constant head to 1 and the constant concentration to 35 kg/ m3, I obtain exactly the solution
of Simpson (2004). It has a concentration of 100% on the whole sea boundary and a shape of the
wedge significantly different from the Henry original solution. On the other side, I try to obtain
the Henry solution setting only the initial concentration on the last column (not the constant
concentration) but, as I said, the intrusion of all the isochlors is approx. 0.1 m than the expected.
* Henry's Problem: The dispersion zone was observed to be really narrow (~ 10 mm). Therefore,
we assumed that the 0.5 isochlor (sort of in the middle of the dispersion zone) represents the
wedge. Since the dispersion zone was observed to be 10 mm, there may be an error of 5 mm in
characterizing the wedge via the 0.5 isochlor since we do not know where it is located within
that dispersion zone. We decided to use only one isochlor (0.5 isochlor) since it was cleaner to
try to match transient results (at different times) for only one isochlor instead of trying to match
the spread of the wedge (~10mm) observed in the physical model and the dispersion zone
obtained from the numerical results.
* Henry's Problem: The solution shown in Simpson's paper is the actual semi-analytical solution
(derived by Henry) with the constant concentration BC on the seaward side. To obtain the
solution shown in the SEAWAT manual you have to set a seaward BC that allows the
concentration to leave the system in other words you have to set a computed BC for
concentration on that side. This represents a more realistic case where the concentrations are
allowed to exit the system on the seaward side as they are carried upwards by the recirculating
flow within the wedge. However, the semi-analytical solution does not apply to this BC and you
can only do an inter-code comparison as SEAWAT does against SUTRA. Since Henry is
considered to be an insensitive benchmark problem an inter-code comparison should be enough
(my opinion).
* Aqtesolv and other similar software may work fine for pumping tests if there are not unusual
conditions in the vicinity of the well. Design of a well field for mine dewatering is best done
using a more flexible model like FEFLOW (http://www.feflow.info/) or modflow-surfact
(http://hglsoftware.com/Modflow_Surfact.cfm)
* My understanding of particle tracking and pathlines is that it is purely based on your
groundwater flow outputs (MODFLOW) and has nothing to do with concentration. It calculates
where the particle would go based on groundwater flow direction and velocity. It is like putting
a ball into a river and see where it would go. Therefore, my suggestion would be: setup your
flow model properly (initial heads, aquifer properties, boundary conditions like constant head
cells) and run MODFLOW. Then run whatever package you are using for particle tracking.

* Use MODPATH and have all the particles start at the tops of the cells containing the river. If
all those particles end up at the tops of the cells losing ET then you will know that all the river
flux leaves as ET. If not, weight the particles by the amount of river flux in the cells in which
they originated and calculate how much was lost to ET that way.
* A typical approach would be to do a mass transport simulation, setting a concentration of - for
example - 100 mg/l to the water infiltrating at the river, and a concentration of 0 mg/l to all other
water sources. The concentration of the ET (or concentration in the uppermost layer) would then
be the percentage of river water in the ET. By using multi-species mass transport simulations,
you could even track different sources of water. I have to add, however, that I am not a
MODFLOW user, so I cannot comment on the technical details of the method in MODFLOW.
* I think the question you want to answer with your model is what are the ultimate origins of the
molecules of water that are evaporating? If so, then the MODPATH particle tracking idea might
be ok, and I would particularly recommend the tracer-via-transport-model approach mentioned
by Peter. (If you do that, pay attention to how your transport model is set to treat the
concentration of the modeled tracer in water removed from the system by ET. You'd get
erroneous "build up" of concentration in the ET zones if you set the species conc in the water
lost to ET as zero. I think that zero conc flag is the default setting---and maybe only setting--with the VMOD GUI; I don't know about GWV. You might need to manually change the ET
conc flag in the MT3D input to have the tracer removed with the ET.)
But, just in case you are asking a different question: Keep in mind that removing water from the
alluvial aquifer (whether that sink is from pumping or ET) will change flow patterns and it will
induce additional river leakage (or reduce gain) much more rapidly (I am talking about transient
flow here) than the time for a molecule of water/tracer to travel between the river and that sink.
A sink will increase river losses relatively rapidly as the cone of depression reaches the river,
and that is a very different question than can be answered by tracking particles of water.
(Forgive me if that is not your question of it it was already obvious to you, but I mention it since
that conceptual mistake is not uncommon.)
* Daniele's CHD approach sounds reasonable to me. I understand your concern about the fact
that CHD can both act as a source and sink. I would use Zone Budget to set up a zone at the
CHD cells. The CHD-in value would show you only the amount of flow that goes into the CHD
cells.
Also check your CHD-out value. If it is zero, then CHD is purely a sink and we do not need to
worry further. Otherwise, continue to read.
If there is outflow from the CHD cells, then it is going to change the surrounding area and hence
may affect the inflow to the CHD cells. Therefore you should only use the CHD-in value as your
preliminary start point of your calibration.
The following is just my opinion.
Springs are simulated by drainage cells because (i) it is always a sink (ii) we do not know about
the amount of spring discharge. We need drainage cells to tell us the answer.
In your case, (i) is true but (ii) is false as you already know the discharge value.
Another type of boundary condition that can fulfill (i)=true and (ii)=false is the Well package. It
is always a sink. It requires known discharge rates.

Since you have assigned very high drain conductance but the discharge is still too low.
Therefore the next thing I would look at will be K (higher K = transmits more water = more
discharge).
I would use the Well package and vary K until the head at the wells are near the drain elevation
(surface elevation of the spring). After your K is right, you can take away the wells and put the
drainage cells in.
The methodology I just mentioned, however, is purely based on theory and has not been tested
yet.
* Theoretically a spring is a drain of the system and you should calibrate the hydraulic parameter
of the drain (conductance) on the base of the observations of the measured discharges. If you are
not able to repreduce the same or similar discharges it means that your conceptualization
(boundary conditions or other thins) is not OK.
Of course, for a calibration run you can use other packages like the well package or the EVT
package to simulate the springs and to force the abstraction of the water you have observed .
However for a predictive run you have to use the drain package and if the drain conductance is
not calibrated or the conceptual model is not OK you might get wrong results.
* I suspect that ".rst" stands for "raster" The released version of ModelMuse can import one
type of raster file: Surfer grid files. Another type of raster file is an ASCII raster file generated
by some ESRI programs. If it is that type of file, I can provide you with a beta version of
ModelMuse that can read them if you contact me at my work email (rbwinst@usgs.gov). both
the Surfer and ESRI raster files are text files so you should be able to read what is in them with a
text editor. If you can't read what is in them with a text editor, then they are some sort of binary
file and ModelMuse probably can't read them.
* The process of modelling consists in 2 steps: 1) calibration 2) prediction. The first step is to
make sure that your model is able to mimic the real world, whilst the second step is to use the
model for the purpouse of your study (dewatering, water supply, capture zones, contamination
containement etc.) Genarally you use the observed/measured data calibrate the model. In other
words you wulod use the observed stresses (abstractions, drains, recharge, etc.) to set up the
calibration model and then you have to compare the calculated water levels with the observed
water levels. If you conceptualization is correct the observed levels and the calculated levels
would be quite close otherwise you have to review your conceptualization (aquifer property
distribution, hydraulic parameter values, bounday conditions etc.). PEST (parameter estimation)
will help you once you have decided the distribution of your parameters and fixed the boundary
conditions.
* You can use the heads in the Head-Observation Package
http://water.usgs.gov/nrp/gwsoftware/modflow2000/MFDOC/index.html?hob.htm
and then use UCODE or PEST to help calibrate the model. Generally, head observations are not
enough to calibrate a model. You usually also need either flux observations or prior information
to calibrate it.
* Abnormal termination error - If you changed the number of stress periods in the model
(MODFLOW?), you have to add stress-period data to all the boundary-condition packages.
Probably the model simulates one period, and then fails because it has reached the end of one of
the files before it has finished reading data.
* Abnormal termination error - it is possible that some of the production bores went dry due to
the increae of the abstraction rate by 20%. If you use the well package I suggest you to use the
multi-node well package available with modflow 2000 that works similarly to the fracture well

package of modflow surfact which is able to varies the abstraction rate as function of the local
water table elevation. To confirm that try to see in the lst file the most recurrent failing cell
where the closure error is above the convergence criterium/a it might be one of the cells that are
dry. Have also a look on the abstractions (see the mass balance in the lst file) and see if they are
consistent with what you assigned.
* Why "the upper limit of the chloride bi carbonate ratio constraint is 0.05" when the guidelines
in Custodio (1996) state that seawater is present in groundwater if the ratio rCl-/rHCO3- (ions in
meq/l) is between 20 and 50.
* If you are running a transient simulation the storage component in your mass balance comes
from the capacity of the porous medium to store or release water due to the specific storage for
confined aquifers or specific yiled for unconfined aquifers. You would notice that the storage
component of your mass balance would change when you change the Sy or the Ss in your
model.
* Where the water enters depends on the layer of the river grid. the streambed will not tell the
MODFLOW where water goes. u could determine the layer of a river grid based on its
streambed while writing the RIV file. The input of RIV could be changed in each period, thus
you could use different layers of the river grid to represent the interaction as the groundwater
table and river stage change.
* You've to look at the groundwater head contours and choose NO FLOW along the the
direction of flow (perpendicular to the contour lines) and select Specified Heads along the
contour lines. So, if the contour lines are fairly parallel, you would be able to select Specified
Head Boundaries in two sides and NO FLOW boundaries in two sides.
- That only works for steady state flow - a transient flow model will need specified head
boundaries all around.
* It depends on what you're modeling. While GHB may be appropriate, you should also consider
fixed head for fixed flux. Fixed head is easiest and is often sensible. Fixed flux is more difficult
to apply but may be better depending on modeling objectives. GHB is intended to indirectly
model the presence of a source or sink of water that is outside the model at some distance, and
the GHB conductance is intended to represent the material between the model boundary and the
external source/sink of water.
* It handles rivers differently than it does recharge. ModelMuse uses points, lines, or polygons
to define rivers. However, when importing an existing MODFLOW model, it always uses a
point at the center of the grid cell to define rivers. Any point that defines a river that is inside or
on the edge of the child model will be a river in the child model but not in the parent model.
However, it won't be assigned to the first or last row or column of the child model because those
will be treated as constant head cells in the child model. Instead, they will be located one row or
column inward from the edge of the child model.
* Let's start with the coordinate system. Columns numbers increase in the X direction (West to
East). Row numbers increase in the negative Y direction (North to South). Layer numbers
increase in the negative Z direction (Top to Bottom). Head is the elevation to which water would
rise if a piezometer (or more colloquially, a well) were installed in the aquifer and allowed to
equilibrate with the aquifer. Thus in the first stress period, the water levels were a little higher in
the upper layer than in the lower layer. In the second stress period, there are two wells pumping
water out of the lower aquifer resulting in lower heads in both aquifers.

* There are at least four USGS programs that can be used to read data from the cell-by-cell
budget file.
1.
2.
3.
4.

ZoneBudget
MODPATH
GW_Chart
ModelMuse

Note that the cell-by-cell budget file must be an unstructured non-formatted file to be read by the
above programs. To generate such files with versions of MODFLOW not distributed by the
USGS, openspec.inc in the MODFLOW source code may need to be modified prior to
compiling MODFLOW.
* If you are using Groundwater Vistas (www.groundwatermodels.com), you can convert
instantly from one boundary type to another. Otherwise, it would depend on whether you are
using the CHD Package as the input for your fixed heads or the BASIC Package. If the Basic
Package then it's not that simple because you need to remove the negative signs in the IBOUND
array, and pick out the head values from the starting head array. Then you'll need to create a
GHB input file (and presumably a PEST template file) using that information. If you are using
the CHD Package it's a lot simpler because you can just reformat the CHD input file to GHB
format in a text editor pretty quickly. The formats are very similar.
* If you have wells near the top of the model that are extracting water, that would reduce the
head in those cells. In response to the reduced head, water from neighboring cells, including the
cells below the ones containing the wells would flow into the well cells. That would set up a
vertical head gradient such as the one you observe.
* The answer to your question is a function of the software you are using as a GUI for
MODFLOW; ModelMuse, Visual MODFLOW or MFI2005. I recommend you to use
ModelMuse (http://water.usgs.gov/nrp/gwsoftware/ModelMuse/ModelMuse.html) as it is open
source and has so unique capabilities. In ModelMuse, you can activate WEL package under
Model| MODFLOW Packages and Programs| Boundary conditions|Specified flux. For your
contaminated site, if you want to track the pathway of the groundwater flow you can use
MODPATH which is embedded in ModelMuse as a post-processor. Another suggestion, you
can use MOC3D http://water.usgs.gov/nrp/gwsoftware/moc3d/moc3d.html .
* For wells; If you are using ModelMuse, " Create object, then double click on object, select
HOB (for head observation wells),and also specify other properties like x,y coordinates from
there. When you finish click okey. Remember you need to define/choose the package (WEL or
HOB) depending on which wells you want to assign.
For wells in VisualMODFLOW, Click input >wells >Pumping wells> click add well> click
anywhere in the Model, then a new small box will open where you will specify the well
properties. The same procedure applies for head observation wells. You can also import them as
ASCII file.
* In general, you first need to activate the Well package before you can create a well. If you
want to do a solute transport simulation, you will probably want to use MT3DMS to do that part
because MODFLOW itself does not do solute transport.
* In PMWIN5, one can use two type of background map, vector map and raster map. For vector
map, PMWIN suports dxf and surfer blank file. For raster map, pmwin supports jpg and bmp
format. You can add both the vector map and bit map as an background map from under the

editor environment, and use the menu option-->maps. However, you have make sure the
followings, otherwise you won't see your background map.
-- For both vector and raster map, you need to make sure the model and your background map
are in the same coordinate. You can assign the parameter to shift your model coordinate to be
consistent with your background map in the editor environment, under menu Options->environment....
-- For dxf map, you need to save your dxf file to an pretty old version since it does not support
the new version of dfx. Sorry I could not remember what dxf version it supports upto.
-- For raster map, you will need to ensure the spatial coverage of the map is larger than your
model coverage, otherwise the raster map won't display after the georeference.
I know PMWIN5 is free, but it is old, the newest version of MODFLOW it supports is
MODFLOW96. I suggest you purchase Chiang's book, which comes with the newer version of
PMWIN, I believe it is version 7.0, it supports MODFLOW2000. You can find the detail
information from the following link: http://www.pmwin.net/index.htm
* A range check error is always a bug. It can occur whenever a program attempts to access
something outside the valid range of data so it can occur in lots of different ways. Several ways
in which it can occur have been fixed but evidently not all.
* Together, MODFLOW and MT3DMS can simulate solute transport but they can not simulate
multiphase flow such as oil and water together.
* Arrays and the numbers of rows and columns are allocated dynamically in MODFLOW-2005
(also in MODFLOW-2000), and are not limited by anything in the MODFLOW code. The
practical limitation on row and column dimensions (and model size/complexity in general) is the
amount of memory available to the program at run time. If you are running into a 2000
row/column limit, the limitation likely is in PMWIN. You could contact the developer of
PMWIN and ask if the limits can be changed. Or you could use another preprocessor.
ModelMuse is an option.
* The following are questions that you can ask yourself and hopefully they can guide you
through your model setup process.
1. Why are you setting up a model? What questions do you want your model to answer (what is
the objectives of your model)? Sometimes you will find that an analytical solution is sufficient
to answer your question.
2. What sort of spatial scale are you looking at? Do you need a cell size of 100 km? Or 5 m?
3. Do you need a steady-state or transient model? If transient, what sort of temporal scale are
you looking at? Years? Days? When do you want your model to start? From 1920? From 2000?
4. How large do you want your model to be? You need to define the model domain - i.e. the
northern, eastern, southern and western boundaries. It is best to use a natural boundary such as a
river. If not then use boundaries like groundwater divides. Sometime you will have to use
political boundaries (if any). Since you are simulating pumping wells, it is best to set the domain
large enough so that the cone of depression does not extend to any of your boundaries during the
simulation period. Regarding how to simulate boundary conditions, please refer to System and
Boundary Conceptualization in Ground-Water Flow Simulation written by the USGS.
5. What hydrogeological data are available? You will need that to setup your hydraulic
conductivity and storativity parameters.

6. You will need to setup boundary conditions like recharge (note that recharge does not
necessarily equal rainfall), ET, pumping, surface water bodies (if any) etc. Literature and
previous studies at your project area can assist you in choosing an appropriate value for recharge
and ET. Of course it is even better if you have field measurements.
7. Collect observed groundwater level data so that you have something to compare your model
outputs to (i.e. calibration).
Setting up a model is never easy and can take a very long time. The questions above may just
take you a month, or can take you up to a year, depending on your objectives.
Note that after setting up your model, it is recommended to undertake (i) calibration, (ii)
sensitivity and uncertainty tests, and (iii) predictions.
* 1) Check the layer type of your top layer and it should not be type 0 (i.e. confined). Ideally it
should be type 1 (unconfined) or 3 (convertible). This will allow specific yield to be used when
the water table is below the cell top elevation. Also, make sure your specific yield is large
enough (usually around 0.01, but without understanding the hydrogeology of your study area it
is hard to say).
2) In general, do not use layer elevations (i.e. depths of layers you mentioned) for calibration.
3) Try changing your recharge. In my opinion recharge is the trickiest parameter ever. It can be
less than rainfall, due to water loss through the unsaturated zone. It can be greater than rainfall,
as there can be water gain from lateral inflow. Evapotranspiration is also something that you can
consider.
4) Yes it is always tricky to change the cell resolution during the modelling exercise. Most user
interfaces allow you to export cell elevations as a shape file. Do that, and then change the cell
resolution as needed, then re-import the shape file and the user interface should be able to do the
interpretation for you.
5) To compare simulated groundwater table with measured groundwater levels, the preferred
way is to use hydrographs you plot the computed and observed water level for a monitoring
bore. The less preferred way is to use water level contours. I do not prefer this way as the so
called observed water level contours are drawn either by hands or computing program (i.e.
interpretation). Neither of them reflects the reality. However, contours can be used to see
whether the model is replicating the correct flow direction and magnitude. I guess the rule of
thumb is not to be too fussy about matching the model contours with the observed contours.
Imagine if we have got all the data, people just need to feed the data into models like fill in
blanks, and the models always run smoothly without any problem. If thats the case then I guess
people wont need any modellers. However, usually a model will not work properly at the
beginning, and the value of a modeller is to be able to spot and fix the problems. Problemsolving skill is an important skill that modellers should develop.
* Modflow does not support a way to include river cells and drain cells in the same observation.
If you are certain that the heads in the drain cells will always be at or above the drain elevation
throughout the simulation, you could convert the drain cells to river cells (the drain elevation
would become the river stage), and then define a river-package observation as desired.
However, if at some point in the simulation the head in a former drain cell falls below the former
drain elevation (now the river stage), the boundary would not behave like a drain cell and water
would be simulated as entering the cell from the boundary.

* Visual MODFLOW will translate your input into standard SEAWAT packages; you can then
run these using the SEAWAT.exe that can be downloaded from the USGS website
(http://water.usgs.gov/ogw/seawat/). Or, you can use the .EXE versions of SEAWAT included
with Visual MODFLOW 2011.1, we now provide these in both 32-bit and 64-bit versions. (start
the .exe, provide the .NAM file, and go). You can then compare the resulting .LST files, using a
comparison tool. FYI, we have benchmarked the SEAWAT engines in Visual MODFLOW and
compared these to the USGS data sets, and have not found any significant differences.
* You may need to revise the name file generated from VMOD if you are using the USGS
version of SEAWAT_v4.exe. Several output files in that name file may not be recognized by the
SEAWAT_v4 from the USGS website. You can use "#" to comment them out then it should be
ok to go.
* You need to solve 3D Richards' equation with appropriate Dirichlet boundary conditions (no
flux at the bottom). There exists some free solvers for it. One is the GEOtop model below. One
reference commercial software is Hydrus 3D. To solve them you need, obviously, the
appropriate water retention curves, and parameterization of hydraulic conductivity. One
alternative, seen the dynamics, is to solve 1D Richards equation superimposed to a Boussinesq's
equation solver (e.g Cordano, and Rigon, WRR 2008), always with Dirichlet boundary
conditions.
* To see the DOS windows, you may want to create a batch file that contains two lines as below:
SEAWAT_v4 name_file
pause
I assume the exe file is in the same folder. The DOS windows will stay until you close it, so you
can see the error messages.
* You might be able to use MODFLOW-VSF (Three-dimensional finite-difference groundwater model (MODFLOW)--2000 version--with variably saturated flow) or the UZF package
(Unsaturated-Zone Flow (UZF1) Package for Modeling Unsaturated Flow Between the Land
Surface and the Water Table with MODFLOW-2005)
http://water.usgs.gov/nrp/gwsoftware/mf2k_vsf/vsf.html
http://pubs.usgs.gov/tm/2006/tm6a19/
* Unfortunately Modflow-Surfact is not for free. It is a program developed by HGL
(Hydrogeologic). You have to buy a license if you want to to use it. Even though you have the
premium version of Visual Modflow, it does not include the license of Modflow-Surfact.
Remember that Visual Modflow is just a graphical interface for pre and post-processing
modflow (and related programs) input/output files. Visual Modflow can generate and run
Modflow-Surfact input files only if you have the extra license. Find here some details of the
software:
http://www.swstechnology.com/groundwater-software/groundwater-modeling/modflow-surfactflow
HGL developed also a graphical interface for their codes Modflow-Surfact and ModHMS.
However I dislike their interface and I would rather prepare the input files with a text editor.
* MODFLOW-NWT is designed to handle the rewetting in a more robust way than standard
MODFLOW-2005. http://water.usgs.gov/nrp/gwsoftware/modflow_nwt/ModflowNwt.html

* If you don't want to spend the money on MODFLOW-SURFACT, MODFLOW-NWT may be

a viable alternative. MODFLOW-NWT essentially handles dry cells in way similar to
MODFLOW-SURFACT's pseudo soil relations and provides improved handling of water table
fluctuations over multiple layers in your model. It is fully supported in Visual MODFLOW v.
2011.1.
* The MODFLOW-NWT is in essence a solver with capacity of handle rewetting cells if you
have dry cells in your model, so you can modify directly from the list file and basic file,
changing the .pcg2 to .nwt solver (you can download from USGS resources page there are
many examples), add upf package an run directly from the executable, and visualizing in a
postprocesor of your preference.
* The total pumping rate in ModelMuse would be more correctly labeled as the total rate per
layer. You would need to divide the rate by the number of layers intersected to get the rate right.
If you want to simulate flow through the well from one layer to another or to have MODFLOW
calculate how to divide up the pumping between layers, you should use the MNW package.
* I think you should use ModeMuse, a good GUI that supports MODFLOW-NWT,
MODFLOW-2005, and many more. I once had a rewetting problem while modelling a
groundwater system of a certain catchment, and MODFLOW-NWT did well. Its an open source
software available on USGS site with lots of videos and a lot of support from online groups.So
easy to learn.
* In many cases, if a polyline or polygon is used to specify a group of wells, it may be
advantageous to specify the pumping rate as a rate per unit length or rate per unit area and then
multiply by ObjectIntersectLength <objectintersectlength.htm> or ObjectIntersectArea
<objectintersectarea.htm>. Doing so makes it possible to modify the grid without reentering
information. If the Pumping rate interpretation is set to Calculated, those functions will be
included automatically. Sometimes it may be desirable to specify the total well flux for an
object. One way to do this would be to use a formula of the form (Total Rate)/ObjectArea
<objectarea.htm>*ObjectIntersectArea <objectintersectarea.htm> or (Total Rate)/ObjectLength
<objectlength.htm>*ObjectIntersectLength <objectintersectlength.htm>. If the Pumping rate
interpretation is set to Total, those functions will be included automatically.
* Each layer intersected by the point object defines a well with the pumping rate you specified.
The total pumping rate is the pumping rate you specified times the number of layers intersected
by the object.
* The calculation of storage depends of which package are using, there is a difference among
LPF and BCF, in the BCF the term of storage is given, beside of calculation of T, if is
convertible (LPF) or Confined, and depends by the initials heads (not the constant boundary
heads) puts in your model.
* Place the GHB cells in active cells (IBOUND = 1). So long as the GHB cell is an active cell, it
doesn't matter whether neighboring cells are active or inactive. From your description, I think
you want to place the GHB cells on the south west side. It wouldn't make sense to place them on
the same side as the constant head cells.
* Anywhere a future prediction is needed at a specific location but where there is no existing or
historic monitoring point (so no residual to be calculated). Examples: a point of compliance,
hypothetical point of water supply, spring, planned location of monitoring, etc. Granted this
information can be gotten by post processing model output but its nice to have a way to list
results at specified points (cells) directly, especially for those with limited software resources.

* The bearing is used to make the variogram anisotropic in a certain direction. The contribution
is used to have multiple variograms in the krigging. If you look at the 2d pilot point example in
the Groundwater Vistas manual, it uses multiple variograms during krigging.
* Groundwater Vista has several advantages compared to Visual Modflow. these include:
1. Unstructured Grid Package (USG) which is not yet available for Visual Modflow. This tool
enables refining the grid in defined areas, and not for entire rows and columns. This reduces the
model size and shortens run times;
2. Groundwater Vistas has an integrated automatic sensitivity analysis which may help to
achieve better calibration;
3. Groundwater Vistas supports uncertainty analysis tools; and
4. MODFLOW-SURFACT (a MODLOW add on) can be utilised with Groundwater Vistas to
improve the modelling of surface and groundwater interactions. GW Vistas is recognised as an
industry standard tool in this type of application.
* The .nam file is a file associated with MODFLOW itself and contains the names of the input
and output files. Therefore, you should be able to import your model into Visual MODFLOW as
it requires either a MODFLOW-2000 or a MODFLOW-2005 NAM file to be specified as input.
Of course, importing MODFLOW datasets, will always have limitations (regardless of what was
the GUI used to create the original model), so you should not expect to be able to import all
aspects of your original model.
* Hydro GeoBuilder (HGB) is already capable of creating up to 9 child grids within a parent
grid, allowing for local "grid refinement". HGB is a standalone conceptual model developing
tool developed by Schlumberger Water Services (SWS), and it creates grid independent
conceptual models that can be translated into MODFLOW numerical models (grids) and/or
FEFLOW models (meshes). SWS will very soon release Visual MODFLOW Flex, that basically
seamlessly integrates both HGB and Visual MODFLOW into a single environment. If you have
a Visual MODFLOW (Standard, Pro or Premium) license with active Maintenance, you will be
eligible to upgrade to the equivalent version of Visual MODFLOW Flex free of charge, so your
first problem is solved.
Visual MODFLOW Pro and Premium include PEST as a parameter optimization and predictive
analysis tool. MODFLOW-SURFACT is also supported by Visual MODFLOW provided that
you purchase SURFACT from SWS or one of their distributors.
* ModelMuse can import MODFLOW models that work with the USGS version of
MODFLOW-2005. However, ModelMuse will only import the packages it supports so you
should check whether ModelMuse supports all the packages in your model before trying to
import it. I think you should be able to import Groundwater Vistas models without any
problems. I'm not sure about Visual MODFLOW. In the past Visual MODFLOW had some
additional packages that were not in the standard version of MODFLOW. If you commented out
those packages, you would probably be able to import it. MODFLOW models generated by
GMS often can not be run with the USGS version of MODFLOW without some hand alteration
of the input files. First you must make sure that the input files are in what GMS claims are the
standard formats. However, those still need some additional changes before they will work.
GMS input files often put file names quotes. The USGS version of MODFLOW does not accept
quotes and in addition, the file names can not contain any spaces. There may be additional
changes required but that is what comes to mind at present.

With regard to models generated by Hydrogeobuilder, you should be able to import those but
you will import the numerical model not the conceptual model. ModelMuse can not run PEST.
However, you can use to run UCODE which performs a similar function. To run UCODE, you
also need ModelMate. Variable density flow can be modeled with SEAWAT which is not
currently supported by ModelMuse. With regard to whether you can neglect variable density
flow, that depends on what the goal of your model is and what the area you are trying to model
is like.
* In Hydro GeoBuilder, the conceptual model is designed outside of the grid and simulator; it
can be used for MODFLOW or FEFLOW, and eventually MODFLOW-USG. Once you apply a
finite difference grid onto the conceptual model, and convert this to a numerical model, this
results in a set of MODFLOW files, with the standard USGS format (with .NAM package, etc.).
So yes, these standard MODFLOW files can be imported and run in other GUI's such as GMS or
GWVistas.
You can import standard MODFLOW 2000, 2005 files into Visual MODFLOW; these can come
from GMS, GWVistas, etc. After you create a new project, there is an Import MODFLOW
option from the main menu; you select the .NAM file and proceed through a step-by-step
wizard. You can exchange data between Visual MODFLOW, GMS, and GWVistas using
standard MODFLOW package file format. Aside from that, each program saves a project in
their own format: GMS and GWVistas is a binary project file, where as Visual MODFLOW is
.XML based.
The main benefits of Visual MODFLOW are the intuitive interface, graphics and display
quality, and the 3D Visualization. Visual MODFLOW also supports MODFLOW-SURFACT
and PEST.
As you may have seen, we are in the process of rolling out VMOD Flex, which combines
conceptual modeling from Hydro GeoBuilder with the numerical modeling features of Visual
MODFLOW, in a single, integrated package. VMOD Flex allows you to design a 3D conceptual
model then simulate this with both structured and unstructured grids; in addition, you can
designed localized grids and run Local Grid Refinement (MODFLOW-LGR). In the near
future, VMOD Flex will support the latest version of PEST with Pilot points.
Regarding MODFLOW-USG:
To the best of my knowledge, GWVistas does not yet support MODFLOW-USG. In v.6, there is
a prototype for demonstrating nested grids. You cannot generate MODFLOW-USG files nor run
a MODFLOW-USG simulation. MODFLOW-USG has not yet been officially released, it is still
undergoing testing and review by the USGS. When I last spoke with the code authors, they
indicated it should be released this year; once it is, we will add support for this in VMOD Flex.
* MODFLOW-Surfact does now support the Conduit Flow Process (CFP) designed for karst
simulations. While perhaps not ideal for your case, it might work better than assigning the
whole grid cell a high K value - just a thought. That is the only option I can think of for your
situation. Groundwater Vistas does support CFP, although we have not hooked it up to surfact
yet. If you need it, we can do that.
* Surfact does not support the USGS MNW packages. But it has 2 of its own called Fracture
Well 4 and 5. I think Fracture Well 5 is roughly equivalent to MNW2.
* 1) Q: How do I spend from my Bank Account without depleting it? Ans: Not possible. But
take care to recharge the Bank Account from time to time.

2) Similarly, pumping groundwater from a large dia dug well would deplete phreatic ground
water and will also affect nearby wells, especially the shallower wells. But all the well owners
should take care of recharging the wells during Monsoon season, by digging infiltration pits
around the wells and directing runoff from rainfall into the pits.
3) Dug wells in fractured hard rocks are practically beyond mathematical treatment. At the most,
an approximate estimation of how much water could be pumped with a stabilized drawdown of a
few meters, could be made. But this is not the safe yield. Most of the dug wells penetrate the
fractured zone fully and go into the massive rock below. This portion excavated in the massive
rock serves as the storage for ground water seeping from the overlying fractured rock. If these
seeps are just a few discreet springs and NOT all around the wet perimeter, mathematical
treatment is still more difficult for a heterogeneous, unisotropic medium.
4) Taking watershed as a unit, the recharge from rainfall in the watershed is about 9 to 14
percent, in hard rock areas. Thus the total volume of recharge could be estimated and about 60%
of this could be taken as the safe yield of ground water pumpage for the watershed. Safe yield
for an individual well is a fallacy. If soil & water conservations techniques are adopted in a wellmanaged watershed, the percentage of recharge to rainfall could be improved upto 25 to 28% as
per the study by World Bank
5) The proposed National Water Policy is silent on priorities, which means that Industries do not
necessarily get a lower priority if their water use is rational and productive. Licensing by Govt.
to Industries, for water pumpage is full of corruption & red-tapism, because the Licensor himself
is not technically competent to issue any such permits. Furthermore, if an Industry is granted to
pump 100 cu m per day, there is no guarantee that the wells / bores in land belonging to the
Industry would yield this supply. At the most, Govt should make it compulsory for Industries to
harvest rain water from roof and land for recharging during Monsoons.
* Since the term 'Safe Yield' has been overly misused, the groundwater experts have
recommended to better use the term 'Sustainable Yield'. This modified term should be properly
understood by the hydrogeologists (or groundwater hydrologists) in order to ensure its
successful use in practice. Of course, artificial recharge, coupled with rainwater harvesting is a
vital tool to ensure 'sustainable yield' from an aquifer system, and they should be promoted on a
wider scale to sustain both unconfined and confined/leaky confined aquifers on a long-term
basis.
In order to determine the realistic sustainable yield of an aquifer, detailed and accurate
information about the geology (depth, thickness and areal extent of aquifer layers and those of
confining layers), a reasonable estimate of recharge under particular hydrologic and
hydrogeologic conditions and its spatio-temporal variation as well as the proper understanding
of groundwater hydraulics in a single and/or multi-aquifer system, including the hydraulic
connectivity between aquifers and/or between aquifer and surface water bodies are essential.
Given these information and knowledge for a catchment/basin (provided they are dependable),
one can be able to realistically estimate sustainable yield (or so-called 'safe yield) of an aquifer
system. I strongly believe that no short-cut method is available for the efficient management of
vital groundwater resources in a basin/sub-basin.
* You have to supply the external heads for the GHB package. If you can't do that, you need to
reconsider your boundaries. For example, If you can locate (or approximate) a flow divide, you
can use that as a no-flow boundary. You can also use a streamline as a no-flow boundary. For
more details, see http://pubs.usgs.gov/twri/twri-3_B8/.

* FEFLOW can only simulate well fluxes at nodes, so the only way to simulate the screens
exactly is to have nodes assigned to the top and bottom of the screen. This is often not practical.
* Stress periods are defined based on when a stress on the system changes. For example, if a
well is turned on or off, that would be a reason for starting a new stress period. Seasonal changes
in recharge and evaoptranspiration would be other common reasons for defining new stress
periods. Within each stress period, you need to define a sufficient number of time steps to get a
solution that is accurate enough for the purposes of the model.
* The Unsaturated Zone Flow package in MODFLOW can simulate unsaturated flow in the
vertical direction and is coupled with the saturated system beneath it. MODFLOW does not
simulate solute transport but its results can be used with MT3DMS to simulate transport of
solutes. MT3DMS only simulates transport in the saturated zone. Neither MODFLOW now
MT3DMS simulate non-aqueous phase liquids (NAPL).
* Groundwater Vistas Version 6 (www.groundwatermodels.com) coupled with MODFLOWSurfact (www.hgl.com) can simulate saturated & unsaturated groundwater flow and multicomponent transport in 3D, including the effects of non-aqueous phase dissolution (although not
flow of the napl itself). The model can also simulate density effects on groundwater flow.
* In the computational analysis world, the terms Verification and Validation have distinct
meanings. Verification refers to the process of showing that the code is solving the governing
equations correctly. This involves monitoring the iterative convergence, grid independence, as
well as potentially comparing to some type of simplified analytic solution. The goal of
verification is to increase confidence that there are no "bugs" in the code itself. Validation on
the other hand refers to the process of showing that the verified solution to your code represents
reality. Validation is used to test the assumptions in your model as well as the appropriateness
of your parameters and boundary conditions. If a verified code is compared to experimental
data, then the code is validated for those conditions.
* In some respects the issue of validation of MODFLOW is moot. It has been used for realworld problems all over the world for close to 30 years. There are hundreds of USGS
applications of MODFLOW that are fully documented and in the public domain which should
serve this purpose.
Verification is trickier. While I'm sure the USGS has internal studies verifying the MODFLOW
code (and its various versions), I do not know of anything official being published. The closest I
can point to is a report by the US EPA which is a collection of problems designed to show how
modflow works. Some of these problems, though, involve comparing modflow to analytic
solutions and can therefore serve as at least partial verification of MODFLOW88 (it was
published in 1993). Here is the link:
http://www.epa.gov/ada/csmos/models/modflow.html
* There is a tricky way of dealing with this in MODFLOW-Surfact, though. If you want to
simulate the mined out areas as very high hydraulic conductivity (which is how lakes were
simulated before the LAK3 package was created), you can do that with MODFLOW-Surfact's
TMP1 (transient material properties) Package. This can change hydraulic conductivity and
storage over time, going from the pre-mining native K values to a very high post-mining value.
This would allow you to simulate the entire mining and recovery period in one run. The
downside is that MODFLOW-Surfact is expensive.
* The lake package does allow the definition of the lakes to be changed. However, it requires
that the cells that make up the lake be inactive (IBOUND=0) and does not provide a way to

change which cells are active. Thus, if it wasn't a problem to make all the cells in the mine
inactive at the beginning of the simulation, you could do it. Otherwise, you would have to create
a series of simulations in which the cells that make up the lake are changed and set them up so
that the final heads in one model are used as the initial heads in the next.
* One way that is sometimes used is to weight the heads by the transmissivity of the layers. For
example, if the transmissivities for layers 1 through 5 were (10, 5, 3, 7, 8), you would give layer
1 a weight of 10/(10 + 5 + 3 + 7 + 8). In MODFLOW, the weights have to add up to 1.
However, in ModelMuse, it checks whether the weights add up to 1 and if not, it adjusts them so
that they do add up to 1. Thus you could just assign layer 1 a weight of 10 instead of 10/(10 + 5
+ 3 + 7 + 8).
* I haven't reviewed these multiple applications yet, but I dare say that without some form of
proper model validation, the deterministic results of MODFLOW should be interpreted with
caution and (unless fine- tuned to a particular scenario) should be assumed to contain extreme
inaccuracies. Without the confidence obtained via model validation, any model-based decisions
(especially regulatory) are wide open to litigious and scientific attack.
* The variable ITMP, set to 0 in the lake package, would mean "no lake calculations this stress
period", which means that the lake would be treated as no flow area (inactive area of the model)
because of the definition of the IBOUND matrix that cannot vary with time.
* (During the monsoon season, the width of river increases on both sides of river banks,
inducing vertical recharge also. Under such scenario, how we can modify the transient river
boundary condition). If the river is still contained in the same cells, increase the conductance
during the monsoon season. If it expands to cover additional cells, make those cells river cells
during the monsoon season but turn them off again later.
* Try using the Streamflow Routing (SFR) package of MODFLOW; both MODFLOW-2000
and MODFLOW-2005 have this package. The SFR package allows a user to specify a rating
curve for the river cross-section - flow versus depth and width of the river. Note that this
package is not implicitly solved and can become unstable if non-linearities are high. If you end
up using this package, it would be prudent to keep an eye on convergence and mass balance.
This will allow the model to store that extra rain water in the SFR boundary if water budgets are
of concern. However, the SFR package, and for that matter none of the packages in
MODFLOW, have the capability to simulate overbank flooding - in case your interest is in the
small scale workings of the river.
* For no-flow boundary, you should set IBOUND to 0 at the edge of the active area of the
model. In addition, the edge of the grid is automatically a no-flow boundary.
* Here is a link to a video on how to use MT3DMS with ModelMuse.
http://water.usgs.gov/nrp/gwsoftware/ModelMuse/MT3DMS/MT3DMS.html
You do have to download and install both MODFLOW and MT3DMS in order to run MT3DMS
because part of the input to MTD3DMS is output generated by MODFLOW. In brief, what you
have to do to use MT3DMS is to activate MT3DMS in the MODFLOW Packages and Programs
dialog box and define one or more chemical components that you want to track. You would also
have to activate the MT3DMS Sinks and Sources package. You will need to define the
concentration in the lake and then run MODFLOW followed by MT3DMS. You could use the
transport observation package in MT3DMS to track the solute entering the well. However, that
won't distinguish between the solute that comes from the well and solute derived from some
other source.

* A better way to think about the situation is that the river is outside of the aquifer. MODFLOW
only simulates flow between the river and the aquifer. It simulate flow inside the river. It would
be best to use either 1 or 2 Z-formulas. The Z-formulas determine which layers of the model the
river is connected to. The river bottom does not need to be the same as the bottom of the cell. It
is often higher than the bottom of the cell. MODFLOW even allows it to be below the bottom of
the cell although it is usually not a good idea to do that.
* Your current model setup probably indicate that there are much more inflows to the aquifer
than outflows, resulting in continuously increasing heads. Maybe the water volume entering the
aquifer from the specific head boundary is much more than the water volume discharging into
the river. You should check the water balance in order to identify if that's the point and refine
your model setup or even your conceptual model.
* The edge of the grid is automatically a no-flow boundary. You can also use the IBOUND
array to set some cells to inactive. There will be no flow between the active and inactive cells.
* The continuous source of pollutant can be simulated by assigning a constant concentration at a
node or a group of nodes. Assign to the same nodes a reference group to record the flux of
contamination that is released from your source. Then you will be able to check if this flux is
similar to your own analytical evaluation (even qualitative). You can also simulate a constant
leak, with a specified flux of water and contaminant, etc. Almost any situation can be simulated.
They are then several remediation options. Here are some ideas:
- excavate your source (that means turn off your source in Feflow), and look at the time required
for your plume to reach a concentration that is below a trigger value. That means you have an
idea of your degradation parameters for your chemical of concern.
- place some wells downgradient to capture and treat your water. Try some sensitivity tests to
improve the number of wells or the rate of pumping (higher number of wells or pumping rate
cost more money, but can be more efficient -> try to find a good balance)
- try the same with some reinjection wells upgradient your source, reinjecting clean water taken
from your pumping wells after treatment
- try to reinject downgradient the pumping wells, through an injection trench.
- try some confining slurry walls, with or without pumping and optional reinjection wells,
different shapes of walls, etc.
Pay attention to the costs and benefits of your different scenarios and to the field reality (like
realistic pumping rates etc). Try also to figure out which solution is the most sustainable ... (a
treatment that will run 100 years or even more will be more expensive that an approach made to
last 5 to 10 years, or even 1 ...)
* I am using a polygon object and the RIV package to represent a river. There are a few
steps/changes in elevation along the river according to which I need to specify the river
stage/head values.
I assume you are using ModelMuse for this problem. One way to do it would be to define a new
2D data set and set its interpolation method to "Nearest". Then create polyline object and use the
InterpolatedVertexValue function to assign values to this new data set but instead of assigning
values to intersected cells, assign values by interpolation. Then use the new data set as the
formula for the stage in the polygon object. And yes, stage is the same as head.
* To make the best use of the ModelMuse - ModelMate connection, you'll need to use
parameters in ModelMuse to define the model inputs that you want to calibrate. After you've set

up parameters that you want to calibrate in ModelMuse, you can create a ModelMate file by
using the menu item File | Export | Export or Update ModelMate File.
* You may want to define other parameters in addition to HK parameters in the LPF package. If
you even think at some point you might want to manipulate other parameters (e.g. vertical or
horizontal anisotropy, or vertical hydraulic conductivity of the layer or underlying confining
bed) it is probably worthwhile to go ahead and define those properties at the start using
parameters...if you don't want to let UCODE_2005 manipulate them now, just set them as fixed.
Often, modelers find they return to this step ("parameterization") multiple times during the
modeling process, so I would say go ahead and start using ModelMate and UCODE_2005 to
analyse your model. It usually makes sense to start out by making a forward run and checking
the results before jumping into a sensitivity or parameter-estimation run. The HOB CHD files do
not have parameters. The CHD Package does support parameters that can be used to control the
starting and ending heads for each parameterized CHD boundary.
* You could still use the RIV package when there is water, if you don't need to do streamflow
routing.
* RIV package is the old version and STREAM package is the latest version to be used with
MODFLOW. However, RIV package cant do flow routing problems whereas STREAM package
can do it. Based on your problem, you can use one of them.
* Select Mode|MODFLOW Layer Groups and define as many layers as you need. A data set
will be created for the top of the model and the bottom of each layer group. Use objects to define
the values of those data sets.
* The vertical conductance is calculated from the vertical hydraulic conductivity and geometry.
However, the BCF package input does not contain sufficient information to back-calculate the
vertical hydraulic conductivity from the conductance.
* The drain package may be more appropriate than either the river or stream packages if the
wadis will never act as a source of water for the groundwater.
* You could find the methods to calculate K and Vcont in the MODFLOW 2005 manual
(Chapter 5).
* I have a transient model where the water table is rising and falling through different model
layers through time (on a seasonal basis). I was having trouble with rewetting, and it was
suggested I use the NWT solver in MODFLOW 2005. In NWT dry cells remain active. This
works very well, and I have no problems now with drying-rewetting. Although you do need to
choose your solver parameters carefully to get fast convergence and low mass balance errors.
* The NWT options I use are:
a.
1.
2.
3.
4.
5.
6.
7.

Model|MODFLOW2005|Options
i.
NWT General
OPTIONS = SPECIFIED by user
HEADTOL = 5e-3
FLUXTOL = 5e-1
MAXITEROUT = 2000
THICKFACT = 1e-7
LINMETH = 2
IPRNWT = 1

8.
9.
10.
11.
12.
13.
14.
15.
16.

IBOTAV = 0
DBDTHETA = 0.8
DBDKAPPA = 0
DBDGAMMA = 0.001
MOMFACT = 0.001
BACKFLAG = 0
MAXBACKITER = 10
BACKTOL = 1.05
BACKREDUCE = 0.9

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

ii.
NWT Methods
IACL = 2
NORDER = 1
LEVEL = 1
NORTH = 4
IREDSYS = 1 (MODFLOW-NWT 1.0.3 onwards)
RRCTOLS = 0.0
IDROPTOL = 1
EPSRN = 1e-3
HCLOSEXMD = 1e-4
MXITERXMD = 250

* The warnings represent unusual situations that can sometimes be errors but often are not. You
don't have to correct them if you understand them and think they aren't a problem. If you don't
understand them, you should try to figure out what is going on. In the case of the particular
warning you received, there should also be a list of cells where it has identified initial heads that
are below the bottom of the cell. If you didn't expect that, a good thing to do would be to color
the grid with the initial head and then look at the explanation of how the initial head was
assigned in one of the problematic cell. If the explanation looks OK, try checking the elevation
for the bottom of the cell and check the explanation for how that value was assigned. You can
see the explanations by selecting "Data|Show Grid Values" and then putting the cursor over the
cell of interest.
* The initial groundwater table does affect the convergence, even for steady-state simulation, as
it is the starting point of numerical calculation. I would suggest you increase layer thickness for
the case with a complex geometry.
* The zones change laterally in your model? If you have very thin layers, the calculation of
vertical leakance become unstable more if you using the rewetting option, LPF takes as input
the vertical hydraulic conductivity directly and computes a vertical conductance internally. The
main difference (with BCF) is that it updates vertical leakance at each solver iteration for
partially saturated convertible layers, The NWT SOLVER utilize the same package (identical)
its call UPW, but it will handle much better than PCG2 or other.
* If the initial head is below the bottom of a cell in a convertible layer, the cell will go dry
immediately and dry cells are troublesome for MODFLOW-2005. MODFLOW-NWT was
developed, in part, to better deal with that wet-dry problem. As for ModelMonitor, the program
that monitors the percent discrepancy in MODFLOW as the program is running, it is still
included in ModelMuse. It normally is in the same directory as ModelMuse. I suggest you check
"Model|MODFLOW Program Locations" and see whether the location for ModelMonitor is
specified correctly.
* UCODE can be used with any model that reads its input from text files, including
MODFLOW-NWT.

* ModelMuse and ModelMate are designed to work together on generating and calibrating
MODFLOW-2005 models. ModleMate works, in part, by setting up UCODE input files and
invoking UCODE. To use ModelMate with modeling programs other than MODFLOW-2005,
the user generally needs to prepare the UCODE template and extraction-instruction files by
manually editing them in a text editor (see UCODE input instructions). However, I have not yet
used ModelMuse and ModelMate on a MODFLOW-NWT model, and I think the input for
MODFLOW-NWT and MODFLOW-2005 are similar enough that it may be worthwhile to go
ahead and try exporting a ModelMate file from ModelMuse and see if it works. One thing that
you may need to do in ModelMate is go to the Project | Program Locations menu item and
assign the MODFLOW-2005 program location to point to the MODFLOW-NWT executable.
Also, after opening the ModelMate file generated by ModelMuse, ensure (in ModelMate, using
the Model | Model Commands menu item) that the command for the Forward Primary Model
Run is correct for your model.
* There is no observation process package for SFR because no one has chosen to write one. The
closest substitute is the HYDMOD package. However, it isn't exactly the same as an observation
process package; you would have to do some additional post-processing to use its results as
observations for automated parameter calibration.
* The dispersion can be specified in the MODFLOW Layer Groups dialog box. If the
MultiDiffusion option is specified in the Dispersion package, the dispersion is specified in a data
set.
* ModelMuse uses the same length and time units for both MODFLOW and MT3DMS. You
define them under "Model|MODFLOW Options" on the "Options" tab. If you change the units,
you would need to change all your other parameters such as hydraulic conductivity to match
your new units and you would need to run both MODFLOW and MT3DMS again.
* For each particle, MODPATH calculates the time at which it reaches the boundary of a cell.
Those times are included in the pathline file at each location calculated by MODPATH as part of
the pathline. These times use the same time unit as is used for the MODFLOW model. The time
unit is displayed in the MODFLOW Time dialog box (Model|MODFLOW Time...). If you only
want to display part of a pathline, one way you can do that is by only displaying the parts of the
pathlines that are between two specified times. The lower and upper limits are the times between
which you wish to display the pathline. For example, suppose the particle release time is at time
0 and the particle exits through a well at time 10. MODPATH would calculate the particle
location at each cell boundary between its starting location and the well and it would also
calculate the time it reached each of those boundaries. Those times might be 1, 2, 3, 4, 5, 6, 7, 8,
and 9. You could specify the lower and upper limits as 3 and 7 and only the part of the pathline
associated with the times 3, 4, 5, 6 and 7 would be displayed.
With regard to displaying particle information in a graph, consult the MODPATH
documentation about the structure of the pathline file so you can see how to extract the data in
which you are interested. I would also be interested in hearing what information you would like
to include in your graph. For example, do you want a plot of the distance traveled vs time for a
particular particle or a histogram of the total travel times of all the particles?
* This is a good discussion on the minimum distance between two bore wells in hard fractured
rock aquifers. As S is highly variable and T is erratic and anisotropic, models may only be made
to convince the politicians / policy makers but not to the technical people who know the
limitations.
Practical way is to try an approach with watershed basis. From the total area of the watershed
deduct the area near the edges (which is mostly barren and unsuitable for agriculture) and the

area under dry-land farming. Thus you get an area mostly near the 1st, 2nd and 3rd order
streams, suitable for irrigational development. The annual recharge from rainfall (about 10% of
the rainfall) over the watershed would concentrate in this area. Let this area be "A hectares".
Then make an estimate of the annual pumpage from the existing wells and divide by the number
of existing wells so as to get average annual pumpage per existing well. Divide the annual
recharge from rainfall by this average annual pumpage per existing well, so as to get the
maximum number of wells which could be supported by the watershed. Let this number be "N
wells." Then within the watershed there could be " N / A " wells per hectare. "One well per
hectare" gives a spacing of 100 m. "Four wells per hectare" give a spacing of 50 m. (Assuming a
square pattern)
This gives some technical satisfaction and some relation to the average field conditions. Models
based on specific data points would not represent the watershed. In practice, all these N wells
would never be dug/drilled so that some ground water outflow would still take place from the
watershed. Plus, if a program of recharge augmentation through soil & water conservation
activities and forestation is undertaken by the agency promoting irrigational development, then it
would increase the recharge to ground water from rainfall. Furthermore, if the farmers use nonefficient, traditional irrigation methods then about 30 % of water applied for irrigation would
percolate below the root zone and reach the water table as "return flow". All these factors assure
sustainability.
At field level, the farmer is the owner of ground water and is free to drill anywhere he pleases.
The control on spacing or on pumpage is possible only through the Gramsabha (Village
meetings) and social pressure. But not many Gramsabhas are eager to implement this.
Government legislations are not effective at village level.
Groundwater management is thus skewed between the technical people who have no control at
the field level and the farmers who do not like the meddling by technical people, except advising
them on good locations for drilling / digging.
* MTISS is written not by ModelMuse but by MODFLOW when it creates the flow-transport
link file. MTISS will be set to indicate steady state conditions only if every stress period in the
flow model is a steady-state stress period.
* MTISS is written not by ModelMuse but by MODFLOW when it creates the flow-transport
link file. MTISS will be set to indicate steady state conditions only if every stress period in the
flow model is a steady-state stress period.
* if you want to know the input formats for MODFLOW there is an online guide you can
consult.
http://water.usgs.gov/nrp/gwsoftware/modflow2000/MFDOC/index.html?introduction.htm.
If you download MODFLOW from the USGS web site, it includes example models.
http://water.usgs.gov/nrp/gwsoftware/modflow2005/modflow2005.html
There are also a lot of graphical user interfaces for MODFLOW including ModelMuse, Argus
ONE, Visual MODFLOW, Groundwater Vistas, GMS, Processing MODFLOW for Windows,
Leapfrog Hydro, Processing MODFLOW for Windows, ...
* With regard to ITYPE = -1 or 15, you use those when the specified concentration source or
mass loading source when those sources are not associated with a flow boundary. For example,
if you have a non-aqueous phase liquid that is slow dissolving into the groundwater, you might
wish to model that as a specified concentration source.

* Numerical dispersion...reduce time steps and/or increase spatial resolution. This is a problem
that most transport models have.
* Actually, negative concentrations aren't the manifestation of numerical dispersion. Negative
concentrations are the lower part of numerical oscillations which are part of the solution of the
transport equation. Pete Sinton does point in the direction of minimizing this effect. Look into
the extensive literature on numerical analysis of the "advection-dispersion equation" if you want
to understand this more fully.
* Although ModelMuse can create MT3DMS models, it can not import existing MT3DMS
examples.
* The USGS version of MODFLOW does not use the h5-format so that would definitely be a
problem. Unit numbers should be positive integers. Unit numbers between 97 and 99 are used
internally by MODFLOW so you should avoid those. Otherwise, there are no restrictions on unit
numbers so 702-771 should be OK. You were correct to comment out the ASP file because that
isn't included in the USGS version of MODFLOW.
* It depends on the type of boundary condition. With a well and a constant head cell, the well
has no effect and the constant head is applied. If you have two wells in the same cell, both are
applied independently so the well flux into or out of the cell is the sum of the individual well
fluxes. Drains, rivers, general head boundaries, etc. are handled in the same way as wells.
* You can put more than one boundary condition in a cell. In your specific example,
MODFLOW will ignore the well in favor of the constant head. But that is a unique case. If the
constant head were a general head boundary, for example, then both the well and GHB would be
active at the same time. Likewise, if you had 6 river boundary conditions in the same cell, all
would be active.
* For calibration, you can add this well one of the calibration target and set the observed water
level to be ground surface. If the model predicted water level in the well is above observed level
then it is producing the artesian condition. Not sure why you would want to use drain though.
Drain takes water away from the model, such as a ditch, river and mine pit etc.
* If the water discharged from the flowing well is not being returned to the groundwater system
that you are modeling, using a drain cell to represent the flowing well is appropriate. If some or
all of the discharged water returns to the groundwater system that you are modeling (for
example, as recharge to a water-table aquifer), then simulating the discharge with the DrainReturn (DRT) Package would be more appropriate. In either case, the measured flow could be
used as a calibration target. You may want to define the conductance as a calibration parameter.
* The most obvious things to do would be to use the WEL package to simulate the well and the
RCH package to simulate recharge. At the location of the tank, you would increase the recharge
by the volumetric rate at which you expect water to leak from the tank divided by the area of the
tank. If you are not already using a graphical user interface, I suggest you use one. You have lots
of choices. ModelMuse, Argus ONE, Groundwater Vistas, Processing MODFLOW for
Windows, GMS, and Visual MODFLOW are some that come to mind. ModelMuse is free.
There is also a free version of Processing MODFLOW for Windows that works with an older
version of MODFLOW.
* The amount of error that is allowable is highly dependent on the data available to you and the
use to which the model will be put. A regional model in a data-poor area that will be used for
water resources planning can have a much larger acceptable mean error than can a site chemical
transport model that is used for litigation support, for example. Therefore, there are no solid

rules for the level of error that is acceptable in a given situation; it is a determination that must
be made by the individual modeler. Having said that, I often reference the Groundwater Vistas
manual, which states that the residual standard deviation divided by the range of observed
groundwater head elevation values "should be less than 10 percent for a good calibration." For
more in-depth background on model calibration, consider Hill and Tiedeman's Effective
Groundwater Model Calibration.
* Just to add one more thing, the accuracy desired sometimes rules the maximum error. For
example if we use a groundwater model to create drawdowns of 10m for mine dewatering, then
the maximum allowable error should be much smaller than that to achieve the desired
drawdowns. It should be also emphasized that all these errors i.e. mean error, maximum error,
root mean square error, NS coefficient, coefficient of residual mass etc. have specific meanings
and should be carefully stated not only to support the goodness of fit, but also to enlighten the
reader about the range of error that can exist when the model is used with varying stresses and
for different purposes.
* Consider also what is the maximal error at each observation well. Depending on calibration
item reliability (on the position, Z reference, well depth regarding the aquifer, water level
measurement accuracy, flow regime, etc), allowable error can be more or less important for each
item. Even if the error is an important achievement on the calibration process, never forget to
check if your model configuration has realism or not. There may be a need for an iterative
process between model calibration and observation data sets integration into the conceptual
model, unless this one has an excellent justified base.
* If a general head boundary is defined twice for the same cell in the same stress period, both
definitions are used; there will be two general head boundaries in the cell.
* You can use one of these packages to specify locations of flow observations to constant-head
cells or general-head boundaries and then compare the simulated flows to the observed ones.
http://water.usgs.gov/nrp/gwsoftware/modflow2000/MFDOC/index.html?chob.htm
http://water.usgs.gov/nrp/gwsoftware/modflow2000/MFDOC/index.html?gbob.htm
* Probably the best guide to all things Curve Number is the National Engineering Handbook Hydrology, produced by the USDA, Natural Resources Conservation Service. The handbook is
available online at http://www.nrcs.usda.gov/wps/portal/nrcs/detailfull/national/water/?&cid=stelprdb1043063
There is nothing in the development of the Curve Number procedure that gives guidance for
incorporation of a slope effect.
The Curve Number procedure was developed to deal with annual flood events. It deals with
total event rainfall and total event runoff. The runoff equation can be considered a
transformation of the frequency distribution for total event rainfall into a frequency distribution
for total event runoff. An example is shown in Fig. 10-5 in Chapter 10 of the National
Engineering Handbook-Hydrology, which is available online at
ftp://ftp.wcc.nrcs.usda.gov/wntsc/H&H/NEHhydrology/ch10.pdf
This emphasis on annual events limits the utility of the Curve Number procedure, as originally
developed, to events in which Ia is a small portion of the total rainfall. The procedure has,
however, been applied to continuous simulation. Obviously. continuous simulation treats many
events that do not fit the small Ia criteria. It is very difficult to ascertain guidance for adjusting

the procedure to be applicable to these small events using the fundamentals of the procedures
conception. Possibly an alternative approach that incorporates slope, rainfall intensity, rainfall
duration, surface condition and more would be useful.
* It is probably best to model a confining bed as a low-hydraulic conductivity unit, not as an
inactiver layer. Even a small amount of leakage can influence vertical gradients in the more
transmissive units. You can assign very low vertical conductivity to the confining unit, so
therefore you would have to describe the parameters.
* I think that this is a good guideline in general. Although not in peer-reviewed literature, Jim
Rumbaugh gives a general recommendation of scaled residual standard deviation of less than
10% in the GWV manual as well. Again, though, I would stress that this is not a hard and fast
rule. I'm currently working on a model where attaining that value of scaled RSD would require
a model constrained to a degree not supported by the available data. In other models, a scaled
RSD of much better than 10% could and should be achieved. However, I often use the 10% rule
when presenting model results to a lay audience to communicate the idea that the model errors
are within generally accepted bounds.
* That is a very common problem to have in areas of step topography where also the grid is not
fine enough to avoid cell disconnection. There are many ways to correct this, but I suggest you
try: 1) making your grid finer and/or increase the first layer thickness or 2) code a small
subroutine in fortran or Matlab to correct this. You need to export the model's topography and
bottom elevations as xyz files and then basically load them as matrices and do a loop to check
top elevation of cell (i,j) vs bottom elevation (i,j+1) of each disconnected layer and change bot
elevations according to what you need, usually you could define a minimum layer thickness and
iterate until you remove all disconnections.
* By itself, the situation you describe does not present any problems in MODFLOW. The
horizontal conductance between cells in the same layer is calculated using the average thickness
of the two cells regardless of the amounts of vertical overlap between them. The method of
calculating the average thickness is determined by the variable LAYAVG in the LPF package
(http://water.usgs.gov/nrp/gwsoftware/modflow2000/MFDOC/index.html?lpf.htm) or by
equivalent variables in the other flow packages.
However, steep gradients in topography can contribute to higher cells going dry if they are in
convertible layers. There are a number of suggestions for dealing with that situation as described
under question K on
http://water.usgs.gov/nrp/gwsoftware/modflow2000/MFDOC/index.html?frequently_asked_que
stions.htm. If you are using the wetting option in MODFLOW, it may be helpful to set it up so
that cells to the side of the dry cell can not cause a cell to convert from dry to wet. You could
also try using MODFLOW-NWT.
* You could use the wetting option in the flow package. The cells in the top layer will still go
dry initially but they can convert to wet if the heads in the layer below get high enough.
* In-Out is the discrepancy between what is simulated as entering the aquifer system and what
leaves. It should be small relative to the sizes of the fluxes. If you are using the recharge package
to simulate all your recharge, the recharge term in the flow budget is your recharge.
* MODFLOW doesn't have a maximum time step (unless you consider that computers only use
32 bits to store integers). However, if MODFLOW wasn't able to find a solution in a time step,
it would print an error message and stop. That is probably what happened to you. Look near the
end of the listing file generated by MODFLOW for error messages.

* The code detects the first active cell from the top to bottom based on their hydraulic head and
cell bottom elevation. Recharge is directly added to the top active cell. If a cell is surrounded by
inactive cells, no exchange will occur between the cell and surroundings. It is disconnected. You
can look it up from the formulas.
* If the volume where you want to have the impermeable area and underlying drain are currently
both in the same layer, you do need to subdivide the layer. This can be done the MODFLOW
Layer Groups dialog box either by inserting a new layer group or by increasing the discretization
of a layer group.
* What is the physical nature of the boundary conditions? For example, if it is something like a
lake, then it would be pretty reasonable to assume that the specified head will continue to be the
same into the future. If it is something else, like your model is just local model within a larger
groundwater basin, then you might want to reconsider using a specified head boundary.
One idea would be to replace the specified head boundary condition from the historical model
with a specified flow boundary condition (FHB package) for the future model. You could
estimate the specified flow rate by extracting the boundary flow rates out of your historical
models groundwater budget.
This assumption is generally pretty reasonable if you dont have anything else to go by.
Because for example, if you are pumping more under a future conditions scenario, it is
reasonable to assume that your neighbors (outside of the model area) will also be pumping more,
so the subsurface flux between you and your neighbor will remain unchanged from historical
conditions.
And remember this is just an idea; like I said above, the physical nature of the boundary
condition really dictates how it should be simulated in the model.
* For the mountain boundary, it is a reasonable assumption that the tributary drainage will
probably be the same in the future as it was in historical conditions. Thus, it would be
reasonable to assume the same specified flows for the scenarios that you used for the calibration
model. This would be a fairly simple approach, and you could get way more complex if you
wanted (such as incorporating future climate change).
For the subsurface flow from another basin to your study area, there are a few ideas for
estimating the future boundary conditions.
First, like I said above, one assumption is that the subsurface flow will remain the same in the
future as under historical conditions. The justification for this assumption is that your neighbors
will do behave the same as you do, and thus their activities wont alter the regional groundwater
flow gradient.
If you do want the flow to change for each scenario, another idea would be to use a general head
boundary condition (GHB package). To predict the head at the boundary in the future, you
could look at the trends in historical boundary heads and then extrapolate the heads for the
future.
Hope these ideas help. Determining future boundary conditions is one of the trickier parts of
groundwater modeling, and usually a large source of uncertainty.
* Why don't try injection well?, you can use a tributary area for recharge, like a flux and inject
direct over a screen, you can calibrate this wells within pest, there is will be non uniqueness and
a lot uncertainties, but for the first guess, i think it much more flexible, i thought.

* [ModelMuse] In the "Show Grid Values" dialog box, there should be an explanation of how
the values were assigned. You should check that explanation. Don't forget that recharge rates are
in units of length over time and that MODFLOW will multiply the recharge rate by the cell area
to get the recharge volume.
* Instead of starting out with MODFLOW, you might want to consider using an analytical
solution such as the one described by Hantush. (Hantush M.S. Growth and decay of groundwater
mounds in response to uniform percolation. Water Resources Research, 3 227-234. 1967).
* There are many different formats for DEMs. ModelMuse can read ones in the format described
in the DEM data users guide (http://nationalmap.gov/standards/demstds.html). Your DEM is
probably in a different format.
* Here is an easy work around to import the DEM into ModelMuse.
Export your grid to a 2D points shapefile (Export >Shapefile -> Export Grid Data to Shapefile).
In GIS, map the DEM elevations onto the shapefile
Import the shapefile back into ModelMuse (Import -> Shapefile).
The drawback to this approach is that if you change your model grid, you will have to redo this
process. But it only takes a few minutes to do.
* The principle of superposition states that problem solutions can be added together to obtain
composite solutions. note: This principle applies to linear systems. The tributary area depends
your geological settings and the precipitation within the area to calculate a flux:
http://funnel.sfsu.edu/students/student/courses/G475_775/Tutorial/WinPest/VMOD_WinPEST_
Tutorial.pdf
They use a specified flux located at the Western boundary of the model have a positive pumping
rate - these are used to simulate a specified flow across the boundary and into the model
domain.
* Trescott (1976) offers an expression that will allow you to estimate the head in a well within a
cell.
hw = hij - Qw/(2*pi*Tij) * ln(re/rw)
where
hw is the head at the well
hij is the head in the cell (i,j) containing the well
Qw is the pumping rate of the well
Tij is the transmissivity in the cell (i,j) containing the well
re is the "effective" radius of the cell
rw is the radius of the well
For regular grids, the parameter re may be estimated as re = 0.208*a where a is the row/column
spacing. Note that the Trescott formula does not account for effects of partial penetration, well
screen efficiency (or "skin" effect), etc.
Another way to do this is to use the MODFLOW package MNW, which allows you to use the
well-loss equation (see e.g. Jacob (1947) and later papers of Hantush and Rorabaugh. A fairly

good summary is in Wikipedia (http://en.wikipedia.org/wiki/Well_test). Take a look at the

MNW package documentation.
* The length of the steady state stress period has no effect on the heads calculated by
MODFLOW. It can affect how far particles in MODPATH travel.
* In my opinion, if your flow is in steady state and you get no errors for dry cells, it should be no
problem. Based on my experience, to refine the transport time steps and mesh density will make
the mass balance better. And also check the boundary conditions. I do not know which solver
you used in MT3DMS and how large is your model scale and resolution. As well, what type of
the tracer is, is it nonreactive or reactive? I suggest you using "3TVD" or 'HMOC' scheme to
solve the transport approach again to check the mass balance. It is better not using "upstream"
scheme when your model is big and with a lot of grids.
* You could use a very low hydraulic conductivity value in the cells where the foundation is to
simulate the very low K of concrete. Make sure that your model layers are setup so that bottom
of the layer coincides with the base of the foundation. Then you can assign normal hydraulic
properties to the model layers below the foundation to property simulate groundwater flow
under the foundation. A drain would be a very bad way to simulate the foundation. You would
simulating removal of water from the aquifer which in reality is not taking place
* You can add the well package to introduce flow into the bottom. Positive values of the well
pumping rate are injection of water. I would probably model this as having 1 row, 1 column and
as many layers as you want. In MODFLOW-2000 there are a maximum of 999 layers. In
MODFLOW-2005, there is no limit on the number of layers.
* If you want a plot of MT3DMS results vs time, you can do this with GW_Chart but not
ModelMuse.
* For salt water intrusion, you can generate your model in ModelMUSE as an MT3DMS model.
Then all you have to do is create the variable density flow (VDF) file externally. This file is
extremely simple to make (it is only 5 lines), and the user's guide that comes with SEAWAT is
pretty clear in explaining how to set the file up.
* The finite difference mesh cannot be changed since the partial differential equation is solved at
the node elements of the mesh. By definition itself you cannot change the mesh by looking at the
method followed to solve the equation. However what you can change is the values at different
nodes of the mesh, for eg elevation conductivity etc. to represent structure changes.
* The error message is for the constant heads in the top cells. Check that the specified head is
higher than the bottom elevation of the specified head cells in the cells that are constant head
boundaries.
* GW_Chart can plot drawdowns calculated and saved by MODFLOW. However, drawdowns
are not suitable for use as initial heads. Instead, you should use the final heads calculated by
MODFLOW as initial heads for consecutive runs. If you want to use the final heads as initial
heads, you will need to extract the final heads from the file generated by MODFLOW. If you are
using a graphical user interface, it may be able to do that for you. Another option is
MFBIN2RASTER http://water.usgs.gov/software/FiveModflowUtilities/.
* MODFLOW is probably not the ideal software to use separate base flow. However, to do it,
you can simulate the streams using the Streamflow-Routing Package (SFR). The SFR output
budget contains the groundwater contribution to streamflow which you can compare to the total
flow in the stream. The one trick is that the overland runoff typically needs to be calculated

externally from MODFLOW. It can also be estimated by using the MODFLOW Farm Process,
but that definitely eliminates your "easy to use" requirement.
* Check that the heads in the stream cells are higher than the bases of those cells. If they aren't
MODFLOW will print an error message and quit.
* For salt water intrusion, you can generate your model in ModelMuse as an MT3DMS model.
Then all you have to do is create the variable density flow (VDF) file externally as well as
change the name file to point to everything. The VDF file is extremely simple to make (it is
only 5 lines), and the user's guide that comes with SEAWAT is pretty clear in explaining how to
set the file up.
* When you run modflow, you can find a *.cbc file which contains the cell by cell budget info.
You can analyze these file results easily using GW chart from USGS.
* UCODE is changing the values of parameters in the .pval file. You should check that the
parameter values it assigns are reasonable. For example, is it assigning a negative value of
hydraulic conductivity? If so, you can use the "Transform" option in ModelMate so that
UCODE works with the log of they hydraulic conductivity instead of the hydraulic conductivity
itself. That will prevent the hydraulic conductivity from ever becoming negative. You should
also look at the listing file produced by MODFLOW when it is being run by UCODE. You
should look for any error messages in it. If any are present, they will probably be near the end of
the file.
* If the shapefile is a 3D shapefile, then the elevation will be recognized automatically during
import; just ignore the elevation value that shows as zero during the import. You can check this
after import, by showing the shp file in a 3d viewer to see if Elevation was imported correctly.
* With regard to the lake stage being approximately equal to the outlet be elevation, this isn't
surprising if you have only a little bit of water entering the lake. I suggest you look at the water
budget for the lake and manually calculate the expected stage in the outlet stream given the
amount of water that is flowing out of the lake into the stream. With regard to IPRIOR, the SFR
package only allows IPRIOR to be specified when diverting water from another stream. It can't
be specified when diverting water from lakes.
* ModelMuse can show pathlines from MODPATH but it uses color rather than arrows to show
direction.
* You might be able to use the General Head Boundary to simulate the ocean boundary by
progressively turning off the General Head Boundary cells as the sea level drops. Still, I have to
wonder why you would want to simulate a drop in sea-level by 2000 m. That seems large even
for Ice-Age conditions.
* The first thing to do would be to read the MODFLOW manual. You can get it with the
program itself at http://water.usgs.gov/nrp/gwsoftware/modflow2005/modflow2005.html. If you
haven't used MODFLOW before, you will probably also want to get a graphical user interface
for it. There are a number of them available. The ones that spring to mind are :
ModelMuse
Argus ONE
Groundwater Vistas
Visual MODFLOW
GMS
Processing MODFLOW for Windows

Leapfrog Hydro
Time in MODFLOW is divided into stress periods which are subdivided into time steps. In each
stress period, you can change the definition of the boundary conditions so to turn off a specific
general head boundary cell, you just wouldn't include it in the stress periods for which its
elevation was no longer below sea level. MODFLOW also has specified head boundaries.
Unfortunately for your particular situation, MODFLOW does not allow you to turn off specified
head boundaries.
* If just the location is wrong, you can move the model with some effort but if it requires more
than that, you may need to start over. Making it easy to move the entire model is something that
is on my list of things to do for ModelMuse that I haven't done yet. You can move any objects
by selecting "Object|Edit|Scale, Rotate, and Move Objects..." If the grid angle is zero, you can
move the grid by selecting "Grid|Specify Grid Lines..." and and entering new coordinates for the
grid lines. You could copy all the grid lines positions to the clipboard, paste them in a
spreadsheet, modify them there and pasting back the new values into the ModelMuse dialog
box. If the grid angle is not zero, you can do the same thing but you will have to use some
trigonometry to figure out the correct grid line positions.
* A data set for transmissivity is automatically created if the BCF package is used. However,
transmissivity is only used for confined aquifers in the BCF package. Transmissivity is
calculated internally in the other flow packages based on the hydraulic conductivity and
saturated thickness. If you have transmissivity data that you want to use and you are not using
the BCF package, you can create your own data sets for transmissivity and then use them to help
define hydraulic conductivity.
* The most obvious possible problem is you are entering your pumping rate (GPM, or whatever
you are using) as POSITIVE numbers rather than NEGATIVE numbers. You MUST enter
pumping rates as negative numbers, e.g. -5 . If you enter as positive numbers, you have created
an INJECTION well rather than a pumping well. This would certainly explain your much higher
heads. If you look at the cross section through your wells, you should also see groundwater
mounds instead of CODs at the wells if your pumping rates are "positive".
If that doesn't fix your problem, I highly recommend you post your question on the MODFLOW
and Visual MODFLOW forums on LinkedIn. If you do not already belong to those forums, they
are free to join and you will get many more responses to your question by posting there. You
will need to post additional information, such as hydraulic conductivities in your various layers
and lithologies, screen lengths and depths of wells, pumping rates. Also, what does the model
show without pumping anything? Do you get good water levels that show static conditions you
see in nature?
* You can use ZoneBudget to determine the water budget for each layer. You would need to
make each layer a separate zone. ZoneBudget is supported by ModelMuse. You could also use
ZoneBudget to determine whether flow is into or out of a GHB cell. However, there is an easier
way. Instead of importing the heads from the head file generated by MODFLOW, you can
import flows from the cell-by-cell flow file (.cbc file). Positive values represent flow into the
cell. Negative values represent flow out of the cell.
* I reported the problem with MODFLOW-NWT version 1.08 on Windows XP some time ago
to the parties responsible for maintaining it.Nothing has been done about it so far. MODFLOWNWT version 1.08 will run on Windows 7 as a 32 bit program but will not run on Windows XP.
MODFLOW-NWT version 1.07 will run on Windows XP. If you don't already have version
1.07, you can download it from the following URL.

http://water.usgs.gov/nrp/gwsoftware/modflow_nwt/MODFLOW-NWT_1.0.7.zip
You could also try compiling MODLOW-NWT yourself. There are instructions for compiling
MODFLOW with various compilers at
http://water.usgs.gov/nrp/gwsoftware/modflow_nwt/Guide/index.html?suggestions_on_compilin
g.htm. You might be able to adapt them for MODFLOW-NWT. If you don't have a compiler,
gfortran is a free fortran compiler.
* If the pit is being kept dry by being pumped, you could use the drain package. If the pit is
allowed to fill with water, the lake package might work.
* I think it can although you would want to use the 64-bit version to handle a model that big.
With a model that big you will almost certainly need to use the GMG solver. The other solvers
run into problems when the number of cells get too large. Also it would be a good idea to make
sure that your data are not much more closely spaced than the size of your grid cells; if you try
to use a DEM with a 1 m spacing directly even though your grid spacing is 100 m you are likely
to run into problems. To keep your file size reasonable, save the ModelMuse file as a .mmZLib
file rather than a .gpt file. The .mmZLib file is a compressed binary file rather than a text file
like the .gpt file.
* The rates for each time step will be different. To get the cumulative volume, you need to add
up the rate for each time step by the length of that time step.
* The next release of ModelMuse will generate a warning message about GHB cells that identify
GHB cells with heads that will cause problems with MODFLOW-NWT. If someone needs that
feature now, they can contact me at my work email: rbwinst@usgs.gov.
* The ideal solution (in the public domain) would be to write a little script that compares GHB
head to DIS elevations and discard GHB cells. This way you would know how many cells are
discarded and you can adjust your criteria to minimize elimination (if desired). Any flavor of
Python, Perl, etc. will do.
* Modeling pits with Modflow:
Assuming you are trying to run some simple dewatering predictions, use the drain package. You
don't need simulate the physical excavation of material during dewatering, as it will be above the
water table. Intersect the final pit shell with the model grid, extract the elevations. Assign the
elevations to the corresponding model cells and interpolate these to your model time steps in the
drain package. Be careful with the conductance term as it is often the source of numerical
instability. If you have multiple pit shells through time, you can use these too, depending on the
level of detail desired.
If you need to estimate the number of wells required for dewatering, simply divide the discharge
by well yield. The actual number of wells needed will end up being a trial and error process
anyway, no need to be too precise at this point. It is best to have pilot dewatering well(s) in order
to get the estimate of yield. For pit lake recovery, you can use the lake package. For recovery
you will need to alter your model properties to represent the physical excavation of the pit.
Lastly, you may find it useful or necessary to use the MODFLOW-SURFACT code for
numerical stability in such simulations. I understand that MODFLOW-USG is supposed to
address this issue, but have had limited success with it thus far.
* In FEFLOW 6.0, a graphical interface for PEST is only available in the so-called 'classic'
version of the GUI, and this is based on a very old PEST version not supporting any newer

features. Alternatively, PEST can be used as stand-alone software in combination with

FEFLOW. The basic procedure for this is described in Step-by-step example for using standalone PEST with FEFLOW available from http://www.feflow.com/miscellaneous.html.
Please note that the current version FEFLOW 6.2 contains a full graphical interface for PEST
use with FEFLOW.
* If you are using ModelMuse, select "Model|MODFLOW Options" and go to the "Options" tab.
There is a place for the file name on that tab. If you are using a text editor, you would open the
name file in the text editor and include the head file as a "DATA(BINARY)" file. Then in the
Basic package, you would use the unit number assigned to the head file as the unit number from
which the initial heads should be read. The heads are written to the head file starting with the
first layer and ending with the lowest layer. MODFLOW will read the heads from the file in the
same order so you don't need to worry about reading data from the correct layer.
* The lake cells are inactive and depending upon other parameters such as conductance and
bottom elevation the drawdowns, heads etc. in the neighboring cells are calculated. For
measuring the aquifer response the lake cells will act as sink until the neighboring cells have
heads higher than the bottom elevation of the lake. In a case the bottom elevation is higher than
the heads in the neighboring cells, it will stop extracting water.
* The lake itself is treated as a place where no aquifer is present. Because no aquifer is present,
no groundwater flow is simulated in the lake itself and the Lake package requires that any lake
cells be inactive. Nevertheless, the lake package uses the lake cells to determine the volume that
is available to be filled by the lake water. The actual flow into or out of the lake occurs through
the active cells immediately adjacent to the lake including the cells immediately below the lake.
* How to adjust a model that is not converging - You could try using shorter time steps. It also
might be useful to look at the heads for time steps prior to the non-convergence to see if they are
reasonable. You could also try using just confined layers until you have a better handle on what
is going on and only then convert them to unconfined.
* Assuming that the model is able to run with confined layers, take a look at the simulated heads
and identify locations where there are unusual or unrealistic heads and see if you can figure out
what is causing them.
* Choosing a different non-linear solver gives a different linear system to be solved which might
help some times. I've also observed that problems with confined layers are usually easier to
solve for the linear solver than those with unconfined layers. Your model seems to fit into that as
well. Have you tried increasing the maximum number of iterations for the PCG solver? Maybe
its convergence is just really really bad and it takes a lot of iterations to solve the system. If this
is the case, increasing the number of maximum iterations might help solving the problem
although it might be pretty slow and thus not feasible for day-to-day use.
* If you edit multiple objects and the objects all define the same sort of feature such as a river,
ModelMuse attempts to display the parts of the definitions that are the same. In your case, it
sounds like the times at which river boundaries were defined but the properties of the rivers
differed. To get your edits to be accepted, you would have to change the definitions so that
everything about them was the same. For rivers, that would mean defining not only the times at
which the rivers were defined but also the river elevation and boundary head.
I'm surprised that you got the warning about "objects define times at which stresses change that
were not defined as the beginning or ending or stress periods". When you import a model, the
times for the defining boundary features such as rivers would normally correspond to the stress

periods. By any chance, did you change the definitions of the stress periods? That could account
for why you got the warning message.
* Based on what you have said earlier, it sounds like you changed the length of the first stress
period from 1 to 10. Because this is a steady state model, the length of the stress period does not
affect the solution. With regard to editing the head in the upstream boundaries, the ease or
difficulty will depend a lot on what sort of editing you want to do. You mentioned that you
wanted to change the heads of the upstream GHB boundaries. Here is how I would go about
doing that.
In the model you sent me earlier on Jan 10, you have 14 objects that together define 1215
general head boundaries. The GHB boundaries are all either on the northern or southwestern
boundaries. Each object defines GHB boundaries for a separate layer but some of those GHB
boundaries are in the north and others are in the southwest. To make editing easier, I would split
each object that defines GHB boundaries in both the north and southwest into two separate parts:
a northern part and a southwestern part. For example, the object named
"Imported_GHB_StressPeriod1_Layer2_6" defines 288 such boundaries. I would first select that
object and then select "Object|Select Vertices". Next, I would drag the mouse cursor around the
vertices of the object that are in the north so that all of them were selected and then select
"Object|Edit|Make Selected Vertices a Separate Object." It looks like the upstream end of the
model is on the southwest so I would double-click on that object and enter a new formula for the
boundary head. The current formula is ObjectImportedValuesR("GhbHead6"). If I look at the
Imported Data tab for this object, I see that all the heads are 1576.5. Because they are all the
same, I could just use 1576.5 as the formula for the boundary head instead of
ObjectImportedValuesR("GhbHead6"). If I wanted to raise all the heads by 1. I could just set to
formula to either 1577.5 or 'ObjectImportedValuesR("GhbHead6") + 1'. (I would use the latter if
the heads were not all the same and I wanted to increase them all by 1.) If I just wanted to edit
some of the heads for the object, I could split out the vertices for the object I wanted to edit as
was done before to split the northern form the southwestern vertices and edit the new object.
Another alternative would be to create a new data set that defines the elevations the way you
want them and then to use that data set in the formula for the boundary heads.
* Each branch of the river can be treated as defining separate river cells. It is OK if two or more
river boundaries are located in the same cell. If the river is narrow enough relative to the width
of the cells that both branches of the bifurcation are always in the same cell, it might be
convenient to ignore the bifurcation and calculate the conductance of the river cell using the sum
of the widths of the individual river branches.
* You can combine the following functions plus a healthy dose of trigonometry and the grid
angle to get the X', Y' coordinates of the vertex of an object.
ObjectCurrentVertexX
ObjectCurrentVertexY
ColumnBoundaryPosition
RowBoundaryPosition
You will also need some of the trigonometry functions included in ModelMuse. You can
determine the grid angle by selecting "Grid|Specify Grid Angle". You can use
LayerBoundaryPosition to get the elevation of the top of any cell. Interpolating the elevation of
the top of the model to arbitrary positions could be tricky if you have to deal with points outside
the grid or with points in the first or last row or column. By the way, when creating the input file
for the Head Observation package, ModelMuse uses the precise location of the object defining
the observation to determine the correct column and row offset to use in the head observation
package input.

* Dry cells during pumping 1. Check that the units used for specifying the hydraulic conductivity and pumping rate are
consistent. For example, if hydraulic conductivity is specified in meters per second, the pumping
rate must be specified in cubic meters per second.
2. Check that the hydraulic conductivity is reasonable given the rate at which you are extracting
water. It sounds like the hydraulic conductivity is too low.
3. You didn't say which cells could be used to re-wet the dry cells. MODFLOW gives two
options: the cell directly below the dry cell or both the underlying cell and the horizontally
adjacent cells. For a dry cell in the bottom layer, only the second choice will allow a dry cell to
convert to wet again.
* ModelMuse will count the number of river reaches and use that to specify MXACTR. The user
does not need to specify it directly. You can use the same strategy if you are creating the input
file manually.
* An updated version of ModelMuse, a graphical user interface for groundwater models, was
released on Feb. 28, 2014. http://water.usgs.gov/nrp/gwsoftware/ModelMuse/ModelMuse.html
The new version adds support for the groundwater modeling program SUTRA. SUTRA is well
suited for modeling problems involving complex geometry or saltwater intrusion. Other changes
in the new version of ModelMuse include but are not limited to the following.
Added support for the Stream package in MODFLOW.
Added support for the Stream Observations package in MODFLOW.
Added support for the Flow and Head Boundary package in MODFLOW.
Added support for importing MODFLOW-NWT models.
Added support for MODFLOW-LGR version 2.
A report on the new version of ModelMuse is available in the USGS Publications Warehouse at
http://pubs.usgs.gov/tm/06/a49/.
* ZONEBUDGET should work just the same with both steady-state and transient models.
However, I can think of two ways you might run into problems. ZONEBUDGET uses the cellby-cell budget file (.cbc file) generated by MODFLOW as part of its input. If your model failed
to converge on the first time step, that file would be empty. Also if you tried to run
ZONEBUDGET in a directory that did not have the cell-by-cell budget file or that had a
different name from the name you are using with your model, ZONEBUDGET would not be
able to find the .cbc file. I suggest you look at the listing file generated by ZONEBUDGET and
see if it printed any error messages.
* Zonebudeget3_01.exe is the installer for ZONEBUDGET rather than ZONEBUDGET itself.
You should run that program outside of ModelMuse to install ZONEBUDGET. You then need
to find ZONEBUDGET on your computer. It will probably be at
C:\WRDAPP\Zonbud.3_0\Bin\zonbud.exe. You need to specify the location of
ZONEBUDGET in the "Model|MODFLOW Program Locations" dialog box. You mentioned
that you aren't able to change its location there. That was a bug in certain beta versions of
ModelMuse. You should get the latest version of ModelMuse released on Feb. 28, 2014. That
bug was fixed in the released version.

* If you want to simulate a wall or some similar barrier across a section of the model, you could
use the Horizontal Flow Barrier package. If you are trying to simulate a low permeability zone
around a well screen, you can use the Multinode Well package.
* If you want to run MODFLOW from a batch file, something like this should work.
C:\WRDAPP\MF2005.1_11\bin\mf2005.exe example.nam
pause
* With the stream package you have the option to assign the discharge and let the model
calculate the stages. During the dry season just assign 0 discharge.
* The flag ICALC in the STR package controls the calculation of the stage using Manning's
equation provided you specified the inflows. As a matter of fact to simulate dry conditions you
can simply assign no inflows. However, it is a different story if your segment is connected to
another upstream segment which means that you have assigned -1 in the inflow section. There
could be two possibilities you have not specified in your previous email:
1) the upstream segment is dry as well during the dry seasons: in this case you do not have to do
anything with your downstream segment but you can simply assign no inflows to the upstream
segment
2) water flows along the upstream segment, but there is no water in the downstream segment: in
this case you have to calibrate the conductance parameter to simulate the water front expression
during the dry seasons along the first and second segment.
* As you said the conductance is calculated from the width of the channel, the thickness of the
streambed and the conductivity. Assuming that W and M are measurable you have to calibrate K
in order to make the water disappear in the second section of the channel. You can verify it by
checking the calculated discharges along the segments of the channel, provided you use
ICALC>0 and let the package route the flows. You should calibrate K in order to make Q=0 at
the desired distance of the second segment of the channel.
* Did you remember to convert the units? The units of the mass flux are mass per unit time
(M/T) whereas the units of concentration are mass per unit volume (M/L^3) so to convert the
units, you must multiply the mass flux by the time step length and divide by the cell volume.
Assuming that the movement of solute out of the cell is negligible, that would be your expected
concentration in the cell.
* Dr. Zheng, the author of MT3DMS has a utility program called PM, it is included in the
distribution package of MT3DMS. The package can be downloaded from the following link
http://hydro.geo.ua.edu/mt3d/. The utility program can be used to extract the concentration data
from UCN file. The utility is written using FORTRAN, and the source code is available if you
want to make change to the program.
* You can get the manual for MODPATH version 6 from http://water.usgs.gov/ogw/modpath/
* There is a utility program distributed with MT3DMS, the utility program called PM. It can
extract the cross-section data along a row and column, and export the plot to ASCII, GRD, and
tecplot format. The source code of the utility program is available too, and you can manipulate
the code if you have some knowledge of Fortran programming language.

* Streams in the STR and SFR packages need to be arranged in downstream order because the
water in the stream is routed from one cell to the next. In the River package, there is no
downstream routing so there is no need to arrange the river reaches in any particular order.
http://water.usgs.gov/nrp/gwsoftware/modflow2000/MFDOC/index.html?riv.htm
* Submersible pumps (deep pumping) could be used with following precautions:
1. The ground water occurring at this depth is likely to have more TDS. The salts in water could
corrode the threading of steel pipeline of 3000 feet length and if any of the joint breaks the pump
is lost. A cage woven from nylon ropes is necessary to support the weight of the pump & pipeline.
2. The possibility of using a continuous PVC pipe-line should also be considered so as to
eliminate corrosion at the joints of a metallic pipe-line.
3. People working at field level in petroleus industry could give more information.
4. Please inform the quantity of water to be pumped per hour and also the proposed use of
ground water pumped from such depth.
* If you were using GW_Chart to looking at the head of a specified head cell, the head in that
cell would not be affected by the hydraulic conductivity. Only the head in cells that are not
specified head cells will be affected by the hydraulic conductivity.
* If you are using the Stream package or the Streamflow Routing package, water in the stream in
routed from one stream reach to the next. I think that is the "Stream Flow Out" term. This
routing of water is not part of the groundwater budget because it is surface water.
* USGS released an updated version of ModelMuse that includes support for the Seawater
Intrusion (SWI2) package. It also allows you to display a cross sectional view of the water table,
the ZETA values from the SWI2 package or other suitable data sets.
* The riverbed elevation could be sensitive in case it is significant compared with the layer
depth.
Since none of the DEM datasets methods could resolve the water body issue, bathymetry could
be effective if available. Or single site cross section data can be used to interpolate using some
tools?
* The cumulative budget is the running total of all inflows and outflows to the aquifer. It sums
all of the volume gained/lost by the cells for each time step (or just all cells for a steady state
model). The recharge term would be the total amount of water added to the aquifer for all stress
periods up to and including the time step you are printing.
* If there is groundwater flow into a cell, some of that flow can discharge as surface leakage.
* Negative results in ModelMuse - This sort of problem is often due to problems with the way
the model is set up. For example, if there is a lot of recharge to a cell with very low hydraulic
conductivity, you can get this sort of result. You can also get this sort of result in transient
models if there isn't any place where water can leave the system.
* First of all, when you are modeling a coastal aquifer you should be using SEAWAT. The
Constant Head and Constant Concentration cells used to simulate the saltwater boundary should
be applied along the top of the sloping sea floor (that is, the top edge boundary of the aquifer
where we know the head and concentration of the seawater). If you have the topography of the
sea floor this is easy to do, and SEAWAT will calculate the distribution of Equivalent
Freshwater Head and salt concentration that are the saltwater wedge within the aquifer.

If you do not have information about the slope of the sea floor, but you do have multi-level
monitoring wells along the seacoast with the vertical distribution of head and salt concentration
downward into the aquifer, you can assign Constant Head and Constant Concentration cells
vertically downward through the aquifer along the sea edge. However, this is an approximation
of the saltwater wedge that exists within the aquifer because you are assigning the Constant
Head/Conc cells in the aquifer material and not at the boundary with the salt water.
* The input to the SFR package requires elevations at the beginning and end of a stream
segment. MODFLOW interpolates between those values based on the length of the segment in
each cell.
* The extension SFR indicates that the problem is in the SFR package. ModelMuse uses free
format for the SFR input but that was first supported in MODFLOW: version 1.10. You should
check the listing file that was generated. At the top, it should say which version of MODFLOW
you were running. You should check that to make sure you were running the right version. You
can also look at where MODFLOW stopped writing output to identify where the error is.
However, if you are really using the latest version of MODFLOW, that won't solve your
problem because the problem is in ModelMuse.
* When you start a new model in ModelMuse the initial dialog box allows you to specify the
number of layers and elevations of the layers. Later on, you can change the number of layers in
the "Model|MODFLOW Layer Group" dialog box. You can change the layer elevations in the
"Data|Edit Data Sets" dialog box.
* If a stream is in a cell that is inactive, MODFLOW will search the layers below for an active
cell at the same row and column location. Another thing to keep in mind is that the cells that
comprise a lake are always inactive cells as far as groundwater flow is concerned. Thus, if a
stream and a lake are in the same cell, the stream will be moved to the cell underneath the lake.
Maybe the best way to handle it is to only activate the stream segments that overlap with the
lake in the stress periods in which the lake is dry. When the lake is wet, make the streams
inactive and have the segment that would normally flow into the overlapped segment flow into
the lake instead. However, you will have to manually specify when the stream should be active
or inactive; MODFLOW will not be able to do that.
* The first thing I would do would be to check for changes in the overall water budget especially
for changes in the amount of recharge. If the amount of recharge is higher in the MODFLOWNWT model than in the MODFLOW-2005, it may be that some of the recharge in the
MODFLOW-2005 model went into dry cells where it would be ignored.
* LAYWET indicates that a layer can convert from dry to wet. This is separate from whether a
layer is confined or unconfined. If the recharge was different in the two models, I would try to
figure out where the recharge was getting lost in the MODFLOW-2005 model by plotting the
recharge flux for each cell from the cell-by-cell flow file.
* Simulate welt lands using GSFLOW - I think the SFR package would work. You could use the
8-point channel
option to define the flood plains so long as the flood plain width is less than the width of a cell. I
think the Wetland Package was developed by the South Florida Water Management district
rather than the USGS so it is not available from the USGS.
* You can use the Saltwater Intrusion (SWI) package in MODFLOW. SWI is supported by
several GUIs including ModelMuse. SEAWAT would be another option.
* I see three options.

1. Extract the heads from the head output file instead of the listing file.
2. Use the Head Observations package to get the heads you want.
3. Use the HYDMOD package to get the heads you want.
* ModelMuse is free while PMWIN is a commercial software. PMWIN 5.3 is freeware, but it is
an old version (now PMWIN 8 is sold) adopting also an old version of MODLFOW (I think
previous to MF2000). The creation of the data is based on matrix and if I remember correctly
you cannot use shapefiles. I found ModelMuse very simple to learn and also useful. The
documentation available online is really detailed. It uses the latest versions of Modflow which
sometimes are not supported neither by competitor SW. The pre-processing supports shapefiles
and lots of other formats. Moreover since it is a free software sometimes issue happen: but that's
the same with Commercial SW and the developer of ModelMuse is releasing every year or less a
new debugged version.
* The nonlinearities occur if any aquifer is unconfined or if a head dependent boundary
condition is nonlinear (See PCG document).
* As I understand it, GMS can create the input for MODFLOW in either of two formats. If I
remember correctly, one format is a binary HDF5 file. The other format is very similar but not
identical to the text file format used by the USGS version of MODFLOW. The GMS version of
the input files allows for quotation marks around file names so that file names can contain
spaces. The USGS version of MODFLOW does not accept quotation marks and spaces in file
names are not allowed. With either the HDF5 or the text file format, you would need to use the
GMS version of MODFLOW to run the model. If you wanted to alter the model, you would
need to alter the input files and if you did that correctly, you should be able to run MODFLOW
without using GMS. I think the GMS developers have published on how they are using the
HDF5 file format with MODFLOW so you might want to research that.
If you wanted to work with the text file format, you could look at how ModelMuse imports
existing models. It uses a stripped down version of MODFLOW called ModflowImporter that
just reads the MODFLOW input and prints it in a form that is easy for ModelMuse to interpret.
The source code for ModflowImporter is included with the ModelMuse source code at
http://water.usgs.gov/nrp/gwsoftware/ModelMuse/ModelMuse.html. ModflowImporter only
reads the standard MODFLOW file formats not the ones used in GMS so to import GMS
models, the user needs to make some minor changes to the input files to make sure they conform
to the standard format.
* One difference is that an active cell with K = 0 can still accept recharge. In a steady-state
model, that would prevent convergence. In a
transient model, the head in the cell would get higher on each time step. Neither is a good result
so you should not attempt to disable
cells by assigning K = 0 because it doesn't really work.
* Inactive cells are NOT included in computation. But K=0 will still be computed. There will be
no flow to or from the cell in both cases; however for "K=0" there can be storage variation.
* In order to avoid the problem of the model convergence, you have to consider a bedrock
outcrop as inactive cells.
* The methodology of using HDF5 for GMS' version of MODFLOW was recently in
Groundwater, see https://dx.doi.org/10.1111/gwat.12060 Visit
http://www.et.byu.edu/~njones/modflow-hdf5/ more on this. Be aware that the HDF5 extension
is non-standard, and only GMS supports it at the moment. The HDF5 MODFLOW files can be
modified outside of GMS, and you can use command-line tools like h5diff e.g. to see what

changes were made by altering well pump rates within the GMS GUI. And you can re-run the
simulation using mf2k5_h5.exe from a console. Also with GMS, you use the "Save native text
copy" option, which stores everything under a prefix_MODFLOW_text folder, which I think is
mostly compatible with USGS' executables by not using HDF5 formats and removing quote
characters in paths specified in the name file (as Richard mentioned earlier).
* The following video shows how to assign values to different layers of the same data set.
http://water.usgs.gov/nrp/gwsoftware/ModelMuse/DataSets/DataSets.html
You can change the selected layers with the "Model Cube" in the corner of the top view of the
model.
* Specific storage generally is several orders of magnitude *smaller* than specific yield. Ss is
unit-dependent, but even so, this is true for any length unit likely to be used in a model. A
typical value for Ss would be about 1.0e-6/ft.
* Weights are used in calibration. Higher weights are assigned to observation boreholes in the
main study area and/or where you have greater confidence in the observation dataset. Weights
are also used on observation boreholes to be Pest calibration.
* Modflow has a lot of packages that allow it to simulate boundaries and other processes not
present in the base code. For instance, MT3DMS and SeaWat allow modeling of solute and
energy fluxes and variable density flow. Sutra does not have modular packages that add on, but
it can consider solute and energy (which it treats as a solute) flux and variable density flow
natively without additional packages. I think that in order to add boundaries not included in the
base model, rather than turning on a package, the Sutra code must be modified and recompiled.
Modflow requires less computational power than Sutra (generally), but because it is a finite
difference grid, rather than a finite element mesh, you cannot refine cells around areas of interest
as easily.
There are many GUIs that can be used to pre-and-post-process model inputs and outputs for both
modeling packages. Some are better than others and the prices vary considerably. Model Muse
is freeware from the USGS. The GUI works with both Modflow and Sutra, so it may be a good
place for you to play with both modeling packages to see which one better fits your needs.
* We have added capability in MT3D to handle the issues you both are likely facing. The new
options can handle the following: (1) cell-by-cell transport if flow is passing through a dry cell
as can happen when using MODFLOW-NWT; (2) inflow from boundary conditions like
recharge passing through a dry cell and solute transport associated with that (with the RCH
package option NRCHOP=3, NWT applies the recharge on the highest active cell, and if that
cell is dry then water percolates through the dry cell depending on the Kv of that cell); and (3)
solute storage change in transient flow simulations as a cell dries and rewets.
* The specification varies between MODFLOW 2000 and 2005. We experienced that the SFR
input file for mf2005 is not compatible with mf2k.
* The manual (SWI2, Seawater intrusion package)is at the following URL:
http://pubs.usgs.gov/tm/6a46/. MODFLOW comes with example input files for the SWI2
package. ModelMuse can be used for pre- and post-processing for SWI2.
* In general, what you need to do is to specify the IBOUND array differently for each layer so
that cells are only active in the areas where that unit is actually present. In ModelMuse, you
would do this through the "Active" data set. You would first set the default formula for the
Active Data set to false. Then for each layer, you would create one or more objects that set the

Active data set to true for the areas where the related geologic unit is present. There are other
ways of accomplishing the same goal but this is the most straight forward way.
* The numbers outlined in red are "FIXED-FORMAT CONTROL RECORD" in the " Array
Reading Utility Module" U2DREL. The numbers outlined in yellow are the the values of the
array that is being read. For more information, see the following URL.
http://water.usgs.gov/nrp/gwsoftware/modflow2000/MFDOC/index.html?array_reading_utility_
modules.htm
* If you are using the River Observation package, the simulated value computed by MODFLOW
is the net flow between all the river cells included in the observation and the groundwater
system. Thus, there isn't a single point where the comparison is made but rather the value is
spread over a number of locations. For more information, see
http://pubs.er.usgs.gov/publication/ofr00184.
In ModelMuse, you designate the river reaches that are part of an observation in either the
Object Properties dialog box or the "Model|Manage Flow Observations..." dialog box. In the
latter, you define the observed values and times. You can also select all the objects that you want
to make part of the observation. You can find more information by clicking the "Help" button in
the "Manage Flow Observations" dialog box.
* What is DRY(1,7) mean? It means the cell at row 1 column 7 converted to an inactive cell
because the head in cell was below the bottom of the cell so the cell went dry.
* Since you are using python, flopy (https://github.com/modflowpy/flopy) may be useful for
you. It can extract data from compact budget files.
* You will need to understand why the cells that have unrealistic values are assigned the values
they have. One way to do that is with the "Grid or Mesh Value" dialog box. First you need to
color the grid with the layer elevation data set. (Select "Data|Data Visualization..." and on the
Color Grid pane, select the layer elevation data set and click "Apply.") Once the grid has been
colored, select "Data|Show Grid or Mesh Values." Then move the cursor over one of the cells
that has an unrealistic value. An explanation of how that value was assigned for that cell will
appear in the "Grid or Mesh Value dialog box. It may be that the value was assigned using the
default formula for the data set. If that is the case, you can edit the default value in the
"Data|Edit Data Sets..." dialog box. Another option might be to use interpolation among objects
to assign values to cells. There are several videos on
http://water.usgs.gov/nrp/gwsoftware/ModelMuse/ModelMuseVideos.html that deal with
assigning data set values that you might find helpful. They are grouped under "Working with
Data Sets."
* Constant head cells only interact with other groundwater cells. They don't pull water across the
top face of the model.
There is no difference between a .cbc and a .bud file. The extension used is determined by the
file names in the .nam file. Different GUIs for MODFLOW have used different extensions for
what is exactly the same sort of file. If you edit the Name file manually, you can use whatever
extension you want but it doesn't change the structure of the file.
* There isn't any way to get this sort of diagram from within ModelMuse. You would need to
generate it yourself in some other program. You can use ISTCB2 in the SFR package to obtain a
printout of the magnitude of the flows in each stream reach. I'm not sure exactly what
information is contained in that file. If it contains both the cell locations and the segment and

reach numbers, you might be able to process that to obtain a diagram like what you want. You
might also need to know how the segments are connected to one another.
* A simulation must have at least one stress period and stress-period lengths can vary. Stress
periods can be either steady state or transient (Harbaugh, 2005, p. 3-6). A steady-state stress
period neglects changes in storage, whereas a transient stress period considers the effects of
changes in storage in the calculation of ground-water heads. Multiple steady-state stress periods
can be interspersed with transient stress periods when GSFLOW is run in MODFLOW only
mode; however, when run in integrated mode, the stress periods must all be transient after the
initial stress period.
* If there is too much flow out of the river when you specify the river as a constant head, maybe
your hydraulic conductivities are too high.
* If you write the lines in the Matlab code starting with a special symbol, the line will run
directly on the linux/ unix command line. This way you can directly run modflow inside Matlab.
* Please find the link for Modflow linked with Matlab below:
https://code.google.com/p/mflab/
* Theoretically the principal directions of anisotropy must get aligned with the grid's orientation
but practically it is really hard to enforce so you should not be worry about unless you do have
prior knowledge or evidence about it.
* If the only reaction you want to simulate is radioactive decay, you can do that with
MODFLOW + MT3DMS.
* Please read the definition of the term boundary when a PDE is used for a finite domain and
how it influences the computed state variable in the domain. Boundary will be imposed on the
domain irrespective of the fact that the cells lie above sea level or below sea level. The cells
above sea level will dry out because the computed head is below the bottom of the cell which
lies above sea level. Do not compute token is used as INACTIVE region in Modflow. Also
assigning a constant head boundary means that the head will remain the same and is kind of non
computed during the simulation. For suggestion, try to look what you want to compute and start
an iterative procedure of developing the model starting with the simplest model.
* All models have simplifying assumptions. These are just the ones MODFLOW uses. You can
always use flat layers with MODFLOW if you want to although you would have to use more
layers and be careful about maintaining the aquifer connectivity.
* Any model is an approximation of the real world. The accuracy of the model depends on the
field experience of the modeler. Computer does help only in accelerating the results and
drudgery of actual calculations. Groundwater modelling is a bit more difficult as we can not see
what is happening under the earth and difficult to get realistic parameters of T and S. The same
water levels can be obtained with different T and S values. A good hydro geologist / Water
Engineer with lots of field experience is the prerequisite of good modelling.

(Last updated on 6 May, 2015)