Online Guide to MODFLOW-NWT

1.Download the installation file from the MODFLOW web page.

2.If the file is an .exe file, double-click on it. A dialog box similar to this will appear. Click on the Unzip button.

3.If the file is an .zip file instead of an .exe file, just unzip it.

4.The default location for the MODFLOW-2005 version 1.11 executable is C:\WRDAPP\MF2005.1_11\bin .

1.Read the documentation: .

2.MODFLOW is a command-line program rather than a graphical-user interface program.  All the input for MODFLOW must be prepared in advance in a text editor or a separate graphical user interface.

3.See the Beginner's Guide to MODFLOW for more information.

MODFLOW is a command-line program rather than a graphical-user interface program.  All the input for MODFLOW must be prepared in advance in a text editor or a separate graphical user interface.  When MODFLOW is run, it prompts the user for the name of the Name File and then uses the files listed in the Name File to run the model. The input files for MODFLOW can not be edited by running MODFLOW.

There are a variety of graphical user interfaces for MODFLOW on the market. Many users find the graphical user interfaces make MODFLOW easier to use.

Prepare the input files for MODFLOW. Then proceed using one of the methods below.

Method 1:

Open a command line window.  On Windows XP, you do this by first clicking the Windows "Start" button in the lower left and selecting "Run..." then type "cmd" and click the OK button.  In the command line window, use the "CD" command to change to the directory to the directory that contains the name file for your model.  If you also have a copy of MODFLOW in the same directory as your input files, type the the name of the MODFLOW executable such as "mf2k" or "mf2005".  If you don't have a copy of MODFLOW in the same directory as your input files, type the full path for MODFLOW such as "C:\Wrdapp\mf2k.1_18\bin\mf2k.exe". (If the full path includes any spaces, be sure to enclose the full path in quotation marks.)  MODFLOW will start and prompt you for the name of the name file. Type the name of the name file and pres the Enter key on the keyboard.

Method 2:

Create a text file in the same directory as the input files for the model. On the first line of the file enter the full path for MODFLOW such as "C:\Wrdapp\mf2k.1_18\bin\mf2k.exe" followed by a space and then the name of the name file.  On the second line write the line "pause".  The file might end up looking something like this.

C:\Wrdapp\mf2k.1_18\bin\mf2k.exe MyModel.nam

pause

Save the file.  Then change the file extension of the file to ".bat".  In Windows Explorer, double-click on the file to start MODFLOW.

There are several different versions of MODFLOW available. Check https://water.usgs.gov/ogw/modflow/index.html for the version you want.

This is answered at https://water.usgs.gov/software/.

1.In the Name File, set Ftype for the file in which head or drawdown is to be saved to "DATA" instead of "DATA(BINARY).

2.In the Output Control file, use words instead of numeric codes.

3.Specify the Head Save Format or Drawdown Save Format in the Output Control file.

4.[Optional] include the word LABEL after the format to ensure that each array can be easily identified.

No. It can only be saved in binary format in the USGS version of MODFLOW. Users would have to change the MODFLOW source code and recompile MODFLOW in order to save the cell-by-cell budget file in ASCII format.

However, the some of the cell-by-cell budget terms can be written to the Listing file by setting the budget unit number in the output files to a negative number.  For example, set IDRNCB less than zero in the Drain package.

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

1.ZoneBudget

2.MODPATH

3.GW_Chart

4.ModelMuse

Note that the cell-by-cell budget file must be an unstructured non-formatted file to be read by the above programs. To generate such files with versions of MODFLOW not distributed by the USGS, openspec.inc in the MODFLOW source code may need to be modified prior to compiling MODFLOW.

See also: How can I read data from a binary file generated by MODFLOW?

First of all, mpif.h is only needed to compile a parallel version of MODFLOW-2000.  The serial version of MODFLOW-2000 is not compiled with mpif.h.  To compile the serial version of MODFLOW-2000, use the file para-non.f from the source\serial directory.  To compile the parallel version of MODFLOW-2000 use the files from the source\parallel directory.  One of the files in the source\parallel directory (para-mpi.f) requires mpif.h.  You shouldn't use the files from both the source\serial and source\parallel directories; use one or the other but not both.

