The MODFLOW Data Model is an extension to the Simulation portion of the Arc Hydro Groundwater (AHGW) data model and is used to store complete MODFLOW simulations in an ArcGISgeodatabase. The data model consists of a set of tables for archiving MODFLOW model data. Having the model in the database makes it possible to utilize the mapping and plotting capabilities of ArcGIS. It also facilitates the use of tools, such as those provided in MODFLOW Analyst, for populating the MODFLOW package tables using data from the Arc Hydro groundwater and surface water data models. It also provides an archival tool for models facilitating permissions, check-in/check-out capabilities, and web services.
The MODFLOW Data Model generally uses the same naming convention for variables defined by MODFLOW. The meanings of all these variables are only summarized here. Refer to the MODFLOW documentation for a full description.
The AHGW data model includes a Simulation component that facilitates the storage of simulation models (grids, meshes, and associated data) in a geodatabase. The simulation component uses polygons, points, and multi-patches to represent 2D and 3D cells and nodes. The MODFLOW data model consists of a series of tables and relationships associated with the simulation component. The data model is based on MODFLOW 2000 and includes all of the standard MODFLOW packages. It will gradually be expanded to include supplemental packages.
For some of the MODFLOW packages, including the Global Package, the LPF package, and the Recharge package, the input data associated with the package is primarily one or more arrays of data representing cell-by-cell values. These arrays are represented in the data model using tables indexed by a cell ID. In the case of the stress packages, the package input data are typically not defined using an array corresponding to the entire grid. Rather, the data are associated with a subset of the grid cells. For example, the input to the well package is a list of well instances where each well lists the IJK indices of the corresponding cell and the pumping rate. For transient simulations, one set of values is listed for each stress period (simulation interval). The input to these packages is stored in tables which include the cell IDs, the stress period ID, and the attributes associated with the particular stress package (water level, conductance, etc.). In either case, the resulting tables can be joined with Cell2D, Cell3D, Node2D, and Node3D features to display the locations of the stress package objects in the model domain.
Cell and Node Features
The MODFLOW Data Model is an extension of the Arc Hydro Groundwater Simulation Feature Dataset. The MODFLOW data is stored primarily in a set of tables described below and the Cell and Node features of the Simulation Feature Dataset are used to generate map layers in ArcGIS in order to visualize MODFLOW models. The features are also used to perform spatial queries such as interpolating hydraulic conductivity values to the K array in the LPF package. When used with the MODFLOW Data Model, one additional field is added to each of the cell and node features in order to support joins based on MODFLOW cell ids. An IJ field is added to the Cell2D and Node2D features and an IJK field is added to the Cell3D and Node3D features. The resulting feature classes contain the following fields (in addition to the point and polygon fields):
In the MODFLOW input files, cells are identified by a combination of three integers representing the row, column, and layer indices of the cell (I, J, K). Since joins can only be accomplished using a single field, it is necessary to generate an integer field corresponding to a unique IJK combination. Furthermore, some MODFLOW input arrays are fundamentally 2D in nature (Evapotranspiration, Recharge, etc.) and require an integer identifier corresponding to a unique IJ combination. To facilitate joins and queries related to the MODFLOW data, the data model includes a CellIndex table containing the following fields:
The IJ and IJK fields of the CellIndex table is populated from the I,J,K values by starting at a value of one for the cell corresponding to I=1, J=1, K=1, and looping through the cells in the grid row-by-row within each layer, and incrementing the index. The IJ index ordering is repeated within each layer. The following example indicates how this numbering would be accomplished in both the C and VB languages:
// C Syntax// numI, numJ, numK = number of cells in the I, J and K directionsintindex1=1;for(intK=0;K<numK;++K){intindex2=1;for(intI=0;I<numI;++I){for(intJ=0;J<numJ;++J){IJK=index1;IJ=index2;++index1;++index2;}}}
' Visual Basic Syntax' numI, numJ, numK = number of cells in the I, J and K directionsindex1=1ForK=1TonumKindex2=1ForI=1TonumIForJ=1TonumJIJ=index2IJK=index1index1=index1+1index2=index2+1NextJNextINextK
For example, consider a MODFLOW grid with three rows, four columns, and two layers (numI=3, numJ=4, numK=2). The CellIndex table for this grid would be as follows:
CellIndex Table
I
J
K
IJ
IJK
1
1
1
1
1
1
2
1
2
2
1
3
1
3
3
1
4
1
4
4
2
1
1
5
5
2
2
1
6
6
2
3
1
7
7
2
4
1
8
8
3
1
1
9
9
3
2
1
10
10
3
3
1
11
11
3
4
1
12
12
1
1
2
1
13
1
2
2
2
14
1
3
2
3
15
1
4
2
4
16
2
1
2
5
17
2
2
2
6
18
2
3
2
7
19
2
4
2
8
20
3
1
2
9
21
3
2
2
10
22
3
3
2
11
23
3
4
2
12
24
It is also helpful to view the IJ and IJK indices on a layer-by-layer basis (IJ values shown in red, IJK values in blue):
K=1
J=1
J=2
J=3
J=4
I=1
1
1
2
2
3
3
4
4
I=2
5
5
6
6
7
7
8
8
I=3
9
9
10
10
11
11
12
12
K=2
J=1
J=2
J=3
J=4
I=1
1
13
2
14
3
15
4
16
I=2
5
17
6
18
7
19
8
20
I=3
9
21
10
22
11
23
12
24
The Cell2D and Node2D features include an IJ field and the Cell3D and Node3D features include an IJK field where the IJ and IJK fields are populated using the same strategy used to populate the CellIndex table. The MODFLOW data is stored in a separate series of tables (described below) and the tables containing cell-by-cell data include either an IJ or IJK field depending on whether it is a 2D array or a 3D array. The MODFLOW tables are then joined to the cell and node features using the CellIndex table. For example, a map layer illustrating hydraulic conductivity values with polygons could be generated by first joining the IJK field of the LPFProperties table to the IJK field of the CellIndex table. The CellIndex.IJ field of the resulting temporary table would then be joined to the IJ field Cell2D feature class. This type of join can be easily generated in one step using the “Make Query Table” geo-processing tool in the MODFLOW Analyst. The values associated with individual grid layers in the resulting map layer can be displayed using a definition query (“CellIndex.K = 1, CellIndex.K=2, etc.). For 2D arrays or for models with only one grid layer, the CellIndex table can be bypassed and the IJ or IJK field of the MODFLOW tables can be joined directly with the IJ field of the Node2D and Cell2D features since the IJ and IJK values are identical for K=1. Similarly, joins can be performed directly between IJK-based tables and the Cell3D and/or Node3D features. Map layers of MODFLOW data associated with cell and node features can be symbolized and toggled on/off independently from other features in the TOC window in ArcMap and ArcScene.
Sometimes it is necessary to derive I, J, and K values from the IJ or IJK indices, or vice versa. The following C and Visual Basic code shows how to get the I and J indices given an IJ value:
// C Syntax// '%' is the modulus operatorI=((IJ-1)/numJ)+1;J=(((IJ-1)%numJ)+1;
' Visual Basic Syntax' 'Mod' is the modulus operator, 'Int' converts a decimal to an integerI=Int((IJ-1)/numJ)+1J=((IJ-1)ModnumJ)+1
Likewise, to get the I, J, and K indices from an IJK value:
// C SyntaxI=(((IJK-1)/numJ)%numI)+1;J=((IJK-1)%numJ)+1;K=((IJK-1)/(numI*numJ))+1;
It should be noted that with this strategy, if the grid is modified by adding or deleting rows or columns, all tables which include IJ or IJK fields will need to be modified by renumbering the IJ and IJK values according to the new configuration. We will eventually provide tools to automate this process.
Groups
Tables that are related to each other are put together in a group and, in the diagram, are displayed together in a colored box. For example, three tables are used to represent the LPF package and these are grouped together in the data model. Groups typically are associated with MODFLOW packages but not necessarily. For example, the Output group does not correspond to any MODFLOW package.
Global Settings / Name File
The MDFGlobals table is used to store global variables that are not associated with a particular MODFLOW package or MODFLOW input file, but which are useful for managing the MDM. Currently the only field in this table is the model version. Additional fields will be added as the need arises. The Version field is used to indicate which MODFLOW version is represented in the data model (2000, 2005, etc.). This makes it possible to support multiple versions of the data model. Currently the only versions the data model supports are MODFLOW 2000 and 2005.
The Global Settings group also includes the NameFile table.
File type ("Ftype" in MODFLOW documentation, but "Ftype" has other meanings in Arc Hydro). FileType coded value domain.
Nunit
Long Integer
Fortran unit number
Fname
Text
Name of the file
Use
Short Integer
Flag indicating whether or not the file is being used. Only when this flag is true should the file be included in the name file. Uses TrueFalse coded value domain.
Discretization (DIS)
One of the main input files to MODFLOW is the Discretization (DIS) File. It defines the spatial and temporal discretization used in the model. Some of the information in the DIS file is represented by the Cell2D feature class. The rest comes from the following tables.
The DISVars table contains variables associated with the DIS file. The RefTime variable is not written to the DIS file. It is used by tools associated with the MDM to generate date/time values representing the beginning and ending of each stress period in the Stress Periods table. A geo-processing tool exists that computes these values and adds two columns (Start, End) to the table when necessary.
The DELRC table is used to store the widths (discretization) of the rows and columns. While this information could be derived from the geometry of the Cell2D polygons, it is convenient to store it explicitly in a table.
The StressPeriods table stores information on stress periods and time steps. The SPID field defines the stress period order and must begin with 1 and go to N where N is the number of stress periods. Other tables in the data model which refer to stress periods reference the stress period ID.
The DISLayers table contains variables defined on a layer-by-layer basis.
The TopElev and BotmElev tables are used to store the top and bottom elevations for the cells of the grid. For the TopElev table, only the cells in the top layer should be included. The top elevations for the remaining layers are assumed to be equivalent to the bottom elevations of the above layer as defined by the BotmElev table. Thus, the BotmElev table should include the bottom elevations for all cells in the grid. The BotmElevCBD field is used to store the bottom elevation of confining beds, if appropriate.
Stress period number used to define the order, e.g. 1, 2, 3
PERLEN
Double
Period length
NSTP
Long Integer
Number of time steps
TSMULT
Double
Time step multiplier
SSorTr
Text
Steady state or transient. SteadyState coded value domain
RIV_ITMP
Short Integer
Use previous flag
WEL_ITMP
Short Integer
Use previous flag
DRN_ITMP
Short Integer
Use previous flag
GHB_ITMP
Short Integer
Use previous flag
CHD_ITMP
Short Integer
Use previous flag
RCH_INRECH
Short Integer
Use previous flag
RCH_INIRCH
Short Integer
Use previous flag
EVT_INSURF
Short Integer
Use previous flag
EVT_INEVTR
Short Integer
Use previous flag
EVT_INEXDP
Short Integer
Use previous flag
EVT_INIEVT
Short Integer
Use previous flag
MNW1_ITMP
Short Integer
Use previous flag
STR_ITMP
Short Integer
Use previous flag
STR_IRDFLG
Short Integer
Use previous flag
STR_IPTFLG
Short Integer
Use previous flag
SFR_ITMP
Short Integer
Use previous flag
SFR_IRDFLG
Short Integer
Use previous flag
SFR_IPTFLG
Short Integer
Use previous flag
LAK_ITMP
Short Integer
Use previous flag
LAK_ITMP1
Short Integer
Use previous flag
LAK_LWRT
Short Integer
Use previous flag
DRT_ITMP
Short Integer
Use previous flag
ETS_INETSS
Short Integer
Use previous flag
ETS_INETSR
Short Integer
Use previous flag
ETS_INETSX
Short Integer
Use previous flag
ETS_INIETS
Short Integer
Use previous flag
ETS_INSGDF
Short Integer
Use previous flag
Basic Package (BAS6)
The Basic Package is represented using the tables below. The Options and HNOFLO values are stored in the BASVars table as a text string and a double. The IBOUND and STRT arrays are stored in the Basic table. The IBOUND array is used to define the active/inactive status of the grid and the STRT array is used to define the starting heads. Mulipliers for the IBOUND and STRT arrays are stored in the BasicArrayMult table.
MODFLOW has two options for specifying output control: using words or using numeric codes. The MDM stores the options in tables patterned after the numeric codes option. The tool which converts MODFLOW models to geodatabases handles both options. Furthermore, the tools which export from the geodatabase to native MODFLOW files can be designed to export either format.
Not all of the output options are supported, in order to make the tables manageable.
The Output Control data consist of two parts: four global flags (IHEDFM, IDDNFM, IHEDUN, IDDNUN) and a set of flags that are specified for each time step. The global flags are stored in the OCVars table.
Time step data is stored in the OCTS table. Note that there is no INCODE value in the OCTS table. It is assumed that INCODE=0, indicating that all layers are treated the same way for a given time step. This allows the further assumption that there is one record for each output time step.
The OCTS table is entirely dependent on the records in the StressPeriods table and the number of time steps (NSTP) per stress period. Any tools used to manage the MDM will need to update the records in the OCTS table any time the StressPeriods table is edited.
Many of the MODFLOW packages include a flag at the top of the file indicating whether or not the cell-by-cell flow terms for the package should be output to the CCF file. These flags are stored in a single table called the CBFlags table.
The data for the Block-Centered Flow Package are stored in a combination of variables and tables. The IBCFCB value is stored in the CBFlags table in the Output control group.
The BCFVars table stores various variables associated with the BCF package.
The BCFLayers table is used to store layer-by-layer variables. In the MODFLOW text input files, the Ltype flag consists of two digits: one representing the mean (LAYAVG) and one representing the layer type (LAYCON). These two digits are combined to a single flag in the input file but are stored separately in the MDM. There should be one record in the table for each layer in the grid.
The BCFProperties table stores the aquifer property arrays associated with the BCF package. Note that the data in these arrays are applicable to some layers, but not to others, depending on the layer type (Ltype). The users of the MDM (and the applications that operate on the MDM) will need to ensure that the fields of the records in the table are populated for the cells in the appropriate layers.
wetting threshold and flag to indicate which neighboring cells can cause cell to become wet
Layer-Property Flow (LPF) Package
The LPF Package is handled similarly to the BCF package. The ILPFCB value is stored in the CBFlags table in the Output control group. Variables associated with the LPF package are stored in the LPFVars table. Layer-based variables associated with the LPF package are stored in the LPFLayers table. The LPF aquifer property arrays are stored in the LPFProperties table. As is the case with the BCF package, the contents of the “arrays” depend on the layer types defined by the LAYTYP flag in the LPFLayers table. Some arrays are only required for certain layer types. The VKCB field is used to store the vertical conductivity for quasi-3d confining beds as defined by the LAYCBD table in the DIS section. The IJK field in records associated with VKCB values is the cell in the layer just above the confining bed.
Most of the commonly-used stress packages in MODFLOW follow a simple strategy. The cells associated with a given type of stress are identified and an input entry is made for each instance in a list in the package input file. In some cases, multiple entries are made for a given cell (three wells in a single cell, for example). The River, Well, Drain, General Head Boundary, Constant-Head Boundary, and Horizontal Flow Barrier packages follow this format. Each of these packages are represented in the data model using a variable and a table. For each package, the cell-by-cell flow flag (IRIVCB, IWELCB, IDRNCB, etc.) are stored in the CBFlags table in the Output control group. The remaining data associated with the package are stored in a series of tables, one per package. Each record in the tables corresponds to an instance of the given stress at a particular cell for a particular stress period. The SourceID field is used to associate records with the spatial features from which they were derived. The SourceID represents the HydroID of the point, polyline, or polygon in the Framework component of the Arc Hydro database that was used to construct the record in the table. This field is only used when the tables are constructed using a tool in Arc Hydro GW. For the case where pre-built MODFLOW files are imported from another database, the SourceID values should all be Null.
Factor used to calculate conductance from the parameter value
LayR
Long Integer
Return flow flag
RowR
Long Integer
Row number of the recipient cell
ColR
Long Integer
Column number of the recipient cell
Rfprop
Double
Return-flow proportion
SourceID
Long Integer
HydroID of the feature that the source comes from
LinearScale
Double
Length from the begining of a polyline to the center of the polyline segement within the MODFLOW cell
Array-Based Stress Packages
Two of the more common stress packages are array-based: the Recharge Package (RCH) and the Evapotranspiration Package (EVT). While the individual records are quite similar, both packages require some additional variables. Furthermore, both packages require input that are based on rows and columns, but are not necessarily tied to a particular layer. One approach to handle this would be to store IJ indices. However, it is necessary to do joins with the Cell2D and Node objects to display values. Thus, a IJ field is used with each record where the IJ index for the corresponding cell in the top layer is stored.
Recharge Package (RCH)
The cell-by-cell flow flag (IRCHCB) for the Recharge Package (IRCHCB) is stored in the CBFlags table in the Output control group. The remaining data are stored in the three tables below. The RCHVars table holds the NRCHOP variable (associated with a coded value domain). This variable defines the recharge option. For NRCHOP=1 or 2, a single recharge value (RECH) is stored for each IJ combination. For NRCHOP=3, an additional array of integer values (IRCH) is required. The RECH and IRCH values are stored in the RCHArrays table. The IRCH field will likely be rarely used. The RCHArrayMult table is used to store array multipliers.
The Evapotranspiration package is similar to the Recharge Package. The cell-by-cell flow variable (IEVTCB) is stored in the CBFlags table in the Output control group. The remaining data are stored in the three tables below. If NEVTOP=1, the IEVT field is ignored. If NEVTOP=2, the IEVT field is used.
Flag for reusing or reading the extinction water content
Solver Packages
Representing solver package input in the MDM is a fairly simple process. None of the packages require any type of array- or list-based input; all input is in the form of a set of variables. For each solver package there is one table with one field for each of the variables used in the package. Each table contains only one record.
Beginning with MODFLOW 2000, the MODFLOW input files allow for the definition of parameters. Parameter definitions can be complex and representing parameters in a GIS database is challenging. The following design is an attempt to allow complex parameter definitions, yet provide a simple option for the most routine cases. The tables are related in multiple ways but those relationships are not shown here. Refer to the diagram.
Standard MODFLOW parameter type from PARTYPE coded value domain. If "Custom", then the TableCode and FieldCode fields are used to define the parameter type.
TableCode
Text
The name of the table containing the parameter. Ignored unless PARTYPE is "Custom".
FieldCode
Text
The name of the field in the table identified by TableCode containing the parameter. Ignored unless PARTYPE is "Custom".
Parval
Double
Parameter value used for forward runs
Keyval
Double
Key value in the field identified by PARTYPE (or TableCode and FieldCode) that identifies the location of the parameter. The value should be one that does not normally occur in the data (e.g. -99999)
B
Double
"Starting" value used in sensitivity and inverse runs
BL
Double
Min parameter value
BU
Double
Max parameter value
BSCAL
Double
Scaling factor for the SEN and PES processes.
LN
Short Integer
Flag indicating whether or not the parameter should be log-transformed during the SEN and PES processes
ISENS
Short Integer
Flag indicating whether or not the parameter should be analyzed during SEN or PES processes
LogInterp
Short Integer
Flag whether or not to use log interpolation for pilot points
LogMinVal
Double
Minimum value when using log interpolation for pilot points
Tied
Text
Used by PEST. The name of another parameter used to link one parameter to another. The tied parameter is automatically adjusted along with the parent parameter by multiplying the parent parameter value by the Parval value of the tied parameter.
Source
Short Integer
Flag indicating how data values for the parameter will be populated. ParamSource coded value domain.
Simple mathematical operators used to combine multiplier arrays
The main table is the Params table. Parameters can be classified into two groups: 1) list-based parameters (well, drain, river, etc.) 2) array-based parameters (K, Ss, Sy, recharge, et, etc.). The strategy for managing the two types of parameters differs slightly. Another type of parameter exists that is non-native to MODFLOW: pilot points associated with array-based parameters.
List-Based Parameters
In the input files for the list-based stress packages, parameters are defined by providing a list of parameter definitions at the top of the file, above the main list of stress items and including a list of parameter names in the main list with each stress period group. Since this approach includes some redundancy and since it is difficult to directly duplicate in a database setting, a different strategy is used based on the concept of “key values”. The Keyval field in the Params table represents a value in the identified data column that identifies the location of the parameter. A value for the Keyval field should be selected such that it would not normally occur in the data column. For example, if the Keyval=-800 is used to identify river conductance, a query could be performed on this value to find all river stress objects with this value. The tools developed for the MDM are able to use this type of query to write out the MODFLOW files in the native format. Furthermore, a similar tool is able to read a MODFLOW package file in the native format and convert it to the Keyval format when importing the file. Using the Keyval approach also simplifies the process of parameterizing the model input in the GIS. The user simply assigns selected key values in the appropriate fields using standard editing tools. No special or additional tools are required.
For parameters associated with conductance values, the Condfact field is used to scale the parameter value for use with the conductance term. A similar approach is used with the Hydchr and Factor terms in the HFB table.
Array-Based Parameters
Array-based parameters are more complicated than list-based parameters. Array-based parameters can be defined in three ways: using key values, using clusters, and using pilot points.
Key Values. The Keyval field is used to identify the records in the data column corresponding to the parameter locations, similar to the process described above for list-based parameters. For most cases, this simple approach is sufficient. The only case where it is not sufficient is where you want to define a parameter that uses multiple zone arrays which cover distinct portions of the grid. When using the Key Value approach, only the Params table is necessary.
Clusters. The Clusters approach mimics the method used in the MODFLOW input files. Clusters are associated with Parameter Instances, even if a parameter only has a single instance. Clusters are defined using zone arrays and multiplier arrays. All of the tables, besides the Params and Pilot points tables, exist solely to support the clusters approach.
It should be noted that the entries in the Multipliers and Zones tables are referenced by IJ index. These arrays stored in this table are defined on a layer-by-layer basis with respect to the MODFLOW grid. Thus, each entry in the array is associated with an IJ index, independent of model layer (K). Going with an IJ index as opposed to two separate I, J fields simplifies the process of joining the tables with the Cell2D features. The IJ index for a particular entry corresponds to the cell in the top layer of the grid, regardless of which layer the Mulplier or Zone array is associated with. A GP tool exists that creates a temporary copy of the table and populates the table with I and J fields when needed.
Transient Array-Based Parameters
Transient array-based parameters are used with the Recharge and ET packages. In this case, MODFLOW utilizes “parameter instances” to define the parameters in the input file. Each parameter can be defined by multiple instances. Each parameter instance has a name and one or more clusters. Each parameter instance/cluster combination is linked to one or more stress periods. The ParInstances table contains the list of parameter instances.
Pilot Points
Pilot points allow one to define a distribution of values within an array by specifying parameter values at selected XY locations (pilot points) and interpolating to a zone of cells within a model layer. The Keyval field is used to identify which cells in the specified array are to be included in the pilot point interpolation. The PilotPts table is used to store the list of pilot points. Pilot points are organized into groups using the ParamID. The SourceID field could be used to represent the HydroID field of the associated point in a point layer from which the pilot point set was created. The Parval, and ISENS fields supersede the similarly named fields in the Params table. The weights associated with each pilot point are defined using a multiplier array. A tool will exist that displays the final paramter values based on the pilot point data.
Observations
Beginning with MODFLOW 2000, an Observation Process was provided in MODFLOW that allows the user to input head and flow observations. Simulated equivalents are then automatically computed by MODFLOW, from which residuals can be computed. This is an essential part of any type of calibration exercise. Both head and flow observations can be transient and head observations are allowed to span multiple layers. Flow observations are supported for the GHB, DRN, RIV, and CHD packages. This list will be expanded as more stress packages are added to the data model.
Portion of the simulated gain or loss in this cell that is included in the total simulated gain or loss for this cell group
The OBSVars table is used to store individual variables related to observations. The OUTNAM and ISCALS variables are written to the OBS file. The TOMULT* and EV* variables are written to the HOBS, GBOB, DROB, RVOB, and CHOB files.
The HOB table is used to store the locations of the head observations. The HOBLayers table is used to store a list of layers associated with each observation. In the MODFLOW input file, a list of layers is only provided when there are multiple layers. However, the table is used for all cases (even when there is only one layer) in the interest of simplicity. The layers are stored in the HOBLayers table. The HOBTimes table is used to store the head measurements. For each head observation location, there may be multiple head observations at different points in time. Once again, the table is used even for cases with a single value in the interest of simplicity.
The FLOB table is used to store the flow observations. Each record in this table corresponds to an observation at a particular time defined by the IRESFP and TOFFSET variables. All types of flow observations are stored in the same table and are distinguished using the FLOBType field. The FLOBFactors table is used to identify the entries in the associated stress package table that correspond to the given flow observation. The manner in which the factors are associated with the entries in the stress package file follows the same method as outlined in the MODFLOW file formats. This method relies on the ordering of the items in the list. As a result, it typically makes most sense for the tools associated with these packages to build the entries for both the stress package tables and the flow observations tables at the same time.
The variance-covariance weight matrix option (WTQ array) is not supported for flow observations in this version of the MDM.
SEN and PES Processes
The tables associated with the SEN and PES processes are shown below. The data associated with the Sensitivity process are stored in two places: 1) the parameter variables (BSCAL, LN, and ISENS) are stored in the Params table, and 2) the remaining variables are stored in the SEN table. The PES data are all stored in the PES table. Lines 5-10 in the PES file are not supported. It is assumed that NPNG=0, IPR=0, and MPR=0.
Native MODFLOW output consists of four general types:
Head and drawdown files. Binary files listing the computed head and drawdown values grouped by time step (indexed by stress period and time step number). The drawdown file represents the computed head minus the starting head.
Flow budget files. Binary files listing the cell-by-cell flow terms grouped by time step. This includes three flow numbers for each cell representing flow in each of the axis directions. It also includes set of values for each stress type (RIV, DRN, WEL, etc.).
Head and flow file (HFF). This is the binary file produced by MODFLOW for use with the MT3D family of contaminant transport codes. It includes both the head and flow data.
Miscellaneous text output files. MODFLOW produces various text output files including the LST and GLOBAL files.
File format such as ASCII or binary. OutputFormat coded value domain
Compress
Text
Flag indicating if the file is compressed and, if so, what type of compression is used. "", "zip", "tar" etc. Only used if the file is stored in the File field as a blob
File
Blob
The file stored as a Blob, or null if the file is not stored in the geodatabase
The OutputHead, OutputDrawdown and OutputFlow tables are used to store the head, drawdown, and cell-to-cell flow output for each cell for each time step. The flow values come from the compact budget file, which also contains flow values for the stress packages.
Since the output for a single MODFLOW simulation can be quite large, it may not be practical or desirable to keep the OutputHead, OutputDrawdown and OutputFlow tables populated at all times. In such cases, a geo-processing tool could be used to parse through the files listed in the OutputFiles table to populate temporary tables for the head and flow solution. Alternatively, geo-processing tools for post-processing could be designed to read directly from the binary MODFLOW output files.
In a typical modeling project, dozens, if not hundreds or thousands of model runs are performed. Each run represents a different combination of model inputs and/or grid configuration. While not all of these runs need to be archived, it is useful to archive many of the model runs for future reference or so that one can revisit and update an earlier model run. With the MDM described in this document, model runs could be archived simply by copying the entire simulation feature dataset (including Cell2D, Node, and the MDM tables) for each model run. Each simulation feature data set could be stored in a separate geodatabase to simplify the duplication process.
While duplicating a geodatabase is a simple and effective strategy, it could result in massive storage requirements for large models. Two models runs could be identical except for a single record in a table and yet the entire geodatabase would be duplicated. Fortunately, ArcGIS provides a powerful tool for managing multiple model runs without wasteful duplication of data. This tool is called “versioning” and is described in the following documents:
With a versioning strategy, a modeler would first set up a complete model and then turn on versioning and create a new “version”. This initiates the use of a pair of “adds” and “deletes” tables where changes to the database are recorded. In other words, any modifications made to the database by the user are recorded internally in the adds and deletes tables. However, the user continues to directly interact with and edit the database in a normal fashion. The layering of the adds and deletes tables is performed automatically and hidden from the user. Multiple versions can be created and the user can switch back and forth between versions using a simple interface. Versions can be deleted or merged with the original version as desired.
Other Model Types
It is anticipated that in the future the MDM will be expanded to include other models and utilities in the MODFLOW family including MODPATH, ZONEBUDGET, MT3DMS, RT3D, SEAM3D, PHT3D, SEAWAT, etc. Each of these models will share some data with MODFLOW but will require additional tables. As the new models are added to the MDM, the shared tables will be identified and names selected for the new tables that avoid confusion. Linkages will also be identified between models when appropriate.
Limitations
In order to model MODFLOW data in the form of a relational database some simplifications were required. Here is a brief summary of the main limitations and unsupported features of the current version of the MDM.
Only MODFLOW 2000 and 2005 supported (not MODFLOW-LGR etc).
Several packages aren't supported (STR, SFR2 etc.).
Some of the options in the Output Control package aren't supported.
The variance-covariance weight matrix option (WTQ array) is not supported for flow observations.
Lines 5-10 in the PES file are not supported and it is assumed that NPNG=0, IPR=0, and MPR=0.
LAK3 package (v2.0+) - Stages table does not include constituent data for use with MOC3D. i.e., CLAKE(1..NSOL). LAKRates does not include MOC3D solute concentrations.
Versions
1.0 - The initial model as it was when MODFLOW Analyst became available in February, 2009
2.0 - Include LAK3, STR1, SFR2, HUF2, MNW1 packages, and support for MODFLOW 2005.
