Online Guide to MODFLOW

Frequently Asked Questions

Hide Navigation Pane

Frequently Asked Questions

 Previous topic Next topic No directory for this topic Expand/collapse all hidden text  

Frequently Asked Questions

 Previous topic Next topic Topic directory requires JavaScript JavaScript is required for expanding text JavaScript is required for the print function  
A.hmtoggle_plus1        How do I install MODFLOW?
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.

Modflow2005Installation

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 .
B.hmtoggle_plus1        How do I get started with MODFLOW?
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.
C.hmtoggle_plus1        How do I use MODFLOW to open a MODFLOW model so I can edit it.

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.
D.hmtoggle_plus1        How do I run MODFLOW on Windows

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.
E.hmtoggle_plus1        Where can I get MODFLOW?

There are several different versions of MODFLOW available. Check https://water.usgs.gov/ogw/modflow/index.html for the version you want.
F.hmtoggle_plus1        Does the USGS provide support for MODFLOW?

This is answered at https://water.usgs.gov/software/.
G.hmtoggle_plus1        What do I need to do to have MODFLOW save heads or drawdowns in ASCII format?
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.
H.hmtoggle_plus1        Can the cell-by-cell budget file be saved in ASCII format?

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.
I.hmtoggle_plus1        How can I read data from the cell-by-cell budget file?

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.

See also: How can I read data from a binary file generated by MODFLOW?
J.hmtoggle_plus1        I need the file mpif.h to compile MODFLOW-2000 and it isn't included in the source code.  Where can I get it?

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 https://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.
K.hmtoggle_plus1        My model hasn't converged. What can I do?

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 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 solver may work better.
10.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.)
11.When using the PCG2 solver, you can set DAMPPCG to a value between 0 and 1.
12.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.
13.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.
14.If recharge or evapotranspiration are used, make sure that they are applied to the correct locations. See NRCHOP, NEVTOP, and NETSOP.
15.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.
16.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.
L.hmtoggle_plus1        How can I read data from a binary file generated by MODFLOW?

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

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

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.

The array data can be either in single-precision or double-precision format.  There is no data field that indicates which format is used.  Instead, you will need to try both and see which one works.

First read the following variables in order

KSTP: the time step number, an integer, 4 bytes.

KPER: the stress period number, an integer, 4 bytes.

PERTIM: the time in the current stress period, a real number, either 4 or 8 bytes.

TOTIM, the total elapsed time, a real number, either 4 or 8 bytes.

DESC, a description of the array, 16 ANSI characters, 16 bytes.

NCOL, the number of columns in the array, an integer, 4 bytes.

NROW, the number of rows in the array, an integer, 4 bytes.

ILAY, the layer number, an integer, 4 bytes.

Next come a list of NROW x NCOL real numbers that represent the values of the array.  The values are in row major order.  Each value in the array occupies either 4 or 8 bytes depending on whether the values are in single- or double-precision.

After reading one set of values, start over with KSTP. Continue until reaching the end of the file.

The following is a list of possible values for DESC.  The list may be incomplete and is subject to change.  Check the values passed to the subroutine ULASAV in the MODFLOW source code for other possible values.

'            HEAD'

'        DRAWDOWN'

'      SUBSIDENCE'

'      COMPACTION'

'   CRITICAL HEAD'

'     HEAD IN HGU'

'NDSYS COMPACTION'

'  Z DISPLACEMENT'

' D CRITICAL HEAD'

'LAYER COMPACTION'

' DSYS COMPACTION'

'ND CRITICAL HEAD'

'LAYER COMPACTION'

'SYSTM COMPACTION'

'PRECONSOL STRESS'

'CHANGE IN PCSTRS'

'EFFECTIVE STRESS'

'CHANGE IN EFF-ST'

'      VOID RATIO'

'       THICKNESS'

'CENTER ELEVATION'

'GEOSTATIC STRESS'

'CHANGE IN G-STRS'

One way to determine whether the file has been saved with single- or double-precision, is to read the file up through DESC using either single- or  double-precision numbers and see if the value read for DESC matches one of the above values.

The data can be either in single-precision or double-precision format.  There is no data field that indicates which format is used.  Instead, you will need to try both and see which one works.

First read the following variables in order

KSTP: the time step number, an integer, 4 bytes.

KPER: the stress period number, an integer, 4 bytes.

DESC, a description of the array, 16 ANSI characters, 16 bytes.

NCOL, the number of columns in the array, an integer, 4 bytes.

NROW, the number of rows in the array, an integer, 4 bytes.

NLAY, the number of layers in the array, an integer, 4 bytes.  NLAY can be a negative number in which case the absolute value of NLAY is the number of layers in the array.

If NLAY is greater than zero, a 3D array of real numbers follows NLAY.  The number of values is NCOL x NROW x NLAY. To read it, you can use a loop over the layers that contains a loop over rows that contains a loop over columns.

If NLAY is less than zero, the compact format is being used.  (However, in some older versions of MODFLOW, data from the HUF package was saved using the compact format but with a positive value of NLAY.) With the compact format, read the following:

ITYPE, a value indicating how the data is stored, an integer, 4 bytes.

DELT, the length of the current time step, a real number, either 4 or 8 bytes.

PERTIM: the time in the current stress period, a real number, either 4 or 8 bytes.

TOTIM, the total elapsed time, a real number, either 4 or 8 bytes.

If ITYPE = 5 read NVAL which is the number of values associated with each cell.  Otherwise, assume that NVAL = 1.