If you do wish to compile a parallel version of MODFLOW, you will need to get a copy of mpif.h.  Search the web for it.  One place you may be able to get it is http://tell11.utsi.edu/mpich-1.2.5/include/mpif.h

To enable the parallel-processing capabilities of MODFLOW-2000, an implementation of MPI must first be installed on your computer(s).  MPI software is not distributed by the USGS and must be obtained and installed separately.  The mpif.h file and MPI subroutines referenced in the para-mpi.f file and other locations in the MODFLOW source code will be provided as part of the MPI installation.  After MPI has been installed, use mpif.h and other source-code files provided with the MPI implementation that is installed on your computer(s) when MODFLOW-2000 is compiled with para-mpi.f.  Some implementations of MPI support only certain compilers, so ensure that the MPI implementation you install supports the compiler you will be using to compile MODFLOW-2000.  Please refer to page 203 of USGS Open-File Report 00-184 for additional information.

The convergence criteria such as HCLOSE and RCLOSE in the PCG2 package may be too strict or the number of iterations in the solver may be too small. Adjusting other parameters of the selected solver or changing to a different solver may also be helpful.  For large models, the GMG solver can prove helpful.

If the solver has the capability of printing out additional information about the solution process such as by setting IPRPCG to 1 in the PCG2 package, it can be worthwhile to examine the solution information to gain insight into what is causing the problem.

Use of the wetting capability (first implemented in BCF2 and retained in BCF3, BCF5, LPF and HUF) can result in non-unique solutions because the head in a cell must be higher than some wetting threshold. If a cell starts off wet, it can remain active even if the head drops below the wetting threshold. However, if it starts out dry, it may not be wetted because the head in the neighboring cells may be too low.

Use of the wetting capability can cause serious problems with convergence. You can try to avoid this by several methods.

1.If the drain elevation, drain-return elevation, GHB boundary-head, Reservoir stage, River stage, STR Stream stage, or SFR Stream stage are below the bottom of the cell, try making them above the bottom of the cell.

2.If you know a cell should never become wet, make it an inactive cell rather than a variable head cell.

3.You can adjust the value of the wetting threshold in WETDRY. (Higher is more stable but may be less accurate.)

4.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.

5.You can use IHDWET to determine which equation is used to specify the head in newly wetted cells.

6.You can vary the wetting factor WETFCT.

7.If repeated wetting and drying is a problem and the previous suggestions don't help, consider using the UPW package in MODFLOW-NWT.

8.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.

9.You can choose a different solver. The SIP and PCG2 solvers will work with the wetting capability. The SOR solver (not included in MODFLOW-2005 and MODFLOW-LGR) doesn't work well with the wetting capability. Note that cells can not change between wet and dry during the inner iterations of the PCG2 solver. For models with large numbers of cells, the GMG (not included in MODFLOW-2000 or MODFLOW-NWT) solver may work better.

10.In models with large numbers of cells, using a double-precision version of MODFLOW may help.

11.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.)

12.When using the PCG2 solver, you can set DAMPPCG to a value between 0 and 1.

13.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 and Evapotranspiration Segments packages, check the ET flux and extinction depth which together control the conductance of evapotranspiration cells.

14.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.

15.If recharge or evapotranspiration are used, make sure that they are applied to the correct locations. See NRCHOP, NEVTOP, and NETSOP.

16.If you have any unconfined or convertible layers, try making them confined to see if that will allow the model to run to completion. If it does, examine the results and see if it has any unrealistic results such as heads that are much too high or too low. If it does, try to identify the source of the problem and correct it and run the model again. When the model runs without producing unrealistic results, you can try converting layers back to unconfined or convertible layers. Unreasonably high or low heads might be calculated if high specified fluxes are specified for cells with low hydraulic conductivities. For example, a recharge rate that is higher than the hydraulic conductivity is probably unreasonable.

17.In transient models, shorter time steps may help.

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.

Look for cells or blocks of cells that are completely cut off from the rest of the model either because they were set up that way or because cells around them have gone dry. Such blocks of cells may receive recharge that has nowhere to go.

If the Lake package is being used, it may be worth checking whether the value of THETA is appropriate.

It can be difficult to get steady-state models without any specified-head boundaries to converge because there may be an imbalance between the amount of water entering and leaving the system.

