I have been compiling selected extracts on groundwater modelling discussion from various mailing lists for past few years. The updated compiled version (as in May 2021) is placed 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.
C. P. Kumar
Former Scientist ‘G’ National Institute of Hydrology Roorkee - 247667 (Uttarakhand) INDIA
Publications: https://www.angelfire.com/nh/cpkumar/publication/
Discussion Archives on Groundwater Modelling
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.
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.
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
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
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 data set, then browse to find the .bas file. Some data sets (especially those that were created without the use of a preprocessor) can be troublesome.
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).
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.
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.
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.
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.
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.
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.
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.
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.
Cell refinement tool
Grid smoothing tool
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.
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’.
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 non-realistic 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:
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.
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.
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 “wiggles” 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:
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):
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:
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:
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 “wiggles” 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
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.
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.
Looking at SEAW AT 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.
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 dug wells 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.
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 flow paths 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
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.
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.
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.
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.
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 Zone Budget 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.
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.
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.
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:
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.
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).
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.
The groundwater recharge is entered, and a steady state flow simulation has been carried out. The trench is not yet modeled at this point.
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.
The trench is modeled by using constant head condition with h = -1 m.
Finally a steady state simulation is carried out again.
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.
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.
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 post processor 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:
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 output 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=rechargearea (=0.1 m/yrarea 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=SareaM (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/(SareaM) * recharge area = recharge/(SM)
= (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.
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.);
Ground Water Information Systems (GWIS) in which we turn data into information (data processing and management, analyzing, interpreting, quantifying, presenting and reporting);
Modeling, if we have enough and trusting data.
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.
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.
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.
“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.
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.
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.
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.
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.
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?
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.
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!
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.terrain map.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.
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.
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.
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 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.
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:
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.
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.
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 pinch outs.
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
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:
Decrease your outflow - by decreasing parameters such as hydraulic conductivity, or boundary conditions conductance, such as drains (if this is the case).
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 down river 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
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 underlain hydrogeology giving funny results, where in the water table contours crossing hills etc.
Normally any model has a default NO FLOW boundary conditions if you create a model without having B.Cs.
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.
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.
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.
If this is a transient model, the heads will never reach a steady state because there is no source of water for the model.
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.
Having a model without boundaries is a bit like sustainable mining or sustainable land filling (an oxymoron).
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 well field is realistic).
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 dry out 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.
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.
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…).
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).
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.
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.
If you know a cell should never become wet, make it an inactive cell rather than a variable head cell.
You can adjust the value of the wetting threshold in WETDRY. (Higher is more stable but may be less accurate.)
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.
You can use IHDWET to determine which equation is used to specify the head in newly wetted cells.
You can vary the wetting factor WETFCT.
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.
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.
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.)
When using the PCG2 solver, you can set DAMP to a value between 0 and 1.
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.
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 Model Muse 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. Model Muse can figure out a separate conductance for each cell based on how much of the line intersects each cell.
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 Model Muse. 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 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.
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.”
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.
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.
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.
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.
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.
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.
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
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.
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
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.
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:
You might be able to get the two-layer model to approximate the one-layer model, but they will never be exactly the same.
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.
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 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.
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:
Try setting the constant head BC in last column to 1 m & constant concentration at 35 kg/m3
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.)
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.
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.
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.
What sort of spatial scale are you looking at? Do you need a cell size of 100 km? Or 5 m?
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?
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.
What hydrogeological data are available? You will need that to setup your hydraulic conductivity and storativity parameters.
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.
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.
In general, do not use layer elevations (i.e. depths of layers you mentioned) for calibration.
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.
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.
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.
http://water.usgs.gov/nrp/gwsoftware/mf2k_vsf/vsf.html http://pubs.usgs.gov/tm/2006/tm6a19/
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 postprocessor 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 Model Muse, 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:
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;
Groundwater Vistas has an integrated automatic sensitivity analysis which may help to achieve better calibration;
Groundwater Vistas supports uncertainty analysis tools; and
MODFLOW-SURFACT (a MODFLOW 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.
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.
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.
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.
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.
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 conservation 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
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.
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 evapotranspiration 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:
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 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:
Model|MODFLOW2005|Options
i. NWT General OPTIONS = SPECIFIED by user HEADTOL = 5e-3 FLUXTOL = 5e-1 MAXITEROUT = 2000 THICKFACT = 1e-7 LINMETH = 2 IPRNWT = 1 IBOTAV = 0 DBDTHETA = 0.8DBDKAPPA = 0DBDGAMMA = 0.001MOMFACT = 0.001BACKFLAG = 0MAXBACKITER = 10BACKTOL = 1.05BACKREDUCE = 0.9
ii. NWT Methods IACL = 2 NORDER = 1 LEVEL = 1 NORTH = 4 IREDSYS = 1 (MODFLOW-NWT 1.0.3 onwards) RRCTOLS = 0.0 IDROPTOL = 1 EPSRN = 1e-3 HCLOSEXMD = 1e-4MXITERXMD = 250The 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 Model Monitor, 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 Model Monitor 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?
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
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 inactive 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 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.
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.
hw = hij - Qw/(2piTij) * 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 e.g. 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 MODFLOW-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.
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.
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.
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.
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.
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:.3_0.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:_112005.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:
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
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 stream bed 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
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.
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 MODFLOW (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 non linearities 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.
Adding a couple of layers (i.e. dividing the first and third into two) will probably be sufficient to decrease the influence of the simplifications on which both Modflow and Modpath are based. It really depends on the geometrical accuracy you are seeking.
The software you used to generate the cross section draws the bottoms of the cells as flat. That is one valid representation of the cells. Another valid representation would be to connect the centers of the bottoms and tops of cells. If drawn that way, the pathlines would appear more continuous.
MODFLOW packages only support limited parameters options, and they can be specified using pval file. However, for PEST calibration, you can add as many parameters as possible if you want. But you should be careful with the parameter within PEST control file, since PEST only works when MODFLOW could converge and produce results. The more parameters you added, the longer it takes to run. So I recommend run Sensitivity first, and then choose those interested for calibration.
MODFLOW can calculate drawdown for you. When you import the drawdown, ModelMuse will create a separate data set for each layer in addition to a 3D data set. You can plot one of those. If you don’t want to use the drawdown MODFLOW calculates, you will have to use 2D data sets for the drawdown and for the data sets used to calculate the drawdown. If those latter two data sets are heads calculated by MODFLOW, there will be 2D data sets for each layer.
MODFLOW has a limited ability to simulate surface-water/groundwater interactions via the Stream, Streamflow Routing, and Surface Water Routing packages. GSFLOW has a more sophisticated surface-water simulater combined with MODFLOW for the groundwater part but GSFLOW is probably more complicated than you want.
To calculate groundwater surface water interaction, you will typically need to have both a groundwater model and surface water model - of some sort. The complexity of each model depends on the questions that you want to answer. For example,
if you are primarily interested in the changes in baseflow to a stream cause by a dewatering project, then the river component can be quite simple.
if your project involves regional changes in groundwater-surface water hydrology due to climate change, then changes in ET, rainfall-runoff, stream flow and groundwater flow will all be critical.
Also relevant is the amount of data available for calibration. If you have very limited groundwater data, and no stream flow data, and poor rainfall records, then your ability to calibrate a stream flow model will be limited.
One of the most comprehensive models available for catchment scale groundwater-surface water interaction is MIKE SHE. One advantage of MIKE SHE’s framework approach is that it is not tied to a particular numerical method. So, you can decide to use simpler numerical methods for different components depending on the goals of the project.
Usually diffusive/dispersive dominated models take comparatively more time due to decreased time step, as compared to advection dominated mt3dms calculations. You can also check the time step changes when you change the model between advection and diffusion/dispersion dominated model. One can definitely specify the Peclet number during model runs, but the time steps used will depend upon the velocities computed. Though it is not the case with you but sometimes retardation factor or the porosity plays a large part in deciding these time steps.
The only place where the input for MODFLOW-2005 and GSFLOW will be different that I am aware of is in the SFR package. In ModelMuse, there is an option in the MODFLOW Packages and Programs dialog box to save the SFR input in the GSFLOW format.
MT3DMS was designed to work with the regular MODFLOW that treats dry model cells as inactive. As you point out, the assumption of deactivating dry cells is no longer valid with MODFLOW-NWT that keeps dry cells active and allows flow to occur through them. Using MT3DMS with NWT, which violates the originally intended design of MT3D, will accumulate mass in the model cell upgradient of the dry cell resulting in erroneously elevated concentrations.
The SWI2 manual says the zeta values will be saved at the same time as the head but there is no option to print the zeta values. If you have written you own program to convert the binary data to a text file, you can control the format in which the data are printed. Otherwise, you may not be able to control the precise format of the text data.
If the streams are in inactive cells and there are no active cells lower down, the streams won’t interact with the groundwater system.
Check the listing file for more complete information about which parameter caused the problem. Then check the data sets for that parameter that are used to specify the zones.
Usually i do not create a fracture zone unless and until there is a huge diabas in the geologic medium. You can assign a hydraulic conductivity of 1e-7 m/s in the fractured bedrock and use drainage package for tunnel. In case you still want to assign a separate hydraulic conductivity for fracture you can create a high hydraulic conductivity of 1e-5 m/s for the fractured medium. I guess you have to calculate drawdown due to the tunnel construction. Just use this method and show the drawdown at the depth where tunnel is constructed.
If any HK parameters are defined, you must use HK parameters for all active cells.
Rewetting of dry cells is explained in page 5-11 of the MODFLOW-2005 documentation. It is the same approach used in older versions of MODFLOW; cells rewet when neighbouring (or underlying) cells are wet. MODFLOW-NWT is a version of MODFLOW-2005 in which cells do not go dry (they become temporarily ‘inactive’ instead). So there is no rewetting.
The old MODFLOW rewetting system (also used in MODFLOW-2005) is not very stable, depending on the parameters you choose you can either get dry cells that refuse to rewet (common problem) or convergence difficulties due to repeated drying/rewetting. MODFLOW-NWT is much more stable
MODFLOW could output both ascii or binary format files, which is controlled using the OC package. I found another way out by reducing the line characters count using the FORMAT keyword in OC package. It is simply a Fortran format controls. Now the the instruction file could read the output directly. Since format strictly follows the spaces, it is actually better for PEST to read since I can directly direct PEST to read exact column.
Modflow Convergence Error
It depends on what solver you are using, which settings for that solver you are using and the setup of the model (time stepping, grid spacing, material properties and boundary conditions). Your description of the problem, the screen shots and your mention of “inactive cells” lead me to think there is a problem with the model setup that is causing cells to dry out, which can lead to failure. The NWT version of MODFLOW does a much better job of handling dry cells than earlier versions of MODFLOW like 2005. There may be other problems that are also contributing to the failure.
The steps for creating instruction file(s) are described on p. 28 of the ModelMate documentation. In ModelMate, use menu item Model|Create Instruction Files For Observations Defined In ModelMuse. To generate the model output file, you’ll need to run Ucode (which can be done from ModelMate) so it will run the model.
There are two different programs Modflow and mt3dms. ModelMuse is currently the best GUI option (personal opinion) to produce files for both of these programs. ModelMuse produces the Modflow and mt3dms name file(.nam) which has the names of other Modflow (or mt3dms) input and output files.
When you run Modflow program first (e.g. Pathto/mf2005.exe example.nam), it produces a file required for the mt3dms. Then you can run mt3dms (Pathto/mt3dms5b mt3dmsnamefile.nam). Now you can use these lines inside a code (for example optimization code) to directly run it on Linux command line or on the shell.
If your parameters are not changing, it might mean several things:
your calibration is pretty much done, you have reached the optimal set of parameters.
your input parameters are insensitive with respect to your observations - this might mean there is something problematic with your conceptual model.
Error in MODFLOW calibration using PEST - One reason could be that your problem is ill-posed (too many parameters that don’t affect the objective function). Regularisation could help with this (e.g. if you are using pilot points). Just because you have a model and some calibration data doesn’t mean you can calibrate your model to the calibration data. The adjusted parameters actually have to affect the model outputs you are calibrating.
SVD Assist is very useful, it identifies the key parameter combinations that are improving your fit and ignores the rest. It makes the calibration much more efficient (but does not do so well for non-linear systems). PEST also has another SVD function which improves efficiency, you should probably use that, whether or not you use SVD Assist. Check the PEST manual.
The other reason could be your convergence tolerances are too big or too small. If too big the search will terminate before it has found the optimum. If too small, it will never terminate (but you can still halt PEST manually using pstop).
Some utilities including TSPROC and PAR2PAR are basically helping you handling data (input or output) . These types of work can also be done using other simpler scripts (such as transfer from daily to monthly, and preparing inputs for TSPROC takes time again!).
By far, I could see many improvements in Modflow calibration using PEST. Many factors are affecting the result. I believe the model itself is the most important part. And choice of observations parameters or data are also important.
You can use the two rivers as no flow boundary because the ground water flow is parallel to the the river so you can use no flow the ground water flow never cross the river flow direction.
You should try the parameter optimization with PEST. Choose the run section, then parameter optimization. In the objective function tab activate head, save and exit. For the first run you can try the default settings and change them according to your result. Activate PEST and run model.
Try the ADDREG1 utility that comes with PEST. It will read your pest control file and then create a new pest control file that has a prior information observation for each parameter based on the parameter’s initial value.
I had same problem when had defined Brooks-Corey exponent (epsilon) base on soil type. In my case when amount of epsilon decrease under 2.5, number off waves increase so much (like your case). My suggestion is that, if you defined epsilon as a calibration parameter increased its lower boundary, I hope the problem will be solved.
PMWIN has the option to use transmissivity instead of hydraulic conductivity. If you choose to use transmissivity in your model, then the hydraulic conductivity will not enter the calculation. in this case, PMWIN sees no parameters to optimize even though you have checked the hydraulic conductivities. You can check your PEST control file to see if there are parameters listed in the file to estimate.
John Doherty has written a wealth of unbelievably useful processor utilities. See downloads at the attached link (documentation for the utilities can be found on the same page): http://www.pesthomepage.org/Downloads.php#hdr7
PEST in fact does not check the simulation time ranges. It requires the observations read using the instruction file and defined ones within the control file. As long as these records are matched, PEST should not give error. I suggest you check the input file for PEST, specifically the control file and instruction file.
UZF is not designed to simulate unsaturated flow through multiple layers.
Porosity is not required to solve the flow problem (see governing equations here: https://en.wikipedia.org/wiki/MODFLOW). Porosity is only required for solving the transport problem or particle tracking. The flow problem requires the definition of the hydraulic conductivity and the storage (for the transient simulations).
If a river cell goes dry, it becomes inactive and there is no longer any flow to or from the river.
Each well will be treated as if it were at the center of it’s respective cell. More than one well per cell is OK.
Each well will result in a cone of depression around it. These cones of depression might or might not overlap depending on the pumping rates, aquifer properties, proximity of the wells, duration of pumping, net recharge rate, and probably other factors that I’m not thinking of right now. If the cones of depression overlap, the total drawdown at a location would be the sum of the drawdowns that would have been calculated for each individual well.
If there are multiple wells per cell, the total pumpage from the cell is the sum of the pumpages from the individual wells.
The problem is that when you zoom in, ModelMuse tries to create a larger version of the original image and then displays the part of the image that is in the field of view. If the resized image gets to large, it causes a problem and ModelMuse responds by hiding the image.
Transient model calibration in MODFLOW-NWT under ModelMuse GUI - through Data/Data visualisation and the Head Observation Results section you can import your HOB file and make it plot by ModelMuse. I particularly appreciate the fact that ModelMuse represents error with blue and red circles, colored and sized differently depending on sign and importance of discrepancy. In transient mode, I think you should use groundwater chart which is a little software able to extract heads change from model simulation at particular cell coordinates.
To calibrate your model you should obviously adapt your K until you have an equally distribution of red and blue circles with acceptable ranges of error. However you can try ModelMate in order to perform automatic calibration of your problem. My experience is that this is seldom necessary and perform your own diagnostic and understanding on way to calibrate your model is more valuable as well as efficient. ModelMate procedure is also more complicate than a straight-forward adaptation of K values.
If the white cells are all in the same layer, they will be treated as a continuous layer in MODFLOW. It is the layer, row, and column numbers, not geometry, that determine between which cells flow will occur.
MODFLOW is a separate program from ModelMuse and must be downloaded and installed separately. You can download MODFLOW from http://water.usgs.gov/ogw/modflow/MODFLOW.html. To install it, you just unzip the zip file. The suggested installation directory is a subdirectory of C:named MF2005.1_11. If you decide to install it somewhere else, you just need to tell ModelMuse where you installed it. To do that select “Model|MODFLOW Program Locations” and enter the location where MODFLOW is installed.
MODFLOW never lets confined layers go dry. However, if the heads in a confined layer are below the top of the layer, that indicates a problem with the model.
Even If radically different hydraulic conductivities are there next to white cells still the white layer is continuous and the groundwater equation will treat it as continuous.
The infiltration rate is the amount of water that enters the unsaturated zone. The recharge rate is the amount that enters the saturated zone. The recharge rate is less than the infiltration rate because not all the water that enters the unsaturated zone reaches the saturated zone. Some may evaporate or be transpired before reaching the saturated zone. In addition, if the precipitation rate is high enough, not all of the precipitation will infiltrate.
Use observations of head and flow to calibrate the model just as you would any other MODFLOW model.
The land surface is used in the default expression for UZF_Layer. If you set UZF_Layer directly, the land surface data set is not used.
How would one model an ephemeral reach using MODFLOW? - You could use the Streamflow-Routing (SFR) package. Use the STR or SFR package.
Convert a stream package to a river package? - If the head in the stream is specified by the modeler instead of being calculated, all the information required by the river package is also in the stream package input. Therefore, it would be possible to do it. I have never heard of anyone wanting to do this before. One possible issue is that the stream limits the flow into the aquifer to be no more than the amount of flow in the stream. The river package doesn’t limit the flow in that way.
Groundwater ex-filtration component in Modflow-NWT model - I would check that the simulated water table has not risen above the land surface. If it has, that would explain the ex-filtration (and also suggest you need to change your model to avoid that situation). It is also possible that there is more precipitation than can be accepted into the unsaturated zone. You would get that if the precipitation rate is greater than the vertical hydraulic conductivity. I’m not sure whether or not that would be reported as ex-filtration.
The LMT package is already included In the version of MODFLOW 2005 that is distributed by the USGS. Therefore you do not need to recompile MODFLOW to use it.
Ignore the stream flow out component. As Richard says, this is the total accumulated flow at each cell down the stream network (i.e. you might calibrate to gauged flows using this at a given location). The stream leakage in/out is each cell’s interaction with groundwater, which is what you would include in your mass balance.
A Groundwater Vistas project is stored in a gwv file, which is used to create all the files for the MODFLOW run. You can have more than one gwv file in a directory, but generally it is best to have Vistas put all the MODFLOW input and output files in a unique directory for that project. You set up the directories in the Model|Paths to models dialogue box. Setting up a MODFLOW model is pretty fiddly, you have to specify the read/write units for all the input and output files. This is done in the Model|Modflow|Packages dialog and other similar dialog for later versions of Modflow. I am guessing there is a problem with the settings in one of these. You cannot use the same Unit number for two files, for instance. You can set Vistas to automatically assign the unit numbers. Unit 11 seems to be set to the MODFLOW2000 LPF package by default.
Try looking at the input file for the STR package. You need to see if ISTCB2 is set to a value greater than zero. If it is set to a value greater than zero, is it set to the same value as ISTCB1. Bath these variables should appear either in the first non-comment line of the STR package or just after a line that starts with the word “PARAMETER”. ISTCB2 is the 8th number on that line and ISTCB1 is just before it: the 7th number on that line. If ISTCB2 is both greater than zero and the same value as ISTCB1, then the streamflow variables are being stored in the same file as the flows between the stream and the aquifer. Only the flows between the stream and the aquifer should be part of the groundwater flow budget. That would account for the results you are getting. You could try changing ISBCB2 to zero and rerunning your model. That should give you the results you expect. Be careful that the new value of ISBCB2 is in exactly the same place as the old value. If the right end of the number is shifted left or right, it could cause MODFLOW to crash. For example, if ISTCB2 is “72”, You should change it to “0”. The reason it could crash is that MODFLOW may be expecting all the numbers to be in a fixed format where each number must occupy a specific number of characters.
Model Viewer plots vectors for MODFLOW-GWT (groundwater transport) models but not for the usual MODFLOW models. With GWT, flow velocity vectors can be calculated because porosity is part of the input. Porosity isn’t part of the input for regular groundwater models so although you could calculate the “Darcy velocity”, you can’t calculate the true velocity from just the model input and output.
ModelMuse only defines parameters for which there is a corresponding parameter in the MODFLOW input file. The UZF input instructions do not include any parameters.
Modflow does not consider some variables as parameters for some reasons (can we actually assume all unknowns are parameters? mathematically we could). Since PEST is model-independent, any inputs can be parameters. But the choice of parameters could result in different scale of difficulties. What you need is just preparing the files for PEST, which mostly like have to be done outside ModelMuse. But there are quite a few utilities you can make use of. So to do SA, you could possibly include most of the parameters in your definition. But when do calibration, you usually only focus on a few of them.
To see the arrival times for all cells for a particular pathline, you would have to look at the pathline file itself. It is just a text file. See the MODPATH documentation to understand what the numbers mean.
Pits in the ground surface are unlike to have much influence on the stability of a MODFLOW model unless they affect the elevation of boundary conditions used in the model. Even then, however, pits would likely only have a minor effect.
You could check to make sure the recharge is applied to the top active cell instead of to the top layer. That is controlled by the NRCHOP option in the Recharge package.
Lf90.err is distributed to purchasers of Lahey Fortran 90. They can distribute it with programs compiled with Lahey Fortran 90. If you are right about what that error number means, that suggests that Pest was trying to move to a location in a file before the beginning or after the end of a file. It might try to do that if it was trying to extract an observation from a file produced by a model run in which the model stopped prematurely.
There are lots of reasons why the simulated and observed heads could be different. The first things I would look at are recharge rate, hydraulic conductivity, and boundary conditions.
Use a single Z-coordinate for the object that defines the CHD boundary and set its formula to Model_Top. The formula for the specified head itself can be higher than Model_Top. Be sure to check that the heads in cells that are not CHD cells do not rise above the top of the model because such cells would be treated as confined.
In MT3DMS, the concentration associated with a boundary condition is the concentration of any flow into the aquifer through the boundary condition. Water leaving the aquifer gets the concentration of the aquifer. ET extracts water so it doesn’t need an associated concentration. I don’t recall whether or not MT3SMS allows for evaporative concentration or not. You should check the MT3DMS documentation to find out.
If you use MODFLOW-OWHM, you can use the NWT solver with local grid refinement.
DRAIN boundary would seem to be the most appropriate for seepage outflows into a ditch. I have used DRAIN boundary cells to model groundwater discharge into an open pit mine. Time dependent data used were: groundwater head data upgradient of the drain; water level in the drain (mine pit); discharge from the pit (water was being pumped out of the pit). If it is a multi-layered aquifer, then you might assign different property values (conductance and head) for the different seepage surfaces if necessary.
MODFLOW does work on Windows 10.
If you are using UZF, I doubt you would be able to do this at all without modifying the MODFLOW source code. The problem is that the UZF package stores the water content in the unsaturated zone in an array of values for each vertical column of cells. However, the input for UZF only allows you to specify a single value of water content for each vertical column of cells. Thus, you can’t fully define the input for UZF based on the output from UZF. In addition, UZF doesn’t even write the values that you would need to specify the initial conditions for UZF to continue a model run even if it were possible to specify them in the input.
Whenever you have a wall to stop the groundwater infiltration to the excavation, these kind of boundaries are used. Hence using these kind of boundaries require stating the hydraulic conductivity of the wall and the breadth of the wall. There are of course workarounds to model the same behavior.
You have to create surfaces from shapefiles or excel tables and then make horizons from it. Then the zones are itself created in visual Modflow. Please note that it starts from conceptual modeling approach in Flex and not directly from numerical modeling approach!
There are no free GUIs that support unstructured grids. From the commercial ones, I know of Visual Modflow Flex (from Waterloo Hydrogeologic) and Groundwater Vistas (from ESI). If you do Python, you could use FloPy3. It works with Modflow-USG, however there are still problems with discretization (DISU) module for unstructured grid - it officially works only with single layer meshes. If you however use rectangular grid with Modflow-USG, FloPy3 works fine - but what is the point? If you want to use Modflow-USG with unstructured (triangular, voronoi) meshes, the grid/mesh generation becomes the biggest problem, as the quality of the mesh really impacts model performance in terms of convergence. I use commercially available AlgoMesh (from HydroAlgorithmics - http://www.hydroalgorithmics.com/software/algomesh/ ), it generates quite nice meshes and creates the discretization files for you. They offer 30 days free trial.
Import the model results into ModelMuse and color the grid with the imported heads. The inactive cells including those that became dry will not be colored. Then try to figure out why those cells became dry and fix the problem with the model design.
It doesn’t really make sense to assign a concentration to evapotranspiration. Solutes are not removed along with the water in the process of evapotranspiration. Instead, they accumulate in the cells where evapotranspiration has taken place.
MODELMUSE - in the vdf file a value of 1 or greater for MT3DRHOFLG indicates that fluid density calculation will be calculated using the “Salt” species, you need to define this solute in the mt3dms files.
There are a number of optional features involved with the MNW2 package, but you don’t NEED to enter in null values as long as your flags are set that you don’t want to use them. I asked my coworker, and she said as long as your solver options at the top of the MNW2 file are set to NONE, then you just need the bare bones options to be entered and none of the HLIM stuff. Just be mindful of your 1/0 flags at the beginning and you should only need to enter what you want. I would suggest investigating the test examples to get an idea of how the flagged options work and what the bare bones items that you need are.
Even for steady-state stress periods, one can specify multiple time-steps in the DIS file. Flow time-steps in the BTN file need to be consistent with the DIS file. One issue with running successive steady-state flow stress periods and simulating transient transport is, you may see mass balance errors in the transport model. Because the successive stress period is steady-state, MODFLOW does not report change in storage of water in the FTL file to MT3D even though the volume of water may change in the successive stress period due to a new head solution, resulting in mass balance errors in the transport simulation.
A number of people have contacted about me about compiling their own versions of ModelMuse. ModelMuse is compiled with the Delphi compiler from Embarcadero. Right now through September 9, they are offering the Starter Edition of Delphi for free. I have modified the source code of ModelMuse so that it can be compiled with the Starter Edition.
You can get the Delphi Starter Edition at https://www.embarcadero.com/products/delphi/starter/promotional-download .
You can get the modified source code for ModelMuse from https://github.com/RichardWinston/ModelMuseSource .
You cannot have drainage bottom as 10 m when cell bottom is 11m. Check your initial head in the model. It has to be above the topmost layer bottom.
The Stream Flow Out term is not a part of the groundwater flow budget. Since ZoneBudget includes this term in the water balance calculation of its output files, the percentage error of the water balance can be very wrong. The ZoneBudget program should exclude the Stream Flow Out term.
Visual Modflow might use different kind of formats. The nam file might look the same as does the other lpf files etc. but the fact is that there are differences. You cannot use ordinary Modflow executable to run visual Modflow models. I have encountered a lot of problems in running visual Modflow models using ordinary Modflow executables. The differences are small and difficult to be detected. Like a different way of writing hydraulic conductivities. Instead the solution is to use ModelMuse or Pmwin because they produce files for Modflow executables which can be directly used in Linux systems.
There is a description of how to calculate conductance on this page. http://water.usgs.gov/nrp/gwsoftware/ModelMuse/Help/index.html?drn_object_pane.htm
The USGS released MT3D-USGS recently along with new versions of MODFLOW-NWT and GSFLOW. MT3D-USGS is backwards compatible with MT3DMS but also has some new simulation capabilities including support the the SFR, LAK, and UZF packages. MODFLOW-NWT can create a Flow-Transport link file in the format required for MT3D-USGS. It is also supposed to work with GSFLOW.
First of all, I assume you are also trying to model flow in the saturated zone. If not, UZF isn’t the right software to use. If you are only modeling the unsaturated zone, you could try VS2DT.
You don’t say whether you are a beginner with UZF or a beginner with MODFLOW. If you are a beginner with MODFLOW, you should probably avoid using UZF. UZF most likely will make your model take up a lot more time to run, use much more computer memory, and probably will add little if anything to the accuracy of your model. If you are just starting with MODFLOW, my recommendation would be to use only the packages described in the original MODFLOW-88 documentation plus the LPF and PCG2 packages. Starting off with a model that is entirely confined would be a good idea too.
If you are already familiar with MODFLOW but are just starting with UZF, then you should start by reading the UZF documentation (http://pubs.usgs.gov/tm/2006/tm6a19/). Maybe you have already done that. The UZF package has a lot of data requirements beyond that of the saturated flow packages. For instance, you need to know the Brooks-Corey Epsilon values, saturated water contents, and possibly the residual water contents. If you don’t have a way of getting that information, maybe you shouldn’t try using UZF.
I recommend using a graphical user interface (GUI) to generate the input for the UZF package. If you are already using a GUI and it supports UZF, you should probably continue using it. If you aren’t using a GUI, there a number of good commercial GUIs available. If you don’t want to spend money on a GUI, you can use ModelMuse; its free and has a lot of users - two facts that may be related. I wrote it so I think its good but plenty of other people tell me they like it too.
I don’t want you to think that I think badly of UZF. That is not the case. UZF has proven useful in some applications. However, it isn’t a package that I would recommend for a person just beginning with MODFLOW.
The Recharge and River packages act independently of one another so you can use both in the same cell.
The main difference in using LPF package and BCF package is in the case of LPF the vertical flows are calculated with Kz instead the VCONT of a leakance factor from BCF, and other changes regarding the unconfined- confined criteria.
You can specify different conductivities for the the conduits. You can specify pumping wells by activating the Well package in the "Model|MODFLOW Packages and Programs dialog box and then using objects to define individual wells. You would follow a similar process for observation wells except that you would use the Head Observation Package. You can use UCODE and ModelMate to help calibrate the model.
The problem is due to a bug in MODFLOW-OWHM. MODFLOW-OWHM writes several extra unit numbers to the header for the flow transport link file. Neither MT3DMS nor MT3D-USGS can read the file correctly because of this.
Kindly re interpolate all the elevations by inverse distance method and click on assign to appropriate layer. This may work. If it does not work, create a separate folder and recreate the programme altogether again and create the stream segment only for major canals. As you know, you have to give different widths, k values etc. You may not have realistic data. As such, your stream segment does not give correct answer regarding the canal recharge. At maximum, It will only give the recharge during the canal water flowing. It will not give the total canal water recharge.
You have to collect the total water released in the canals month wise for the last 5 to 10 years and average it and convert it into recharge for m/day for different months and add that as a recharge component in addition to the recharge due to rainfall and work out the visual Modflow. You may get the answer.
Getting comfortable with a good text editor (TextPad, Notepad++) and QGIS (or perhaps Golden’s Surfer, commercial license) is perhaps the most stable toolkit for learning Modflow and it’s limitations. You’ll need to look through a lot of text files - GUI or no - to find spots in your grids / layers that the solver didn’t like, found dry cells / rewetting instability, issues like that. If you haven’t already, I’d dig into as many of the example models as you have time for simply using the command line, then reading the output files / water balance in the *.LST file, volumetric budget/volumes, etc. You can import then into ModelMuse, which has an excellent 3D viewer, or check into setting up QGIS to edit FD grids (Gridder plugin) and visualize outputs.
You may not use USG in ModelMuse however you can try the LGR version of Modflow, which may help you to refine your model locally. ModelMuse allows also to use SUTRA, which is a USGS finite element model. Last but not least Deltares proposes iMOD, a Modflow visual interface that allows easy model size reducing, e.g. you can build a regional coarse model and you can resize it for a local purpose - I haven’t try it yet. Flopy is probably the most exciting software, that does include USG. It needs to script python, which is not so hard. If you want to learn Python, Mark Bakker github page is an excellent starting point, e.g. : https://mbakker7.github.io/exploratory_computing_with_python/
First, there are several versions on Modflow, but one in particular is optimised for unconfined systems (which it sounds like you’re most interested in modeling). Roughly, it uses a modified Newton solver to stabilize rewetting issues in the finite difference mesh – you’ll need to address the details of that in your thesis. Here’s a link: https://water.usgs.gov/ogw/modflow-nwt/
Next, check out the example problems, installed by default into something like this: C:-NWT_1.0.9 There are steady state and transient simulations included, with extensive documentation (on my install, under: C:-NWT_1.0.96a37.pdf )
Use the batch files to check that your installation works – then open the *.LST files and get familiar with reading them.
Note that this documentation focuses on the difference between classic and Newtonian solvers, not your hydro questions about hydraulic connections between surface- and groundwater. But those questions might need a little refinement once you are comfortable with your MF installation.
Finally, don’t get too hung up on using a GUI (though ModelMuse is a good choice). Some other pre- and post-processors are here: https://water.usgs.gov/ogw/modflow/utilities.html
A negative value of IBOUND is used internally in MODFLOW to indicate that a cell is a specified head cell. There would only be a problem if the cell became a specified head cell after the beginning of the first stress period.
Over-clocking would allow any calculations on the CPU to be faster, but it would not change the % used. It may have to do with me running Modpath from Python using a subprocess. Python is restricted to one core, but I wouldn’t think that would affect the ability of DOS to use more resources.
To calibrate your transient simulation, you will need similar information to your steady-state model–specifically data through time such as transient water levels, hydraulic conductivity values, surface water flux estimates, etc. These will need to be incorporated into your model to estimate its effectiveness for simulating whatever scenario(s) you are trying to model.
To visualize your results, you have a few options. The first is to estimate your parameters using statistical information, such as the range in residuals over the range in measurements, the root mean squared error of your data, and the absolute mean residuals. I tend to also look at observed vs. simulated plots both through time and all together (such as residuals through time), as well as hydrographs for all transient water level locations. For guidance on these methods I recommend looking at Mary Hill and Claire Tiedeman’s book “Effective Groundwater Model Calibration: With Analysis of Data, Sensitivities, Predictions, and Uncertainty”, which covers everything you would need to know. They also address all of the questions you listed. If this isn’t available, the USGS also has posted guidelines for assisting with the calibration process. Finally, I think the ASCE also has some standards, though they are pretty vague.
You can calibrate Hydraulic conductivity values in the transient simulation as well. Just make sure that your properties ultimately match between your steady-state and transient models.
A number of performance measures have been proposed in the past to indicate when a model fits historical measurements “well enough” to be acceptable for use in predictions.
These include RMS, SRMS, MSR and SMSR. It has been suggested that performance measures, for example, SRMS < 5%, should be agreed prior to a modelling study and that these should be included in acceptance criteria. However, experience has shown that it is not always desirable to specify a target value of some performance measure. This process is very time consuming and frustrating, keep in mind and good luck!
Copy the MODFLOW executable into the same folder as the input files and run it from there. Another option would be to start a command line window, navigate to the input files directory, and then start MODFLOW by putting in its full path while you’re in the directory with the input files. MODFLOW expects the other input files to be in the same directory as it was started in, not in the directory where the name file is.
Usually when you specify the time in the HOB package it prints out the head values at wells at the measured time instances. I do not think that you have to change anything in the source code to do it. Please go through the modelmuse videos in order to know the details, assuming you are using Modemuse. You can use UCODE to estimate parameters.
You could represent the tunnel as an injection well with the MNW2 if it is small enough. That allows for a skin factor.
The following is from the ModelMuse help for the UZF package.
In the Unsaturated-Zone Flow (UZF) <uzf_unsaturated_zone_flow_pack.htm> package, water is routed from the land surface, through the unsaturated zone to the water table. Evapotranspiration (ET) can be simulated in the UZF package and whatever is not removed by ET becomes recharge to the saturated zone. Infiltration excess, can be routed to streams (SFR) or lakes (LAK). The pane for this package is on the MODFLOW Packages and Programs <modflow_packages_dialog_box.htm> dialog box under Flow Packages <flow_packages.htm>.
One of the data sets created for the UZF package is “UZF_Layer”. To reduce memory usage, you should set this to zero in cells that will have no recharge or discharge in the UZF package.
Recharge and discharge location option (NUZTOP)
The recharge and discharge location indicates where recharge to the unsaturated zone originates and where discharge from the unsaturated zone is removed. If the second option (Specified layer) is selected, the UZF_Layer data set indicates the MODFLOW layer where recharge and discharge occur. Zero indicates that recharge and discharge will not be simulated. If Specified layer is not selected, non zero values of UZF_Layer data set indicates the MODFLOW layer where recharge and discharge will be simulated but do not indicate the layer in which these will occur.
Modflow can be used to model groundwater flow and mt3dms can be used to model transport of contaminants in principle. Granite has very less fractures depending upon its age and depth and contamination modeling in these rocks depends a lot upon the in depth knowledge of fracture newtroks. Basalt can have more fractures and the conatmination modeling can be easier but still not easy to do. It all depnds upon the modeling objective that we can suggest you literature or modeling technique to model it.
MNW2 is not supported by MT3DMS although MNW1 is supported. The Flow-Transport Link file generated by MODFLOW will not contain flow rates for MNW2. I suggest converting your MNW2 wells to MNW1 wells or using MODFLOW-GWT instead of MODFLOW + MT3DMS. You might also look into MT3D-USGS and see if it supports MNW2.
some of the MODFLOW versions may not write MNW2 flow terms to the FTL file that is used by MT3D. It would be good to confirm this. One of the reasons for simulated concentrations to be lower than measured could be dilution as a result of multi-layer mixing within the well. Accurate representation of well screening information in the model may be one of the things you might want to check. To compare simulated concentrations, are you looking at the MNW mixed concentration, or are you looking at model cell concentration within a particular model layer in which the pumping well exists? Can you check how the model cell concentration compares to mixed concentration in the well versus the measured concentration.
Sounds like your flow system may be dominated by fractures, conduits or other type of preferential flow path. Trying to model such systems with single continuum type of model would give you such symptoms because the model is using a diffuse transport model, while in reality, your pumping wells are pulling the tracers into the fracture system where they can be transported to the well more quickly and with less dilution.
A flow systems with preferential flow paths like fractures, conduits, or thin gravel layers will have exactly these symptoms if you try to model it as a homogenous porous media.
The list file is always the best place to find out where the problem is.
ModelMuse does not currently display Darcy velocities. You can save the values of any data set in the “Data|Data Set Values” dialog box. There are functions that give the areas of the cell faces: BlockAreaTop, BlockAreaFront, and BlockAreaSide. For unconfined conditions, you would need to adjust the front and side areas to account for just the saturated thickness. You would also need to figure out what to do when the sizes of faces on adjacent cells don’t match because of variable layer thickness. Finally, you would need to decide whether or not to adjust the vertical vector component for sloping layers and decide what to do about vertical exaggeration.
MNW2 is not supported by MT3DMS although MNW1 is supported. The Flow-Transport Link file generated by MODFLOW will not contain flow rates for MNW2. I suggest converting your MNW2 wells to MNW1 wells or using MODFLOW-GWT instead of MODFLOW + MT3DMS. You might also look into MT3D-USGS and see if it supports MNW2.
some of the MODFLOW versions may not write MNW2 flow terms to the FTL file that is used by MT3D. It would be good to confirm this. One of the reasons for simulated concentrations to be lower than measured could be dilution as a result of multi-layer mixing within the well. Accurate representation of well screening information in the model may be one of the things you might want to check. To compare simulated concentrations, are you looking at the MNW mixed concentration, or are you looking at model cell concentration within a particular model layer in which the pumping well exists? Can you check how the model cell concentration compares to mixed concentration in the well versus the measured concentration.
Sounds like your flow system may be dominated by fractures, conduits or other type of preferential flow path. Trying to model such systems with single continuum type of model would give you such symptoms because the model is using a diffuse transport model, while in reality, your pumping wells are pulling the tracers into the fracture system where they can be transported to the well more quickly and with less dilution.
A flow systems with preferential flow paths like fractures, conduits, or thin gravel layers will have exactly these symptoms if you try to model it as a homogenous porous media.
The list file is always the best place to find out where the problem is.
Try to check the extent of your shapefile for example if you click at the properties of the shapefile with topo data. Then give the same extent to your model while making the model in visual modflow. specify the cell size etc. and then import the shapefile of the ascii raster.
If your well crosses two or more model layers, there are some advantages to using MNW1 or MNW2.
It’s worth getting in the habit of reading the documentation for the different packages (links below). They’re extremely useful and describe all the math behind how it works. It also helps keep us modelers from getting in the black box mentality. As Dr. Winston said, the main advantage of the MNW/MNW2 packages is when a well is screened in more than one layer or cell. In such cases the package calculates, based on prescribed pumping rates and cell heads, how much water should be pumped from each cell in which the well is screened. It can also be useful in certain GUIs (i.e. Argus) if you don’t feel like figuring out which well belongs on which layer. I believe that ModelMuse figures that out on its own for all well-type packages.
https://water.usgs.gov/nrp/gwsoftware/modflow2000/MNW_text.pdf https://pubs.usgs.gov/tm/tm6a30/
You are creating a model to estimate the heads at the river bed, I guess. You have to make cells with sheet piles with conductivity around 1e-9 m/s and with constant head boundary of the river elevation where it exists. Then you have to use a drainage boundary condition at the bottom of the sheet pile where you drain the entire excavation. Do not forget to give same hydraulic conductivity value to the cells representing the bottom of the sheet pile.
Make a Zone Budget in the flow model will help compute submarine discharge from coast.
Based on the Output Control Option (https://water.usgs.gov/ogw/modflow-nwt/MODFLOW-NWT-Guide/), there are a few options for the output formats. This is just an example that you can change the layout of the output file. You can check the input files to see the differences. Since you are using Modelmuse, I think there is not too much you can do with the source code. However, if you are able to compile the MODFLOW source code on Linux or Unix, you can actually change the format easily based on your needs. Using formatted output is actually helpful when you do post-process but you need to make sure no information is missing in terms of precision. I think in most cases you don’t have to consider storage limitation if your model is not too large.
If you want to assess how much water canal can leak to the aquifer then you have to use it as a river and let the water leak into the aquifer. You can check if this is happening in the model through water budget module.
Visual MODFLOW® Flex is the industry standard software for 3D modelling flows of groundwater, transfer of heat and pollutants.
Visual MODFLOW Flex allows you to choose the modelling approach you want to use when building the flows of groundwater models. You can choose the approach conceptual models, highly efficient and extremely flexible, or the approach of conventional models. With Visual MODFLOW Flex, you have a complete set of tools that allow you to treat the water quality, groundwater flows, and initiatives concerning the protection of spring water, thanks to:
MODFLOW-2000, 2005, NWT - Standard modelling of groundwater flow MODFLOW-LGR - Local mesh refinement (LGR) in shared node for simulations at the regional-local SEAWAT v.4 - groundwater flow with variable density in 3D, associated with solute transport for several species and heat transfer MT3DMS - Package Standard simulation of pollutant transport for several species MODPATH - Standard Package modelling the particle path Zone Budget - water balance calculation Package of different sub-areas PHT3D - 3D modelling of reactive transport code of several components in saturated porous medium which combines the two existing computer programs most used, the solute transport modelling and geochemical PHREEQC MT3DMS-2 code of the USGS. WinPEST - Automatic calibration and sensitivity analysis View all flow engines, transportation engines and MODFLOW packages.
I will suggest you to move step by step. Have a groundwater model with river only. Check if you can reproduce the historic groundwater levels. An acceptable groundwater model will be the initial head to the next model. In the next step you will have to add wells. This will be initial head to the next model. You can introduce canal as another river boundary and vary conductance to match the groundwater levels in the vicinity. You have to check whether the canal affected the groundwater levels in reality or not and then start modeling. It can also be that the well irrigation is actually influencing it.So you have to be really sure about that. Type of crop also influence these kind of groundwater levels. There will be a lot of uncertainties in the model like the agricultural fields and the meteorological forcing.
I think what is happening is that somewhere your stream either goes above the top of the cell that it is supposed to be in or below the bottom. Probably the best way to fix that is to set the elevations of your stream cells a different way. Instead of specifying the elevation of the stream at beginning of the end, specify each cell individually. To do that, you have to go into the MODFLOW packages and programs dialog box and select the option there to set the elevation of each cell. Then then you can use a formula such as Model_Top to specify the stream elevation.
MODFLOW requires a almost ideal/simplest setup in terms of spatial location.
Ideally, water, especially in stream channel only flow from upstream to downstream. And the elevation of each stream reach MUST satisfy this rule, similar to stream bed. As a result, the slope of each reach must meet this requirement as well. So as Richard suggested, it is almost better to specify reach by reach instead of whole segment. This can be easily done with some GIS operation.
If you have the hydrology network, you should be able to see where each reach is located in the spatial domain. Your second warning about object should be also solved based on your hydrology network.
Vistas can handle PEST. Don’t forget to check out all the available PEST code on the PEST website. There’re a lot of Modflow resources there. http://www.pesthomepage.org/Groundwater_Utilities.php
WellFootprint: Software to compute the “footprint” of well withdrawals as an aid to visualizing the magnitude of well withdrawals. https://water.usgs.gov/nrp/gwsoftware/WellFootprint/WellFootprint.html
ModelArchiver and FgdcMetaEditor: ModelArchiver is a program designed to facilitate the creation of groundwater model archives that meet the requirements of the U.S. Geological Survey (USGS) policy. https://water.usgs.gov/nrp/gwsoftware/ModelArchiver/ModelArchiver.html
ModelMuse Version 3.10: ModelMuse is a graphical user interface (GUI) for the U.S. Geological Survey (USGS) models MODFLOW–2005, MODFLOW-LGR, MODFLOW-LGR2, MODFLOW-NWT, MODFLOW-CFP, MODFLOW-OWHM, MODPATH, ZONEBUDGET, PHAST, SUTRA, MT3D-USGS, and WellFootprint and the non-USGS model MT3DMS. https://water.usgs.gov/nrp/gwsoftware/ModelMuse/ModelMuse.html
MODFLOW 6 Version 6.0.2 https://water.usgs.gov/ogw/modflow/MODFLOW.html
FloPy Version 3.2.9: FloPy is a Python package for creating, running, and post-processing MODFLOW-based models. FloPy includes support for MODFLOW-2000, MODFLOW-2005, MODFLOW-NWT, MODFLOW-USG, and MODFLOW-LGR. Other supported MODFLOW-based models include MODPATH (version 6), MT3D, MT3D-USGS, and SEAWAT. https://water.usgs.gov/ogw/flopy/
If your goal is to optimize a Modflow model, consider using Modflow-gwm or gwm-vi.
For the stream flowing into a lake, specify the negative of the lake number as the outflow segment for the stream. For the stream flowing out of the lake, specify the negative of the lake number as the diversion segment for he stream. If you draw the stream close to the lake, a “Closest” button will appear in the space for the segment or lake number. If you click it, it will fill in the number for the closest steam or lake.
I’d say Modelmuse is perfectly capable of accomplishing what you want. Also, look into the well footprint package that has just been implemented on Modelmuse, it might help with what you want. The biggest advantage GW Vistas has when compared to MM is the ability to use unstructured grids, as MODFLOW-USG is implemented on their GUI. If don’t need an unstructured grid, ModelMuse is one of the best GUIs out there.
In MODFLOW 6, the CHD package allows cells to switch from specified head to active. In earlier versions of MODFLOW, that is not allowed.
Whenever you make a Modflow model using Modelmuse, it generates a nam file when you run the model. If you are using visual Modflow classic then find out the batch file in the directory and run that batch file.
I think you are referring to the Horizontal Flow Barrier package. It only affects groundwater flow between adjacent cells. Flow between rivers and groundwater is controlled by the river conductance.
PEST is model independent, see ~page 1 of its documentation. This means it can be made to work with any model that has text based input and output files, or utility programs to extract binary output. As such Sutra should work with PEST. The PEST utility programs for Modflow, and various user interfaces make this easier. You will need to understand how PEST works, and about template files. The PEST documentation is thorough, detailed and downloadable.
Looking at your plots, my best guess is that you’re not plotting what you think you’re plotting. It looks like you’re plotting in Matlab, possibly grabbing your model output using the MFLab code? Double check your coordinate system (are i/k swapped? did you flip the k direction?) and double check that you’re plotting flow and heads for the same time steps. Otherwise, it is likely a modeling issue related to how you’re setting up the model. I would imagine any wetting issues would generate large errors in your MF runs (especially because the model image you show only has discharge across the seepage face). Look in your listing file (generally a file with a .lst extension). What are your percent errors in each time step and for the overall model run. I try to keep my errors << 1%, typically ~.01% is a good aim. Also, make sure every listing file has a “normal termination” message at the end of it. If you’re not getting that, then the MF results are meaningless.
There are also numerous non-GUI PEST utilities for creating the PEST files. Unless your model is particularly complex (i.e., pilot points with regularization) the files can be generated easy enough without a GUI. The benefit of using the PEST utilities to create the PEST files is that it provides a better understanding of how PEST is operating.
Multiple Well Configuration in MODFLOW with Model Muse Tutorial https://www.hatarilabs.com/ih-en/multiple-well-configuration-in-modflow-with-model-muse-tutorial
With the stream output use only it will become ill posed problem! Try to estimate the k via pumping test nor slug test, or measure the permeability of the river bed via ASTM field procedure, maybe it will give you a threshold of the values for your sensitive analysis.
There are lots of ways to reduce errors. Changing time/space discretization is one way. Reconceptualizing your model is another. Trying different solvers and adjusting values including inner/outer iteration can also help (GMG is frequently good for non-linearity issues).
When Modflow crashes, it typically just ends. So a good way to see what caused the issue is to look at the last thing written to the lst file to determine where the issue occurred.
So, try reducing the things that make this hard to solve. Reduce the tidal oscillation amplitude, decrease your stress period lengths and cell sizes, decrease your hydraulic conductivity, increase the allowable number of iterations in the solver. Once you get it working at some other set of parameters, slowly work your way back to where you want to be and see which is/are causing the issues.
From the SUTRA manual: “Unsaturated parameters are obtained by a call to UNSAT.” Unsat is “a user-programmed routine in which unsaturated flow functions are specified”. There is more information in section 7.5 “User-Supplied Programming”. One way to write UNSAT would be for it to read a table of values relating the Van Genuchten parameters to the unsaturated flow property region number.
For display purposes, the average elevation is used. However, each drain gets the input assigned by its own object in the MODFLOW input files.
Select nodes on each points you have the head. Then set the GHB data to that point and then select the arc between the nodes and set them as specific head
You can make a shape file in GIS before starting Modflow modeling. In that layer you set all the wells with the elevations for each one. You can make an excel file with all the information and add data to GIS and the basin boundary. Then the shape file has all the information needed then you open the shape file in Modflow and select shape file to figure then all information on shape file layer would set on the coverage layer you want as I suggest operational wells.
It sounds like you want to interpolate among you are wells to specify the top and bottom elevations of your layers. To do that, first specify an interpolation method for the data sets that to find the top and bottom elevations of the layers in the “data|edit datasets” dialog box. Then create Point objects at the locations of your wells. Make them have zero elevation formulas and have them set values of datasets by interpolation. Then select the data sets that define the top and bottom of the layers and specify the observed values at the well locations.
In my opinion,you should start with MODFLOW,even though it requires a little effort in the beginning but it will prove to be useful over time.I want to shed light on following points:
In the scale 1 to 5, where 1 is easy to learn, 5 difficult to learn, these are approximate categorisation.
Groundwater Vista 1 Model muse 2 Visual Modflow 3 GMS 4 Hydrogeosphere 5
If your institute already has any one of the above softwares, you can use the same. If you have to recommend one, I suggest GMS. you can go to Google and search for the local prices.
• As a student, you start downloading student version of Ground water Vista and practice the tutorials and develop a simple model for your area. If required, you can buy Ground water Vista as it is cheaper with compared to other softwares. You can also use Modelmuse for your purpose, which is free. I have developed tutorial with data for Modelmuse. you can download the same as under.
• http://ssrao@waterinfotech.com/Grwater/Modelmuse%20Modflow%20tutorial.pdf & for the data click on • http://ssrao@waterinfotech.com/Grwater/MMBASICDATA.rar
Basically all softwares are same. Your project is more important and decide first your project and collect details to solve your problem.
There is a list of videos on YouTube on the application/set-up of ModelMuse (which uses the MODFLOW code). Search for “Hatarilabs” channel on YouTube for the videos.
In addition to the very useful comments on which model to use, I would add that the first step is to determine what you are aiming to model. Modflow is a groundwater model, and needs separate calculations for recharge inputs, and can be linked to other models for stream flows etc, but does not model these itself. Hydrogeosphere is an integrated subsurface and surface model that will simulate the whole hydrological cycle. We have developed and been using a similar water cycle model for many years called Shetran (downloadable with documentation and references from website below). If you are interested in just groundwater levels/flows and river baseflow, Modflow should be suitable. If you are interested in both groundwater and surface runoff, use one of the integrated models. I would also argue that FE methods don’t in themselves provide a ‘better’ model than FD methods (especially with the IFD formulations in MODFLOW-USD), as other issues e.g. representation of geological structures, and parameterisation, are often of greater concern.
The attached model is an example of how to have layers with non-uniform thickness some of which are discontinuous. Several different methods were used to specify the top of the model and the bottoms of the layers. For the top of the model, the interpolation method of the Model_Top data set was set to NearestNeighbor and three objects are used to specify the top of the model by interpolation. The bottom of the upper layer are specified by several polygon objects using formulas that are just numbers. In areas not covered by the objects, the default formula for the layer is used. The bottoms of the middle and lower layers are specified by an object that uses two different formulas for the different layers. All the objects that specify the elevations of the Model_Top or the bottoms of layers have the number of Z-elevations for them set to 0. The Active data set is specified with the formula “Z < 0.” Only the active cells are displayed on the front view of the model shown below.
If you use the recharge package with a model like this, be sure to specify the option in the MODFLOW Packages and Programs dialog box that will cause recharge to be applied to the top active cell. Otherwise, recharge will only be applied to the cells in which the top layer is active.
Don’t make the cell you want to be inactive a specified head cell. If you used a polygon object to assign the specified heads, add a new polygon section to that same object around the center cell.
Aquifer parameters (K,T, S, Sy), long term water levels, any borehole data for identifying the aquifers, Recharge rate, pumping well data for different seasons, Geophysical data if available, quality of water, river / stream details, river flow data if available
GROUNWATER VISTAS, GMS, MODELMUSE, VISUAL MODFLOW, ANY OTHER SOFTWARE YOUR INSTITUTE IS USING.
Head in a cell can be much higher than the top elevation of the cell. The concept simply states that the head in a confined aquifer is more than its top level and its because of this concepts like saturated thickness etc. exists. Also these conditions are prevalent in artesian aquifers. Try going through hydrogeology notes along with the type of aquifers and equations used to represent flows and heads in such systems.
I personaly create a line shapefile in a GIS (eg QGIS). Lines are perpendicular to stream path. I specify the variable you are talking about for every lines. I then create user data sets with river head, river depth, etc. and use those data sets to specify river parameters along their path.
I would like to know what happens in MODFLOW when head in a cell in the grid system rises to its maximum level ? Whether the head in the cell overflows or whether it is limited to a certain level ? - It corresponds to an inundation if your cell is in the first layer. It is not limited unless you applies drain boundary conditions, corresponding to a head fixed at your model top level.
These GUI like Visual Modflow Flex, Groundwater Vistas etc. actually produce files. These files are read by Modflow code which is freely available and is open source. Aquifer storage and recovery projects often use optimization codes where modflow is run inside these optimization codes and the output files are read inside the optimization codes.
You can use Modelmuse which is another open source GUI like Visual modflow flex or Groundwater Vistas. The biggest benefit of doing it is that the Modelmuse user community is more than willing to help you if you have small problems in fixing something in the model. Also there are number of help videos online.
If the head in a convertible layer rises above the top of the cell, the cell is treated as confined. Other than that, there is no special treatment of such cells. It is up to the modeler to recognize that the simulation results are unrealistic and to change the input to the model to correct the problem.
I understand that you want to know the meaning of a boundary condition. When you solve a partial differential equation in a finite space (or even infinite space) the intrinsic variable’s value has to be defined at the the limit of the boundary (if it is infinite then we define it at infinite) in one way or another. Hence the definition of the intrinsic variable directly or indirectly can be termed as boundary condition. Hence by definition itself a conceptual model defined using partial differential equation has to have boundary conditions. Now you define the system (or a physical space or a problem) using partial differential equation and you can tweak the equation howsoever to make it solve your problem. Hence these boundary conditions can be applied anywhere inside your physical system or at the boundaries. It means that you can apply it between the layers etc. depending upon the type of problem.
Modflow uses a backwards finite difference method to calculate the head values in each cell of your numerical model. However at the edges of your model there are no more adjacent cells so it needs to know how to handle them. So for instance you might make the edge a constant head value which never changes, or a general head which is determined by a remote stage. Either way, Modflow needs boundary conditions to know what the initial heads are so it can solve the backwards finite difference.
Increasing the width will increase the conductance between the stream the aquifer which should result in more flow between the stream and the aquifer. Assuming that the stream is gaining reach, that should result in lower heads in the aquifer. Increasing the slope will result in lower heads in the stream if the stream heads are calculated rather than being specified by the user. That should result in more flow from the aquifer to the Stream and lower heads in the aquifer.
If the groundwater flow of interest is in a thin soil layer overlying impermeable bedrock, it may be difficult to simulate this with modflow. However it is possible to simulate flow through fractured bedrock in mountainous areas.
If the cell containing an observation location goes dry, then the observation would become inactive.
FloPy, the USGS Python package for working with MODFLOW models, has functions for exporting the grid to VTK format and also for exporting results in netCDF format:
https://modflowpy.github.io/flopydoc/vtk.html
https://modflowpy.github.io/flopydoc/netcdf.html?highlight=netcdf
If there are objects that define the bottom elevation, those objects override the default formula.
If your recharge is only precipitation, then you should just be able to apply the precipitation boundary condition across the top of the model. If you have recharge wells, you can apply them by using a positive flow rate (indicates water into the model as opposed to negative which is water out). If you have recharge coming in from the sides, you could try applying a constant flux boundary condition.
The warning about the drain elevation gradient is triggered when the gradient in elevation between drains into neighboring cells exceeds a certain limit. The warning is meant to help identify locations where the drain elevation was specified incorrectly. However, it may also identify locations that are actually correct so the user must decide weather or not anything needs to be done.
ModelMuse is already stable on Modflow 6. So if your purpose is to simulate water flow, then you are good to go. It is however not compatible with MT3DMS yet if you are planning to simulate contamination plumes.
Change Modflow-2005 to Modflow-NWT - main difference is that MODFLOW NWT includes the Upstream Weighting Package as an alternative to the Layer Property Flow package. The Upstream Weighting package has a different way of formulating groundwater flow in unconfined conditions. This alternative formulation can help avoid some instabilities with cells converting between wet and dry. The only real change you have to make when using MODFLOW NWT is to activate the Upstream Weighting package.
You are never required to use the CHOB package. You can use the CHOB package to specify observations of flow through specified head boundaries.
When you specify river head it is a boundary condition and the simulated heads will be exactly the same as the specified heads. Whether the river will act as a source or sink will be controlled by the head difference between the specified river head and the simulated head close to the river cells. Its the hydraulic conductivity close to the river cells and the riverbed conductance which controls the simulated heads close to the river.
You can calibrate MODFLOW-NWT models using ModelMuse in conjunction with ModelMate and UCODE.
The Stream package is documented in https://pubs.er.usgs.gov/usgspubs/ofr/ofr88729. You should read that documentation. The Stream package has been superseded by the Streamflow Routing package (https://pubs.er.usgs.gov/usgspubs/ofr/ofr20041042 and https://pubs.usgs.gov/tm/2006/tm6A13/) but is retained in MODFLOW for backwards compatibility. When one stream segment flows into another, the downstream stream segment into which the flow occurs is the outflow segment. If flow out of a segment is to two or more segments such as when water is diverted from a stream into an irrigation canal, the upstream segment from which the diversion occurs is the diversion segment. In ModelMuse, each object that defines streams in either the STR or SFR packages defines one stream segment.
Does this error appear when generating the input files by ModelMuse or when running the SUTRA? If it is with ModelMuse, try to find a way to reduce the number of nodes in your model. When your computer does not have enough memory, it will try to swap out some of the things in memory to the hard drive until they are needed. If there isn’t enough space allocated on the hard drive for this purpose, you will get the “out of virtual memory” error. I think it’s possible to control how much of your hard drive can be used for virtual memory somewhere in the operating system.
We’ve read your recent review of models and fear that the utility of newer versions of MODFLOW such as MODFLOW-OWHM (which includes the Farm Process FMP updated) or the even newer version of MODFLOW-OWHM now simply called “One-Water” were overlooked in the power of their ability to simulate and analyze conjunctive use. With the new version of One-Water also able to simulate reservoir operations as well as fractured-rock aquifers, you may want to go back and reassess the capabilities that you summarized. We’d be happy to discuss this further with you or send additional information. Also please recall that MODFLOW-OWHM was recommended by the World Bank as one of the top three codes for analyzing conjunctive use. Since this is a powerfully important issue in places like India, we would urge you to have another look at what these various codes can and cannot do.
Let me know if you’d like additional information. I have retired from the USGS as we release this new code by the end of February, but have my own consulting business now open called One-Water Hydrologic, LLC. You can go to our company website for more information and other links to code. If you’d like to try the One Water code let us know and we can send you a Beta Version.
The SWT package does not have any MODFLOW-style parameters. To calibrate it with ModelMate and UCODE you would have to manually create a suitable UCODE template file. If you don’t have MODFLOW-style parameters for HK, VK, etc. you will need to manually create a suitable UCODE template file to calibrate them. ModelMate will only create templates for parameters define in the .pval file.
SUTRA_Mesh_Top is evaluated at nodes. Model_Top is evaluated at elements. If you switch from a model in which Model_Top is used to one where it isn’t, Model_Top is moved to the optional group.
If you were to write a balance equation you could write:
IN - OUT = ACCUMULATION
An excess of IN causes ACCUMULATION. The IN and OUT parts come from change due to boundary conditions and the ACCUMULATION comes from change in STORAGE. Let’s separate ACCUMULATION into two parts:
IN - OUT = STORE_INCREASE - STORE_DECREASE
If there is no in and out in a cell, any increase in storage comes from STORE_INCREASE and decrease from STORE_DECREASE. Now let’s move parts of accumulation to each side:
IN + STORE_DECREASE = OUT + STORE_INCREASE
This matches up to the values given in the balance. STORAGE_DECREASE values are given as a positive value and STORAGE_INCREASE are given as a positive values. This would mean that an increase of storage on the IN side goes out of the cell and the OUT side goes in the cell.
Time series plots of the temporal changes in the rate of aquifer storage would help to visualize that STORAGE IN is the rate of mass added to the system through sources (precipitation, regional groundwater recharge) and STORAGE OUT is the rate of reduction in mass storage.
Also, this contains interesting comments about storage terms and Balance interpretation:
http://inside.mines.edu/~epoeter/583CSM/13_CommentsTransientModelingReports.pdf
The flow into or out of the river will occur through the bottom of the river. Thus, the area of the river bottom is one of the factors that controls how much water flows through the river bottom. For a line, you need the width to determine the area of the river bottom. If the width of the river is much smaller than the cell width, a line is easier. If the river width is greater than or equal to the cell width, a polygon is better.
Imagine that you have simple model with just recharge and specified heads. Water enters through recharge and leaves through the specified heads. The amount of water that leaves through the specified head boundaries will be the same as the amount of water that enters through recharge. You can get exactly the same head distribution for different values of recharge by changing the hydraulic conductivity of the medium. You must either have prior information about what the recharge rate is or you have to have some different type of observation to calibrate the model. You might have prior information about recharge through conducting a tracer study.
You can use a constant head boundary to represent a river when the conductance between the river and the aquifer is so high that the river controls be head in the aquifer. You can use the general head boundary to represent a river if the head in the aquifer never drops below the bottom of the river bed.
Regard to your question about the river package I think it would be worthwhile to review what you have to specify for River cells. Besides the location of the river you also must specify the stage the conductance and the bottom of the river bed. The riverbed is the material that lies between the water in the river and the aquifer so the bottom of the riverbed is the bottom of this material. If the head in the cell containing the river drops below the bottom of the riverbed the flow out of the river will be determined by the conductance and the difference in elevation between the river stage in the river bottom. If the head in the cell containing the river is above the bottom of the river bed then the flow into or out of the river is determined by the conductance in the difference in heads between the river cell in the stage of the river. If you don’t have actual measurements of the river stage it seems like it would be reasonable to use the ground elevation as an approximation pause of the river stage. The river stage should always be greater than the bottom of the river bed. The bottom of the riverbed should always be greater than the bottom of the cell containing the river. If it isn’t, then it should probably be moved to a cell in a lower layer. Beyond the advice to make the bottom of the river bed less than the river stage and greater than the bottom of the river cell, I don’t have any advice about how to specify the bottom of the riverbed.
A main difference between SFR and SWR, is that the first one doesn´t account water storage due to a single flood running down the stream. That means that each module has different time scale. SFR is useful in a month, year or decade scale, where you use mean flow while SWR is for an hour or minute time step, where you are describing a lagged hydrograph downwards (Like an event in HEC-HMS). They are also different in percolation approach. I quite understand that SFR only allows deep percolation to tablewater while SWR allows bidirectional exchange.
In MODFLOW, when you specify an injection rate with the Well package, the injection rate you specify is used regardless of whether the resulting heads are realistic or not. It is up to the user to recognize that the simulation results are unrealistic and to change the model input to correct the problem. With your model, there are at least two possibilities. (1) Use lower injection rates. (2) Specify higher hydraulic conductivities. Higher hydraulic conductivities would allow water to flow away from the injection site more easily. It would also make sense to check your specified head and specified flow boundaries to make sure they are realistic.
GMS can be used to build Seawat models. As you’ve probably seen from your reading, variable-density flow/transport models are non-trivial to construct accurately, so make sure you have a well-defined question and set of expectations prior to constructing your models.
The storage is not calculated as the remainder after accounting for other terms. Instead, the change in head in each cell is being combined with the specific storage or specific yield to calculate the storage term in the water budget.
No storage terms are included in the steady-state model.
The head is a measure of the energy of the water in an aquifer due to its elevation above a datum and it’s pressure (The datum is typically sea level). Water table depth is the distance from the ground surface to the water table.
Head(groundwater potential) is the the water level at a specific point if you have a piezometer having filter installed at that specific point.
Modflow 2005 and before only use rectangular grids – including the child grid in a nested grid (except for Modflow-USG). Every grid (including child grids) must be rectangular. You may make cells in the inactive in one of these grids, which can give the appearance that your grid is not rectangular, but those inactive cells still exist. I may be incorrect, but I do not believe you can make cells inactive in the child grid–even if you can, I would be very careful about doing so.
You can check the Online Guide to MODFLOW for the requirements of the SFR package. Drain boundaries remove water from the model and do not allow it to be returned to the model. If you use SFR, the stream can flow into a lake that can interact with groundwater.
If you want to model drainages, you must use DRT package. DRT allows you to take water from a table water at a landscape (or a farm), associated with a deepth and a conductance, and transform it into a flow at a location. For the other hand, SFR take that flow and make it travel through the river network, interacting with table water at the river or lake bottom (flows to or from the bottom). Link between these packages are at the DRT packages.
The flexibility of deactivating model cells in MT3D is provided with the intent to save computation time for model cells that are not expected to contain any solute. For example, simulating a small plume within a large flow model would benefit from deactivating all model cells expect where the plume is expected to be present. If model cells that are expected to contain solute at some point in the simulation are deactivated, it is expected that you will notice mass balance errors in MT3D since you are ignoring a portion of the plume in the numerical solution and in the mass balance calculation.
To answer your first question, the problem you are having is probably a coordinate system issue. Basically what’s going on is that your model needs to have a conceptual model area defined in which you build your model in. It also needs structural horizons which it builds from 3D surfaces. Both the model area and the 3D surfaces must have their locations defined in space (3D georeferenced). It sounds like the error your getting is that the surfaces you are using are not contained within the geospatial area defined for your model. This may be due to a coordinate system problem where your data for your surfaces is not in the same coordinate system as your model area. Without being able to look at your actual model it’s hard for me to say much beyond that.
To answer your second question, I built my horizons for the model I’m working off using 3D spatial interpolation in ArcGIS. There are other tools you can use to do this as well such as SURFER. Either way, I’m not sure you can develop horizons straight from a spreadsheet.
Decrease the solver convergence criteria number and increase the number of iterations as a first step. Percentage discrepancy should drop down.
If you are using the LPF or UPW packages, MODFLOW calculates the vertical conductance from the vertical hydraulic conductivity. With BCF and HUF, it is more complicated.
Length and time units in MODFLOW and MT3D need to be consistent. Concentration units in MT3D, however, are independent of the length and time units. For example, a model could use feet and days for length and time units, respectively, and use mg/L as concentration units. In this example the mass flux units in the model would be mixed units of [(ft^3/day)*(mg/L)]. That is the unit to be used for calculating mass loading in the model. Therefore, depending on the units being used for length, time, and concentration, you would need to calculate mass loading in appropriate ‘mixed’ units.
This problem could occur for many reasons. One reason could be that you are in dry or inactive cells - (1) Check the well screens to make sure they are not at too high an elevation. If they are higher than the water table you won’t get any hds. (2) Also make sure you do not have an observation value for the first time step.
Use ZONEBUDGET to track how water leaves the groundwater mound both during and after the recharge stress period.
Conductance = river length in cell X river width X hydraulic conductivity ÷ river bed thickness.
If the outflow rate is in units of L^3/T, divide the volume of the groundwater mound by the outflow rate to estimate the time required to remove it. You can estimate an upper bounds on the mound as the it’s area times its height and a lower bound as 1/3 the upper bound.
You don’t say whether the river is connected to an underlying geologic unit in the model or whether it is entirely disconnected from the modeled units. If it is entirely disconnected, I would use drains to represent the seepage face in the valley walls. If it isn’t completely disconnected, I would probably have inactive cells in the layer which has been cut through and a river in the underlying layer.
In MODFLOW, you can have what is called a quasi 3D model in which some geologic units are not represented by any layer. For example, you might have a confining bed between two aquifers. Ordinarily, that would require a model with 3 layers. In a quasi 3D model, there would only be two layers. The confining bed would not be represented by a layer. Instead, flow through it would be treated as completely vertical. In the LPF package, the only thing about it that you would specify would be it’s vertical hydraulic conductivity.
Go for Modflow NWT solver instead. If dry cells are the problem, it deals with it efficiently.
Use your well-log (drill log) data and geological map to produce a 3D model of your aquifer system first. You may need to use geological software like Rockworks/geomodelr for that purpose. This will help you produce your hydrostratigraphic units (aquifer thickness and geometry). Again, use your pumping test data to estimate the hydraulic properties of the aquifer system (T, K, Sy, S, Ss etc). If you have layer based tests, it would even make it awesome. Otherwise, you can use your estimated values as inputs. This is how you produce a hydrogeologic model and assign appropriate hydraulic properties of an aquifer. After all, what you need as the main input to Modflow from the hydrogeologic perspective are:
-Aquifer type -Aquifer thickness -Aquifer boundary
These can be known from the 3D model. AND,
-Hydraulic properties of the aquifer (T, K, Sy, Ss, S…). And, these are estimated from the pumping test data.
Modflow solves the groundwater flow equation while mt3dms solves the transport equation. mt3dms uses a flt file or the flow matrix generated by modflow. So coming to your question of the dry cells problem, try running the model with appropriate boundary conditions and realistic parameters. You have to look at the model results if this is what you expected and you have represented the conceptual model satisfactorily. In case you still have dry cells then chose the aquifer thickness which does not run dry in the model and use that as the Model top.
Depending on your needs, there are some packages that allow the CHD to be turned on/off (e.g. Vincent Posts PBC package).
Use PHT3D which is MT3DMS for advection/diffusion/ dispersion + PHREEQC for chemical reaction.
PHAST can be used to simulate solute transport with reactions. ModelMuse can be used to create the input files for the fluid transport part of PHAST but the chemical part must be generated outside of ModelMuse. ModelMuse supports version 1.51 but not more recent versions.
ModeMuse only allows interpolation for 2D data sets not 3D data sets. You could create one or more 2D data sets and use interpolation in them and then use formula for the 3D datasets to specify the initial head. However, it would be better to use a steady-state stress period to determine the initial head for any transient stress periods. For a steady-state stress period, the initial head doesn’t matter so long as no cells go dry.
Your model budget shows recharge but doesn’t show any water leaving the model although drains are included in your model. Maybe none of the drains are in active cells.
If any cells go dry for which you have specified recharge, no recharge will apply to that cell. K can affect which cells go dry. There is an option in the recharge package to apply recharge to the top active cell. You may wish to use that option.
Flooded cells do not affect recharge.
In SFR package (which uses kinematic wave equation), using ModelMuse, you can specify the inflow to the streams as a time series in the SFR editor or even as an external time series file.
If the rivers are large enough that interaction with the aquifer does not affect the river stage, you could calculate the stage outside of MODFLOW and use it as part of the input for the river package.
If you import the shapes as polygons, you can use them to define wells in ModelMuse by using the “Calculated” option. If you do that, you enter the pumping rate in units of L/T. You may need to multiply by some constant to convert the abstraction rate to the units used in your model.
If its a gaining stream then use the drn package. Otherwise use riv package if its gaining and losing at different places and different times.
If you want to simultate change in storage you must set up your model to transient and apply the storage parameters accordingly.
Specified head boundaries such as the CHD package can supply or receive an unlimited amount of flow to maintain the specified head. No matter what you do, the head in CHD cells will be maintained at the level you specify. Above the dam, humans control the water level in the body of water upstream of the dam so a specified head boundary is a reasonable way of modeling it. Below the dam, the water level is not being controlled so a specified head boundary may not be appropriate. The question then becomes what sort of boundary, if any, is appropriate. First, let’s consider no boundary below the dam. If you do that you can expect that even the small amount of flow passing through the dam would eventually even out the upstream and downstream heads. Thus no boundary below the dam is probably inappropriate. If there is expected to be flow over the dam, the water level in the river downstream of the dam is likely to be an important control on the groundwater levels below the dam. Another control would be groundwater flows into or out of the modeled volume. For instance, if the model is limited to unconsolidated sediments, is there exchange with the underlying bedrock? At the downstream end, there might be flow into the unconsolidated sediments beyond the edge of the model. If you want to consider exchange with the bedrock, the general head boundary package might be appropriate. That might also work for the boundary at the downstream end although for it, you could also consider using a specified flow boundary using the well package. Regardless of how you end up simulating the boundaries below the dam, you could get whatever results you want by varying the properties of the boundaries. For your results to be persuasive, that means you must have good theoretical reasons for specifying the boundaries the way you do. For instance, if you use well boundaries to specify flow out of the downstream end of the aquifer, you need to have a good reason for choosing the flow rate you apply in the model.
Either too much water is going into the model or not enough water is leaving the model or the water that is entering the model can not be redistributed efficiently. Maybe your recharge rate is too high. You could try putting drains over the entire top surface. In essence what this does is to reduce the recharge rate in places where the water level gets too high. If you have rivers or drains where water is leaving the system you could try increasing conductances of those boundary conditions. You may need to adjust the hydraulic conductivity or specific yield.
When this kind of a situation occurs, since MODFLOW is using Darcy’s equation, actually how is the model capable of representing the water table when it is not within a porous medium (in this case, above the ground surface). Is there any module which is capable of calculating the depth of the ponded water when the saturated zone rises to the level of the ground?
Introduce a drain layer over the first layer drainage level as the Model-Top. Dont forget to use Modflow NWT instead. The drainage boundary condition actually simulates the runoff process. It sounds a bit odd but it works.
Be sure that both recharge and evapotranspiraction represent the values to or from the saturated zone. For example, precipitation is not equal to recharge because not all of the precipitation reaches the water table.
This drainage layer accounts for the surface runoff or the surface water which ends up in lakes, rivers etc. (in principle). It will only remove the extra recharge in case the water table starts exceeding the model top. Otherwise it will have no effect. You can do a water balance to verify. The other way is to find out groundwater recharge and discharge areas (surface runoff). In recharge areas the recharge boundary condition is used while in the discharge areas a drainage boundary condition should be used.
Using the heads in pumping wells as observed heads presents a challenge because MODFLOW computes the average head in a cell not the head at the pumping well. You will have to adjust for that difference.
MODFLOW uses an iterative process to solve the ggroundwater flow equations. If all goes well, each iteration will be closer to the true solution than the previous one. When the solution meets the criteria in the solver, the model is said to have converged on the true solution.
Storage is one of the budget terms stored in the cell-by-cell flow file. When importing model results, you can choose the .cbc file and import the storage term.
In this case storage refers to the water entering or being released from storage during the time step. The MF6 documentation describes it following in terms of the water budget:
“Flow into and out of storage is also considered part of the overall budget inasmuch as accumulation in storage effectively removes water from the flow system and storage release effectively adds water to the flow—even though neither process, in itself, involves the transfer of water into or out of the ground-water regime.”
So, in this case the “IN” storage term is actually water being released from storage (and available to flow), and the “OUT” storage term would be water that is removed from flow and is now in storage. The total change in storage over the time step, however, is found by taking the difference of all the inflows and all the outflows.
Hydrogeology - hydraulic conductivity, porosity, storage - stratigraphic thicknesses of each unit
Initial conditions - head, concentration
Boundary conditions which will need different things depending on your system (head, flux, etc.)
For calibration- you’ll need changes in head and/or concentration through time so data from is helpful.
This will get you started, and there’s more. Download some tutorials and try some models.
Perhaps you need to adjust either the conductance or the head of the GHB boundary through which water leaves the system. If there is recharge in your model, perhaps the recharge rate is too high.
After calibrating the model, you can add additional stress periods to represent future conditions. You will need to estimate the future stresses on the system. The accuracy of the predictions will be limited by the accuracy of your predicted stresses and by how well your model represents the actual conditions of the system. Please note that having a well calibrated model doesn’t mean that the model represents the system well particularly if some aspects of the system are poorly constrained.
L3T-1 is the pumped volume. In the water budget there should be a WELL term in the OUT section which represents the pumped out volume in different stress periods. If I had to plot it then I will use a zonebudget which will create an excel file which will be easier to use for plotting.
I generally shy away from the GHB for several reasons. 1) I find the CHD to more intuitive. 2) The computational stress is different – if you’re setting a high GHB conductance to mimic a CHD, why not just use the CHD, which is less computationally difficult (i.e. not computed at all). 3) In MF2K05 and before the CHD allows (while the GHB does not) you to specify a start and end value for each stress period, and the value for timesteps within will automatically change (I don’t know how MF 6 works).
It looks like a lot of cells went dry. Maybe that caused a group of the remaining cells became disconnected from the rest of the model. Recharge to those cells could cause the head to rise so high that the value for a cell was above the maximum value that could be represented on the computer.
Just in case you haven’t considered this, MODFLOW requires you to use consistent units throughout you model. If you want to use abstraction in cubic meters per month, then your time unit must be months and your length unit must be meters. MODFLOW doesn’t have month as one of the defined time units so you would have to use “undefined” as the time unit. The easiest thing to do, I think, would be to use the Well package for the abstraction. You would use the “Direct” option with it. See the ModelMuse help for a description of the Direct option.
Model Top is the top of the uppermost aquifer (you choose whether that aquifer is un/confined). If the topmost aquifer is unconfined, then Model Top is the top of the unconfined aquifer–though the top of the unconfined aquifer is almost always the land surface.
Model_Top represents the upper surface of the first (uppermost) layer. Model_Top can be higher than, equal to, or below the land surface. An example of where Model_Top would be above the land surface would be if one geologic unit has been eroded away in some places. In the areas where it has been eroded away, it would be represented by inactive cells. An example of where it would be below the land surface is if only deep aquifers are being simulated and the overlying rock is not included in the model.
If applying a daily rainfall time series, is it better to let the UZ package calculate the recharge rather than applying a percentage of the rainfall in daily time steps using the RCH package?
Water Table is much high above ground level - Too much recharge and low hydraulic conductivity is the reason. Keep a drainage boundary condition at the top layer with elevation equal to the Model_Top to improve it.
If you are asking how you would simulate the effects of soil erosion, it could be done by reducing the river head by the amount by which erosion has lowered the riverbed. You might or might not want to reduce the river bottom too. Depending on what you choose, you may need to adjust the conductance to reflect the change in river bed thickness.
Run the model without the mine. If you see that the head values are reasonable then there is no reason to doubt the model. The mine would have to be conceptually inserted inside the model with large hydraulic conductivity and putting a drainage layer at the bottom of the mine.
RIV conductance can be calibrated or used in a sensitivity analysis in PEST like any other parameter. Most GUIs support this. If yours doesn’t, take a look at the PEST documentation. As far as parameters go, it’s an easy one
All storage properties are only used in transient models.
I think you better try a different boundary. mostly flow boundary can be changed to flow to general head and the like to see a result. some times constant head boundary gives water continuously to the system and you may not see any draw down. the other thing is the hydraulic conductivity. if you make it smaller flow will be smaller and you may not see any change in the water level. if you increase the hydraulic conductivity you can see a result. look at you recharge also.
The simulated heads are interpolated from the heads in multiple cells around the observation location not just the cell that contains the observation location.
Have you checked the percent discrepancy in your model budget? If the percent discrepancy is high, the flow rates could be wrong.
Ephemeral lake boundary - You can use GHB or time-variant specified head boundary condition in order to model the lake boundary. Generally, the numerical simulation code is selected based on the conceptual model of the study area. For someone who familiar with MODFLOW-2K and MT3DMS, SEAWAT can be a good choice. Sutra can be another option. It is widely used. Femwater is also another option.
If I understand the problem correctly, you have an angular unconformity underneath the soil layers. If you are using MODFLOW 6, you could use vertical pass-through cells to simulate this. In MODFLOW- 2005, you would need to use the HUF package.
Try with simple settings in Newton Solver. Also provide a high hydraulic conductivity for the cells above drain cells. If you have tried that and it was not converging then move to moderate and complex settings. Drainage conductance can be 1 or 10 depending upon the size of the cell. It can be 0.1 as well, try with smaller values first.
My suggestion would be to take stagewise the minedepth and then model the minedewatering at different stages using steady state models. Taking cells above the mine depth with high hydraulic conductivity removes any water from the cells representing the open pit. I have modeled without it and then I see water in the cells representing the open pit. Bedrocks groundwater levels are reflected very crudely in borehole observations usually in crystalline bedrocks.
Of course I dont know what bedrock you would be modeling but accurate results are hard to achieve and can be more difficult to explain. Unsaturated zone modeling is highly inaccurate and biased usless the cell sizes are close to 10cm which has been often ignored by hydrogeologists/geotechnicians
Answering about discretization, It is shown in Olaf Ippischs journal that any discretization below 10cms would give biased result. I dont know if there was any other research to counter that claim. Rest it is just that the results have to make more sense about why the model has to be made in that way.
If you weren’t using the PCG solver try using it. Sometimes, if a group of cells is separated from the remainder of the model, you could get the sort of error you report. I think the PCG solver handles this better than some of the other solvers. You might need to run your model in a FORTRAN debugger to figure out exactly what the problem is. Another option is to try importing your model into ModelMuse and then exporting it again. ModelMuse does a lot of error checking and might detect something that is a problem with your model.
The Z coordinates determine the layers to which the specified head boundaries apply.
MODPATH 7 requires that all rows and columns have the same width or else that quad tree refinement be used. The grid angle must be zero.
The evapotranspiraction depth is not an elevation. It is the distance from the elevation where ET is at a maximum to the elevation where ET is zero. From your description, it sounds like you should have set it to 0.2. Most plants have deeper roots than that so a larger value would probably be better.
If you are using Modflow 6 then quadtree grid refinement doesnt work with Mt3d.
Your problem is that many cells have gone dry despite rewetting . You must check your steady state simulation if every thing is fine then you check your packages invoked in the transient process. In case you have started transient state directly then go back run the model in steady state and use the steady state heads to start transient state.
The first thing to do would be to look in the listing file to see when some of those cells from it dry. If they went dry in the very first time step of the model, you should check the initial head.
Error in simulated groundwater levels - Try with drainage boundary condition at the stream cells. Try increasing the hydraulic conductivity also.
Error in simulated groundwater levels - Check your conceptual model. In particular, check the sources of water going into groundwater and how groundwater leaves the system.
If you put both an injection well and a drain cell with a high conductance in the same cell, you should be able to get something close to what you want. The injection rate must be high enough that the head rises to the drain elevation. The drain conductance must be high enough that the head doesn’t rise much above the drain elevation. If the drain conductance is too high, the model may be unstable.
Recharge includes only the water that reaches the water table so you should subtract any evapotranspiration from the unsaturated zone. If you are using the Evapotranspiration package, it will calculate the ET from beneath the water table. If you are not using the Evapotranspiration package, you need to subtract all ET from the rainfall to get the recharge. Using a single layer would be a common approach if you only have a single aquifer.
I know one difference which gives finite volume upper hand i.e. mass balance is applied at every node in principle while as other methods use global mass balance over the whole grid. Ofcourse it doesnt mean that solution will be any different as per say since it is the same equation which is solved over the whole grid.
We solve a partial differential equation to find groundwater potential at every grid cell. Any solution of partial differential equation in finite domain requires the representation or the value of the state variable at this finite domain. Hence by definition itself we require boundary conditions.
In solving the groundwater flow equation boundary conditions dictate the resulting flow field which in turn is used by the solute transport model. So in simple words in correct hydraulic heads would result in incorrect direction and quantum of solute to be transported by the model, hence most reasonable/ accurate flow field would be required to see the fate of solute to be transported by groundwater. I think you need to understand the ground water hydraulics and solute transport equation parameters and their significance first before attempting the modeling exercise.
The issue lies in the conceptualization of the wetland & the barrier. Is the barrier an existing one or a proposed one ? You need to study the hydraulic head & Hydraulic Conductivity distribution in the wetland and the boundary conditions. A serious study would enable you to most reasonably conceptualize the area to be modeled. One must always remember that modeling programs don’t make a model they only perform computations for simple and complex processes conceptualized.
Hydrogeosphere and OpenGeosys are two environmental models that incorporate PDEs for solving flow for multiple domains (groundwater, unsaturated, surface water, and flow between the different reservoirs). Comsol is a more-developed “Multiphysics” commercial option that allows you to simulate any PDEs you desire, (though it is less specific to environmental apps). Each of those options uses CFD simulations for the surface water component and Darcy for GW flow. My recollection is GSflow solves the surface bits analytically, rather than numerically, but I could be off (never used it), so these might be more accurate. I haven’t spent much time with any of those software besides completing a few tutorials and deciding they weren’t what I’ve needed for my tasks, but they all have a bit of a learning curve and varying costs and amounts of support.
You could also use Modflow or Sutra and set appropriate time steps, and apply appropriate boundary conditions. I’ve done this where I used Matlab/Python to generate input files based on analytical solutions (e.g. the MF CHD file) myself using using either something like airy wave theory to apply wave BCs for a shallow seabed or logged stream stage time series.
You could always one-way couple by using seabed-pressure (or, streambed, etc.) results from a CFD simulation of the surface water (lots of CFD codes out there e.g. delft3d) as the inputs for the groundwater domain – I’ve done this with some success by linking coastal CFD wave/tide/current models to Modflow models.
Make Water Table contour maps of Dry & Wet seasons to identify nature and type of hydraulic boundaries of your area, then make a sketch diagram of the area including the layers and processes you would like to simulate, you would yourself come to know about the answers that you are seeking.
Based on your description in the e-mail below, following are a few possibilities that would lead to reduced concentration than background:
There may be a boundary condition that is introducing concentrations lower than background; or You may have local flow balance errors that could lead to some oscillations in the results. A seemingly good global mass balance may mask local issues leading to erroneous concentrations. I would recommend making the head closure criteria tighter, especially the residual tolerance; or The boundary where you are introducing non-background concentrations, are specified with a lower concentration than the background?; or You mention that there are dry cells in the model. Is the DRYCELL option active in the BTN file? If not, that could be responsible for the issues you are noticing.
Regression is never used during calibration or to show how well/bad the model performs. You have to plot it against Obs=Sim line.
Use draining package in that case!! The river will be forced to only take water from the cells surrounding it if the drainage levels are lower than the surrounding cells.
Use GW_CHART. It works fine with these things. Create a file with cell locations and then import this file and the head file. It will give h(Column, Row, Layer) which you can use. More advance procedures are available using FloPy.
Lots of videos are available on youtube that would definitely help you to devise a groundwater model using MODFLOW. The easiest route would be to go through the "A Modular Three-Dimensional Finite-Difference Ground-Water Flow Model, U.S.G.S., Techniques of Water-Resources Investigations, Book 6, Chapter A1 (1988)
Link:https://pubs.usgs.gov/twri/twri6a1/html/pdf.html.
Then go through the MODEL MUSE tutorial videos link given in the help tab of the MODEL MUSE GUI. After this one would be quite capable of devising a GW model by himself and in case of any difficulty this forum helps everyone to resolve them. Alternatively, you can join any paid online modelling course conducted by IHE, Hatari Labs, IAH, AWS, mak gurukul and the likes.
https://water.usgs.gov/ogw/modflow/MODFLOW-2005-Guide/index.html?frequently_asked_questions.htm
Please note that the locations of each head value is not recorded in the output so you need to figure that out from other files such as the discretization file along with the model description. The model description should tell you where the grid is located, the projection used, and the grid rotation, if any.
Typically, initial heads are groundwater heads of the past month or the past year, or the past decade, assuming that the flow was in a steady condition at that time. Your 200m value is just an arbitrary value; however, if one wants to get initial heads for their location, they’d have to assume that the flow was steady in the last month/year/decade and consider the initial heads to be the average of heads in this period. You can insert your wells as points with associated coordinates and elevations. No need for DEM in that case. Then incorporate your pumping pattern into the model.
With regard to initial head, you design your model so that the initial head doesn’t matter. The most common way of doing this is to have a initial steady state stress period. Then all you have to do is make sure none of the initial heads make cells go dry.
Run a steady state model to find the initial heads. Can be compared to the observations. These initial heads are coherent in respect to the model structure. If you use these initial conditions it will be easier to get convergence.
Conductance of the river is obtained by using the dimension (L,W,m) of the river and vertical hydraulic conductivity (Kz) of the river bed (as part of the aquifer). Recharge can be taken as some % of rainfall plus other sources like return flow from irrigation (%) etc in the absence of any specific studies. Both the parameters are subject to change during calibration.
Perform spatial interpolation between your recharge point (wells) over your model grid to get continuous value of recharge.
If you are using the Well package, the well screen area is not part of the input. The only thing you specify is the well flow rate. Also, MODFLOW does not calculate the head inside the well. Instead, it calculates a head for the cell containing the well. That head would typically be different from the head inside the well.
I would strongly recommend to start modelling with ModelMuse, going through all the tutorials/videos in the software homepage. After trying several commercial interfaces, MODFLOW and others, I think this interface is probably the best you can find to learn how MODFLOW works down to the package level. ModelMuse generates comments in the input files that are extremely useful to understand the whole MODFLOW structure. Ideally, before using ModelMuse, reading the MODFLOW-2005 and MODFLOW-NWT manuals, to understand the discretization scheme and boundary conditions conceptualization and parameters, should give you a strong basis to work with the software. Then jump to MF-USG and MF6.
Now for the long rant about SFR and STR.
RC, I think you are referring to the River Package (RIV) which is a reformulated General Head Boundary (GHB, https://water.usgs.gov/ogw/modflow/MODFLOW-2005-Guide/index.html?ghb.htm) and does not route flow. I also think RIV was part of the original MODFLOW. On a funny side note, just about every package is just a reformulated GHB but just adds representative terminology and additional calculations to determine the GHB BHEAD and CONDuctance (for example SFR calculates the stream stage, which becomes the BHEAD and the streambed hydraulic conductivity becomes COND).
The Stream Package (STR, https://water.usgs.gov/ogw/modflow/MODFLOW-2005-Guide/index.html?str.htm) specifies a rectangular stream network and instantaneously routes flow through the network. The STR package did include Stream Observations (https://water.usgs.gov/ogw/modflow/MODFLOW-2005-Guide/index.html?stob.htm) and the HydMod package (https://water.usgs.gov/ogw/modflow/MODFLOW-2005-Guide/index.html?hyd.htm) came out as well. HydMod provided time series output for multiple packages (such as STR/SFR).
Falling back to STR, its formulation was later refined in became the basis of the first release of HEC-RAS. HEC-RAS enhanced the concepts to include multiple bottom geometries and moved the stream depth calculation to the center of the reach (STR estimates stream depth at the start). This led to the rewrite of STR to make Stream Flow Routing (SFR) to bring in the features of HEC-RAS and a lot of additional new features. Along the way there were a lot of enhancements added though applied projects (such as Randall mentioned with advanced diversion options being added).
Later SFR2 came out to include stream bed unsaturated flow and a linkage to UZF. At that time it became trendy to have companion observation packages (for example MNW2 added MNWI, when MNW1 pretty much had the two packages as one), so with SFR2 came the GAGE package (which could be easily obtained from HydMod or in SFR by setting ISTCB2>0 or in MF-OWHM using the database output options, DBFILE).
I am not overly familiar with the MF6 SFR outside of their release documents and skimming through their code, but I can imagine it is quite challenging developing a stream flow routing option that supports structured grids, unstructured and vertices. That is probably why the selected to keep MF6-SFR simpler with rectangular bottoms, but I assume they follow the more modern technique of calculating depth and flow at the mid-point instead of the beginning of the reach.
The next topic are constant heads (CHD, https://water.usgs.gov/ogw/modflow/MODFLOW-2005-Guide/index.html?chd.htm) or better known as Dirichlet boundary conditions. It is a very appealing option due to its simplicity, but outside of classroom examples or trying to reproduce a lab experiment it should never be used. The problem with constant heads is that it fixes the solution with an infinite amount of water. A classic example would be to have a WEL next to a CHD, which would create the illusion of infinite water availability cause the well would just be pulling water from the constant head. If a fixed head is needed it should use the GHB (a Cauchy boundary condition) with a high conductance, then through calibration its value can later be reduced to create a more realistic boundary that is head dependent. For the case of the GHB, the WEL would extract water from the boundary but the rate becomes limited by the GHBs CONDuctance resulting in a head drop. Also, CHD cells are effectively removed from the simulation resulting in the cells hydraulic properties being moot. While GHB is something attached to the cell that provides flow into it, preserving its properties.
Something you may want to skim over is the first 23 pages (43 in the pdf) of this report https://pubs.usgs.gov/tm/06/a60/tm6A60.pdf, which talks a lot about that. I must admit there are a few math mistakes in that report (mostly innocuous stuff, such as the wrong units for Sy and missing an x in ?x). That report was used as textbook for a university course and the professor just let me know. I am hoping that an update will be posted soon.
and last of the last, since I saw Jeremy knocked Fortran, I figured I tease him with a few quotes from my email signature (always good to end a long rant with a laugh). But then I do sleep with a copy of the original IBM Fortran manual under my pillow.
Also, C++ better watch out; I am building a Fortran Standard library that will give it a run for its money. https://code.usgs.gov/fortran/bif
With all that said, any direct solver falls quickly behind the forefront iterative solvers in performance when the simulated grids are as big as we easily build today for many practical problems. Also, if you’re solving a changing water table situation, you’re no longer working with a linear equation (the parameters are now varying with the state solution). This doesn’t mean a direct solver is a poor solver - it just has its place. I actually would recommend it if you have just a few hundred nodes, a few simple BCs and a fixed saturated thickness. BTW, many very good iterative solvers such as ADI, SOR and SIP have also now been largely left behind as our need for handling tremendous complexity and coupled, also-iterating-to-a-solution, “sub models” such as MNW, STR, SFR (and even water table fluctuations and wet and dry cycling if you think about it) has advanced as far as it has. The USGS has made huge advances in iterative solver developments - follow their lead.
So, I agree with Richard - leave DE4 behind - for all but the smallest and simplest MODFLOW applications.
Most versions of MODFLOW all a standalone windows executable (it ends with .exe, such as mf-owhm.exe), so you have to either double click it, run it from the command prompt (cmd.exe), or have a GUI, such as ModelMuse ( https://www.usgs.gov/software/modelmuse-a-graphical-user-interface-groundwater-models ) or the EU’s QGIS-FreeWat ( http://www.freewat.eu/) to run it (which behind the scene just opens a command prompt and runes the executable.
I develop code for MODFLOW-OWHM, so I will use that as an example, but the same procedure works for MODFLOW-2005 or MODFLOW-6. MODFLOW-OWHM info is at: Homepage: https://www.usgs.gov/software/modflow-one-water-hydrologic-flow-model-conjunctive-use-simulation-software-mf-owhm USGS 2020 Report: https://doi.org/10.3133/tm6A60 USGS Git Repo: https://code.usgs.gov/modflow/mf-owhm
If you run from the command prompt, then it is easiest to place a copy of the executable in the same folder as the input files (this makes relative paths easy). If you use a GUI you can always generate the input files and move the exe into that folder and follow the same set of instructions.
What is important to note is that everything is relative to the directory the command prompt has open. For example, this is cmd.exe opened at C:_example (The default location is C:).
An easy method to open the console at a specific windows folder is to just type into the windows explorer url bar cmd as show below. To illustrate running a Modflow example I copied into the folder the input files for the MODFLOW-NWT Seawater Intrusion (swi2ex4sww) example problem.
(this image has the current directory path in the url bar which is C:_example)
(now I have typed cmd and hit enter as show in the window below)
When you run the MODFLOW program it will ask you for the location of the MODFLOW name file (swi2ex4sww.nam). This file specifies the packages in use and the location of their input files. In this case, I am running the exe in the same folder as the input files so there is no need to specify the path for each file nor the name file. Otherwise everything would have to be relative to where the command prompt is currently positioned or specify an absolute path (absolute paths should never be used since they are not portable. One windows an absolute path always includes a drive letter, such as C:)
If you run mf-owhm without any command arguments, then it will ask for the name file or it can be specified directly when running.
So by typing mf-owhm.exe swi2ex4sww.nam will run the program with that specific name file (this has swi2ex4sww.nam as the name file as a command argument).
The following shows the command prompt opened and I ran the mf-owhm.exe without any arguments, so I had to answer the request for a name file (the red circle is what I typed in):
Then either you will get an error message if something does not work or if it runs will see something like this: (Note that that calendar date will only appear if you specify a starting date for the model, in this case I modified the input to specify a starting date of January 2010)
The other way to deal with this is to use the MNW2 package for pumpage as these wells automatically develop a lower pumping rate based on a seepage face estimation as opposed to just arbitrarily ramping down all wells based on a fraction of saturated thickness. We’ve improved this even further in the newest version of USGS Modflow called MF-OWHM.
Give a try with running it with MODFLOW-OWHM, it has a bit more error messages added and if those don’t work has additional debug info. If that does not help, let me know and I am happy to run it in the debugger.
You can just get the MODFLOW-OWHM exe at https://code.usgs.gov/modflow/mf-owhm/-/raw/release/bin/mf-owhm.exe or you can pull the full release (~40mb) at https://code.usgs.gov/modflow/mf-owhm/-/archive/release/mf-owhm-release.zip
Just to let you know there is a new homepage for MODFLOW-OWHM. The first one that I set will be the general page, but the code and compiled binaries will now be located at: https://code.usgs.gov/modflow/mf-owhm
Generally you only need to run UZF if the delay from surface infiltration to saturated groundwater is greater than a time step. Often the lag from infiltration does not affect the overall semi-annual budget, especially considering other model construction errors relative to not catching the time lag.
Most projects that I know of only use UZF if there is a large depth to groundwater (~200m) or if the travel time to groundwater is greater than 30 days (typically for a model with monthly stress periods and weekly time steps).
What you may want to do is give the model a run using MODFLOW-OWHM. We have continued to maintain and patch UZF bugs. If MODFLOW-OWHM does not work and you are comfortable sharing the model, I am happy to run it in the debugger and see if it is a code error (UZF has lots of div/0 errors and negative power errors that I have been slowing fixing in my spare time).
You can pull a the current copy of MODFLOW-OWHM by going to: https://code.usgs.gov/modflow/mf-owhm
and then if you scroll down to the readme, there are direct download links. Or you can just go here: https://code.usgs.gov/modflow/mf-owhm/-/raw/release/bin/mf-owhm.exe