Discussion archives on Groundwater Modelling I have been compiling selected extracts on groundwater modelling discussion from various online groups 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 "well-behaved" 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 three-dimensional, 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 non-conservative 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 half-life 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 isn’t 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 isn’t good enough. If you don’t 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 R-square). 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 it’s 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 (R-square of 0.35) would be significantly greater than zero based on about 25 samples, but a correlation of 0.01 wouldn’t 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, auto-correlation) that I won’t 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 pre-conditioning) 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 sub-menu, 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 MODFLOW-SURFACT. * 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: XL-Plot, 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: Self <nick.walton@port.ac.uk> To: waterforum@yahoogroups.com Subject: TDS and Conductivity - a tricky relationship Date sent: 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 non-constant 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 re-assigning 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 dry-cell 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 Manning-Strickler 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/Effective-Groundwater-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_compiling.htm may help. For instructions for preparing input for MODFLOW-2000, refer to USGS Open-File Reports 00-92 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 MODFLOW-2005 (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 you’ll 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 won’t 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 groundwater-surface water model. * Yes, I think you misunderstood my point. I am not suggesting that the observed stream-aquifer 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 end-member 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/ofr00-92.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 MODFLOW-2000. 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 non-EL 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 heavy-duty 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. ZoneBudget 2. MODPATH 3. GW_Chart 4. 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 that’s the case then I guess people won’t 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. Problem-solving 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 ground-water 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-surfact-flow 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 well-managed 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 MODFLOW-Surfact (www.hgl.com) can simulate saturated & unsaturated groundwater flow and multi-component 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 real-world 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. Model|MODFLOW2005|Options i. NWT General 1. OPTIONS = SPECIFIED by user 2. HEADTOL = 5e-3 3. FLUXTOL = 5e-1 4. MAXITEROUT = 2000 5. THICKFACT = 1e-7 6. LINMETH = 2 7. IPRNWT = 1

8. IBOTAV = 0 9. DBDTHETA = 0.8 10. DBDKAPPA = 0 11. DBDGAMMA = 0.001 12. MOMFACT = 0.001 13. BACKFLAG = 0 14. MAXBACKITER = 10 15. BACKTOL = 1.05 16. BACKREDUCE = 0.9 ii. NWT Methods 1. IACL = 2 2. NORDER = 1 3. LEVEL = 1 4. NORTH = 4 5. IREDSYS = 1 (MODFLOW-NWT 1.0.3 onwards) 6. RRCTOLS = 0.0 7. IDROPTOL = 1 8. EPSRN = 1e-3 9. HCLOSEXMD = 1e-4 10. 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 non-efficient, 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 Drain-Return (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_questions.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 model’s groundwater budget. This assumption is generally pretty reasonable if you don’t 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 won’t 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. MODFLOW-NWT 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_compiling.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 stand-alone 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 cell-by-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 & pipe-line. 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 MODFLOW-NWT 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)