MODFLOW requires that all input use the same length and time units. If you used the wrong units, that may manifest as a problem with convergence.

Some programs that can read data from binary files generated by MODFLOW include the following.

1.Hydpost (included with MODFLOW-2000 and MODFLOW-2005)

2.ZoneBudget

3.MODPATH

4.GW_Chart

5.MODFLOW-GUI

6.ModelMuse

7.MFBIN2RASTER and CBC2RASTER

Note that the binary files 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.

In addition, Graphical User Interface programs for MODFLOW may be able to read such binary files.

Binary files generated by MODFLOW are of several types.  These include:

1.Head and Drawdown files (See CHEDFM and CDDNFM in Output Control.)

2.Heads and flows interpolated to hydrogeologic units (See IOHUFHEADS and IOHUFFLOWS in the HUF2 package.)

3.Data related to subsidence or compaction (See the IBS, SUB, and SWT Packages.)

4.Cell-by-cell flow files (See ILPFCB in the LPF package and similar variables in other packages.)

5.Zeta values saved by the SWI2 package

6.Files saved by the SWR process. The formats for these files are not described here.

If you need to write code to read the binary files, the following descriptions of how the data is saved may help.

Array Data (#1 to #3)

Flow Data (#4 and #5)

Use the COMPACT BUDGET option in the Output Control file.

Example input files are included with MODFLOW.  They are in the "data" folder for MODFLOW-2000 or the "test-run" folder for MODFLOW-2005.

Darcy's law states that

Q = -KA(h1 - h0)/(X1 - X0)

Where Q is the flow (L3/T)

K is the hydraulic conductivity (L/T)

A is the area perpendicular to flow (L2)

h is head (L)

X is the position at which head is measured (L)

Conductance combines the K, A and X terms so that Darcy's law can be expressed as

Q = -C(h1 - h0)

where C is the conductance (L2/T)

The flow packages calculate the conductance between cells using some average hydraulic conductivity of the cells, the area of the interface between the cells and the distance between the cell centers. Some of the head-dependent boundary conditions, require the user to specify the conductance.  

See also: Mehl, S.W. and Hill, M.C., 2010, Grid-size Dependence of Cauchy Boundary Conditions used to Simulate Stream-Aquifer Interactions: Advances in Water Resources. Volume 33, Issue 4, Pages 430–442

If the disk on which the files are being written is formatted as FAT or FAT32, the maximum allowed file size is 4 GB minus 1 byte. Larger files can be created if the file system in NTFS. See http://technet.microsoft.com/en-us/library/bb456984 for more information.

There are several possible reasons why this might occur.

1.The file is an input file and the file doesn't exist (or at least doesn't exist at a location where MODFLOW can find it).

2.The binary file exists but it has an incompatible format. For example, if you had a binary file created by MODFLOW-2000 version 1.0,  MODFLOW-2000 version 1.2 and all subsequent versions of MODFLOW would probably not be able to read it because the binary format changed in MODFLOW-2000 version 1.2.

3.You compiled MODFLOW yourself and even though the file is an output file, MODFLOW can't create it because the code specified in the file openspec.inc is not correct for your compiler.

Cases 2 and 3 are related and deserve a bit more discussion.

Prior to MODFLOW-2000 version 1.2, MODFLOW used only standard FORTRAN statements to open all files. The advantage of this was that anyone could compile and run MODFLOW. However, there was a major disadvantage too; versions of MODFLOW compiled with different compilers would produce binary files with different formats. That meant that if you wanted to use that binary file, the program that read the file would have to be compiled with the same compiler as was used to compile MODFLOW. For example, if you wanted to use ZONEBUDGET on a binary cell-by-cell file produced by MODFLOW, you would have to compile ZONEBUDGET with the same compiler used to compile MODFLOW. I once heard an explanation of this from one of the compiler manufacturers. According to him, the FORTRAN standard said what programs had to do but not how to do it and in the case of writing binary files, each compiler manufacturer had to figure out how they were going to write binary files themselves and different manufactures came up with different solutions.

In MODFLOW-2000 version 1.2, developers of MODFLOW came up with a solution. The compiler manufactures all allowed programmers to write unstructured non-formatted files without any of the extra information that would normally distinguish the binary files of one compiler from another. However, to do that required the use of non-standard FORTRAN statements. Furthermore, you had to have different non-standard FORTRAN statements for different compilers. That's where the file openspec.inc comes in. This file is used to set some variables used in OPEN statements. By setting these variables to the correct values for a particular compiler, it is possible to have MODFLOW generate unstructured non-formatted files that will be useable by programs compiled with different compilers. The cost of this is that when you compile MODFLOW you need to check openspec.inc to make sure that it is correct for your compiler.

The "STREAM FLOW OUT" budget term can be saved to a cell-by-cell budget file by the Stream (STR) package. It represents the surface water flow out of a stream reach. This is different from other terms normally saved in cell-by-cell budget files which represent either flows among groundwater cells or flows between groundwater cells and boundary features. Note that "STREAM FLOW OUT" represents the total surface water flow out of a reach and not the net flow out of a reach.

There are a number of things you can do to make MODFLOW run faster without changing the simulated values.

•Limit the amount of data that is printed or saved.

oWhen reading data with the Array Reading Utility Modules, set IPRN to a negative number to prevent the array from being printed to the listing file.

oUse the Output Control Option to limit what output data is printed or saved.

oMany packages have options similar to IWELCB in the Well Package that allow you to suppress saving the computed flux term.

oMany packages, such as the Well Package have a NOPRINT option that can be used to suppress printing of the input data.

oLarge numbers of gages in the SFR, LAK, and UZF packages can slow down MODFLOW

•If your model is using virtual memory when running, adding more memory can speed up the model.

•MODFLOW prints lots of data to the listing file so sometimes printing that data can be a bottleneck in the model. Using a faster storage medium such as a solid-state drive instead of a hard drive can help.

•A faster processor can help.

•A computer with multiple processors can help if you will be running other programs at the same time as MODFLOW. However, at the time this was written (Oct. 2014) MODFLOW was a single-threaded application so the benefit of adding additional cores is limited.

•Modify the source code of MODFLOW to make it a multiple-treaded application. The following publications are examples of this approach.

oAccelerating groundwater flow simulation in MODFLOW using JASMIN-based parallel computing. http://www.ncbi.nlm.nih.gov/pubmed/23600445

oA parallel PCG solver for MODFLOW. http://www.ncbi.nlm.nih.gov/pubmed/19563427, http://igg.cas.cn/xwzx/yjcg/200912/W020091211345917673978.pdf

oUse of general purpose graphics processing units with MODFLOW. http://www.ncbi.nlm.nih.gov/pubmed/23281733

oParallelisation of a Finite Difference Code for Modelling Ground Water Flow http://www2.eng.cam.ac.uk/~mspg1/paper-1.htm

omodflow-2005-upcg https://github.com/jdhughes-usgs/modflow-2005-upcg

oA Method for Parallelizing MODFLOW http://igwmc.mines.edu/conference/abstracts/23_Ji.pdf

When you compile MODFLOW, you need to make sure that the code in the file OPENSPEC.inc is correct for your compiler and that it matches what is included in MP6Openspec.inc in the MODPATH source code or the version of OPENSPEC.inc that is part of the ZONEBUDGET source code. Then you need to compile your own version of MODPATH or ZONEBUDGET.

In the version of MODFLOW distributed by the USGS, OPENSPEC.inc sets a number of variables that will cause binary files to be written without anything to mark the end of records or to mark the beginning or end of files. With standard Fortran, such markers are included. However, the Fortran standard does not specify what those markers should be. Because of that, different compiler manufacturer have not been consistent about what markers are used. Typically, this results in binary files being generated by a program compiled by one compiler being different from the binary files generated by that same program if the program is compiled by a different compiler. Because of this, binary files are generally incompatible between programs compiled with different compilers. By removing the markers, it is possible to make the files readable by programs written by different compilers. Unfortunately, there isn't a standard way to achieve that goal. (I.e. there isn't a standard way to violate the Fortran Standard!). Hence, OPENSPEC.inc has several versions of some lines and the person compiling the program must choose the right version for their compiler. The comments in OPENSPEC.inc identify which code is appropriate for several popular compilers.

