MODFLOW design

[ChristinaB]

Question from BR: What are the limitations of the current MODFLOW model. The first version will be in steady state mode and for yearly averages.
What is the spatial resolution is, vertical and horizontal?
@brubash - I think this should be in the contract, but let's write up a clear description here. What I understand is that the limit of the existing data across the entire domain is limiting the dynamics. I think Gil is concerned that the spatial distribution of the uncertainty would be underrepresented by running a finer scale dynamic model. I think we should keep exploring how to address this issue, either by recommending more data be collected where necessary, or doing better at representing the uncertainy, even with higher resolution models.

[ChristinaB]

@brubash
Let me know if this Q&A doc answers this question.

[ChristinaB]

Email from Bert Rubash 5/20/2019

The GitHub NooksackWaterBudget master now has code to import the steady
state, irrigated, non irrigated or both irrigated and non irrigated
MODFLOW output at the appropriate calendar times. It also has Python
code to process the file from Jessica and write input files for TopNet.

To run one of those four requires the input file to be in the folder
with other TopNet files, requires having the appropriate pre-processor
flag defined in topnet.hh, and then a fresh build of TopNet. The
relevant section of topnet.hh is:

#define ZBAR_OUT
// Comprehensive zbar input. Leave ZBAR_IN commented-out if running with
MODFLOW input (below)
//#define ZBAR_IN

// Selective zbar input
// For 2019 Whatcom County model, un-comment only one (or none) of the
following four defines.
//#define SS
//#define IRR
//#define NIRR
#define MODFLOW_TRANSIENT

#ifdef MODFLOW_TRANSIENT
#define IRR
#define NIRR
#endif

I tested all of the changes except the MODFLOW_ALL with both a Bertrand
run and a WRIA1 run. A Python script to plot depth to water table
outputs is also in the GitHub master branch. I will be away from this
computer until late this afternoon, but I will check e-mail.

[ChristinaB]

Email from Jess 5/17/2019

1. Please confirm that -1 is no data. We will not update depth to water table in those drainages.

A DTW of -1 feet indicates that the groundwater model is simulating land surface flooding in that drainage. In other words, the model is predicting a water table elevation that is higher than the land surface in that grid cell. This largely occurs in areas with rapid topographic transitions. In cells with flooding, I set DTW to -1. We have limited observations in the areas where the flooding occurs to constrain the groundwater model. We think a reasonable approach would be to represent these drainages with a 0 DTW, or whatever your shallowest input is.

2. ID management mess: In the attached file we added columns for our model which uses TopnetID and DrainageID -- your table introduces a new numbering system named DRAINID.

Where did this come from? Katherine - can you help verify we are applying the correct DTW to the correct location?

The attached workbook summarizes the “DrainageID” and “POU_ID” identifiers provided to SSPA within the Water Use workbooks. These identifiers were specified either for WRIA1 or the Bertrand Creek subdrainages, exclusively. SSPA implemented an additional identification to allow a unique ID across the groundwater model domain. The first three columns of the attached workbook reflect the AESI-provided identifiers. The fourth column is the identifier developed by SSPA. Please use the attached spreadsheet to determine corresponding identifiers (e.g., “Drainage ID” vs. “POU_ID” vs. “GW MODEL DrainID”, and drainage names).

3. My current suggestion is that we update our model as follows.. (truncated remainder of original question)

The DTW_IRR_FT column represents the SAT model simulated water levels at the end of irrigation season (Sept. 30). The DTW_NONIRR_FT column represents the SAT model simulated water levels at the end of non-irrigation season (Mar. 31). If possible, we recommend using results associated with these dates (Sept. 30 and Mar. 31).

[ChristinaB]

DrainID.xlsx

[ChristinaB]

In topnet.hh the model is set to read in the depth to water (DTW) table file from both irrigation and non-irrigation MODFLOW runs. The MODFLOW annual average irrigation DTW level is used to reset Topnet subsurface on Oct 1. The MODFLOW annual average non-irrigation DTW level is used to reset Topnet subsurface on April 1.

Code in topnet.hh
//#define SS
//#define IRR
//#define NIRR
#define MODFLOW_TRANSIENT

#ifdef MODFLOW_TRANSIENT
#define IRR
#define NIRR
#endif

Code in calv46sn.cpp

#ifdef IRR
if (timeinfo->tm_mon == 8 && timeinfo->tm_mday == 30) { // September 30th
cout << " Updating depth to water table. timestep " << setw(5) << istep << " " << asctime(timeinfo);
char cr;
ifstream zbarInFile("zbar_irr.dat");
if (!zbarInFile) {
cerr << "Failed to open zbar_irr.dat\n";
exit(1);
}

#ifdef NIRR
if (timeinfo->tm_mon == 2 && timeinfo->tm_mday == 31) { // March 31st
cout << " Updating depth to water table. timestep " << setw(5) << istep << " " << asctime(timeinfo);
char cr;
ifstream zbarInFile("zbar_nirr.dat");
if (!zbarInFile) {
cerr << "Failed to open zbar_nirr.dat\n";
exit(1);
}

#ifdef SS
if (timeinfo->tm_mon == 0 && timeinfo->tm_mday == 1) { // January 1st
cout << " Updating depth to water table. timestep " << setw(5) << istep << " " << asctime(timeinfo);
char cr;
ifstream zbarInFile("zbar_ss.dat");
if (!zbarInFile) {
cerr << "Failed to open zbar_ss.dat\n";
exit(1);
}