If NVAL > 1, read (NVAL - 1) copies of CTMP.  CTMP is a description of the additional value associated with each cell. CTMP is 16 ANSI characters, 16 bytes.

If ITYPE = 2 or 5 read NLIST which is the number of cells for which values will be stored. NLIST is an integer, 4 bytes.

Next we read the values associated with the cells. The format used to read the values is determined by ITYPE.

•If ITYPE = 0 or 1, read a 3D array of values.
•If ITYPE = 2 or 5, read a list of cells and their associated values.
•If ITYPE = 3, read a 2D layer indicator array followed by a 2D array of values to be assigned to the layer indicated by the layer indicator array.
•If ITYPE = 4 read a 2D array of values associated with layer 1.

If ITYPE = 0 or 1, read a 3D array of real numbers.  The number of values is NCOL x NROW x Abs(NLAY). To read it, you can use a loop over the layers that contains a loop over rows that contains a loop over columns. Each value is either 4 or 8 bytes depending on whether the file is saved with single- or double-precision data. Remember that NLAY may be a negative number.

If ITYPE = 2 or 5 check whether NLIST is greater than zero. If it is greater than zero, compute NRC as NROW x NCOL. then in a loop from 1 to NLIST read first ICELL (an integer, 4 bytes) and then NVAL values (real numbers either 4 or 8 bytes each).  ICELL is a cell index, the layer, row and column can be determined from ICELL as follows:

Layer = (ICELL-1)/NRC + 1

Row = ( (ICELL - (Layer-1)*NRC)-1 )/NCOL +1

Column = ICELL - (Layer-1)*NRC - (Row-1)*NCOL

Duplicate ICELL values may occur in the list.  For example if two wells occur in the same cell, the cell will be listed twice: once for each well.

If ITYPE = 3, first read NROW*NCOL integer values (4 bytes each).  These are layer indicators in row major order.  Then read NROW*NCOL real-number values (either 4 or 8 bytes each) in row major order.  The position of each value in the list indicates its row and column.  The corresponding layer indicator indicates which layer to which the value applies.

If ITYPE = 4, read NROW*NCOL real-number values (either 4 or 8 bytes each) in row major order.  All the values apply to the top layer (layer 1).  A value of zero applies to all the remaining cells.

After reading one set of values, start over with KSTP. Continue until reaching the end of the file.

To determine whether the files are saved with single- or double-precision real numbers, you need to read the flow values for at least two flow terms.  The description of the first flow term should be one of the first four items in the list below.  The second flow term should be one of the last four items in the list below. The flow terms should be read using the information described above but using either single (4 byte) or double (8 byte) real numbers when reading the data.

'         STORAGE'

'   CONSTANT HEAD'

'FLOW RIGHT FACE '

'FLOW FRONT FACE '

'FLOW LOWER FACE '
M.hmtoggle_plus1        What do I need to do to have the elapsed time saved in the binary budget file?

Use the COMPACT BUDGET option in the Output Control file.
N.hmtoggle_plus1        Are example input files for MODFLOW available?

Example input files are included with MODFLOW.  They are in the "data" folder for MODFLOW-2000 or the "test-run" folder for MODFLOW-2005.
O.hmtoggle_plus1        What is conductance?

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
P.hmtoggle_plus1        Why does MODFLOW stop when the output files gets too big?

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 https://technet.microsoft.com/en-us/library/bb456984 for more information.
Q.hmtoggle_plus1        MODFLOW stops with an error message when it tries to open a DATA(BINARY) file

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.
R.hmtoggle_plus1        What does the "STREAM FLOW OUT" budget term represent?

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.
S.hmtoggle_plus1        How can I make MODFLOW run faster?

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.
•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. https://www.ncbi.nlm.nih.gov/pubmed/23600445
oUse of general purpose graphics processing units with MODFLOW. https://www.ncbi.nlm.nih.gov/pubmed/23281733
oParallelisation of a Finite Difference Code for Modelling Ground Water Flow https://www2.eng.cam.ac.uk/~mspg1/paper-1.htm
oA Method for Parallelizing MODFLOW https://igwmc.mines.edu/conference/abstracts/23_Ji.pdf
T.hmtoggle_plus1        Why can't I get get MODPATH or ZONEBUDGET to run with a version of MODFLOW that I compiled myself?

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.

U.hmtoggle_plus1        What is the best way to represent a cross section through a MODFLOW model with varying layer elevations?

Consider the following geologic cross section with two layers.

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.

Two geologic layers each with a row of nodes in their centers.

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.

A. Cells represented as polygons with vertical sides but slanted tops and bottoms.

B. Cells represented as rectangles with flat tops and bottoms.

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.

When cells are show as rectangles, there can be overlap between cells in different layers. The overlapped area is shown in red.

*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.
V. hmtoggle_plus1        What can I do about an error message saying MODFLOW is "Out of Virtual Memory"?

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

W.hmtoggle_plus1        Is the edge of the grid a no-flow boundary by default?

Yes.
X.hmtoggle_plus1        The simulated heads printed by the Head-Observation Package are different from the ones printed to the listing file or to a head output file. Why is there a difference?

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.
Y.hmtoggle_plus1        In my conceptual model, I have a layer that pinches out. How can I simulate that in MODFLOW?
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.
Pinchout
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.
Z.hmtoggle_plus1        How do I simulate solute transport with MODFLOW?

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