Consider the following geologic cross section with two layers.

When these geologic units are simulated in MODFLOW, the heads will be calculated at a number of nodes in each layer as shown below.

Each of these nodes represents a certain volume of their respective aquifer. These volumes are called cells. Those volumes can be represented in at least two ways. In illustration A below, the volume represented by each node is shown with a tilted bottom whereas in B, the volume is shown with a flat bottom. The advantage of method A is that it makes clear which cells are neighbors of other cells. Flow only occurs between neighboring cells. However, it shows varying elevations for the top of bottom of individual cells. That isn't true. Each cell has a single top elevation and a single bottom elevation. These elevations are defined in the Discretization file.

Method B shows only a single elevation for each cell and method B is the most common way of depicting cells in a cross section of a MODFLOW model. However, beginners frequently ask whether flow occurs through the lines shown in red in the figure below. The short answer is "No"*. Flow only occurs among neighboring cells within layers or between cells that are immediately adjacent vertically. Thus, there can be flow to a maximum of six other cells from any individual cell. The advantage of method A is that it makes that relationship clear. Neither of these methods is ideal because both misrepresent the mathematical model to a certain extent. The best method to use will depend on the ideas you wish to communicate and your audience.

*There is one exception to the explanation given above. In MODFLOW-OWHM, the Horizontal-Flow Barrier package can be used to simulate flow between cells that are adjacent in the horizontal direction but that are in different layers. This capability can be used to simulate faults that have moved different geologic units next to one another in the horizontal direction.

"Virtual memory" is used when your computer does not have enough physical memory to run the model so some data that would normally be in memory is saved in the hard drive instead. You need to have enough hard drive space to store the extra data. Another reason you might get this message is that you are running a 32-bit version of MODFLOW and the model requires more than 4 gigabytes of memory. If that is the case, you need to run a 64-bit version of MODFLOW. There are 64-bit versions of MODFLOW-NWT and MODFLOW-OWHM distributed by the USGS. However, there are only 32-bit versions of MODFLOW-2005 distributed by the USGS at the time of this writing (MODFLOW-2005 version 1.11). If you need a 64-bit version of MODFLOW-2005, you may need to compile it yourself.

Yes.

The heads printed by the Head-Observation Package are interpolated from the calculated heads in surrounding cells. See the Head-Observation Package for details. The heads printed in the listing file or a head output file are the heads calculated at the cell center.

1.The HUF2 - Hydrogeologic-Unit Flow Package is designed to address this problem.

2.When using other flow packages, the pinched out portion of the layer is set to a small portion of the thickness of of the underlying or overlying layer and is given the properties of the underlying or overlying layer. In the illustration below, A represents the conceptual model in which the gray middle layer pinches out. B shows how a portion of the bottom layer is assigned to the middle layer but assigned the properties of the bottom layer.

3.In MODFLOW 6, you can designate the pinched out portion of a layer as "vertical flow-through" cells when using the DIS or DISV packages.

MODFLOW does not simulate solute transport. However, the output from MODFLOW can be used in solute transport programs such as MT3DMS or MT3D-USGS.

In MODFLOW-2000, MODFLOW-2005, and other versions of MODFLOW based directly on them, specified head boundaries can never be turned off. In these versions of MODFLOW, all specified head boundaries, no matter in what package they are specified, modify the internal IBOUND array by making the the IBOUND value for cells containing specified head boundaries negative. There is no provision for converting a negative IBOUND value to a positive value. It is possible to use the calculated heads from one model as the initial heads in another model and that is one way to circumvent the limitation of converting specified heads cells to active cells. However, care should be taken that the file containing the heads for the second or subsequent models contains only the heads for the correct time step and stress period because MODFLOW will read the first set of heads in the file not the final set of heads in the file. In MODFLOW 6, specified head boundaries can be turned off. See the MODFLOW 6 input instructions for details.

MODFLOW is in the public domain. It may be downloaded and used by anyone for free.

MODFLOW is in the public domain. See the disclaimer at https://www.usgs.gov/about/organization/science-support/office-science-quality-and-integrity/guidance-disclaimer#5

In some situations, the USGS can provide training to governmental agencies with a cooperative agreement with the USGS; agencies can contact their cooperating USGS office for additional information.