Minor bug in GAG package for writing lake information

[langevin-usgs]

A minor problem with the GAG Package output was tracked down based on a user’s feedback. The problem occurs when writing output for lakes when the lake package input specified RNF as a negative value (which is then used as a flag; this is a rarely used option) and OUTTYPE = 1, 3, or 4. The gage output file incorrectly included the value of the flag rather than the actual computed value of runoff to the lake. This problem was corrected by changing several lines of code in Subroutine SGWF2GAG7LO (in the gwf2gag7.f file). The model user does not need to do anything differently. Note that all model calculations were correct (and not affected by the fix) and that correct values for runoff to a lake were always printed in the main output (listing) file.

The updated (fixed) version of the GAG Package subroutines is attached.

gwf2gag7.txt

[langevin-usgs]

Additional information from Scott Boyce:

It was brought to my attention about MNW2 not working correctly. At first I thought it was an OWHM only issue, but it looks like its an issue inherited from MF-2005 and NWT. I just wanted to pass along what I did for fixes to MNW2. They mostly are for partial penetration and when Ztop/Zbotm are not fully penetrating.

There are four issues.

---

The first issue is that MNW2 does not calculate conductance correctly on the first time step that a well appears in the simulation. This is noticeable in the attached excel document, which shows OWHM having a spike on the first time step of each stress period, and MF-2005 and NWT having it for the first time step the well becomes active from being inactive (that is when WELLID is specified in the RP input section). OWHM has the reoccurring spikes because at the start of each stress period I initialize all variables back to zero, which caused the error to occur again. This issue occurs because there are several checks for mnwnod(14,:) .NE.0 or COND.NE.0, which is not set until the second solver iteration, but for CONFINE layers, it is only calculated on the first solver iteration.

---

The second issue is that for CONFINE layers with MNW2 wells that have Partial Penetration (PP) enabled do not calculate its effect other than for the first solver iteration after the first time step. The problem is that PP is a function of flow in or out of the well's nodes (Q), so it should be updated every solver iteration. Since Q changes every solver iteration, the PP effect will be different. Its an easy fix to just set irecalc=1 if the well has PP in SUBROUTINE SMNW2COND. Note that this fix actually may also implicitly fix the first problem.

---

The third one, and least important, is that the LOSSTYPE is NONE is not implemented correctly in "function cel2wel2". When the LOSSTYPE is NONE then the conductance should be set to a very large number to mimic the WEL package.
The following code calculates the large CWC:

      cel2wel2=1.0D3*((Txx*Tyy)**0.5D0)/thck

but then a few lines later has the following code:

    cel2wel2 = A + B + C 
    if ( cel2wel2>verysmall )cel2wel2 = 1.000000D0 / cel2wel2

whose result is unknown because A is set to zero and B and C have their result from the past WEL that set them to a value. (typically A, B, and C are set to zero, so this would result in a CWC=0)

---

The fourth issue is that NWT applies its smoother to the MNW2 conductance:

cel2wel2 = cel2wel2*smooth2(h,dc)

This seems unnecessary because MNW2 already takes into account smoothing the conductance as the cell dewaters, so this actually doubly applies the smoothing.

---

While this is not an error I wanted to point out that Fortran 2018 Standard declared COMMON blocks obsolete, so compilers may start dropping support or the ability to compile with them. The reason I brought this up is because the Partial Penetration (PPC) subroutines are the only part of MODFLOW that makes use of COMMON, so this may need to be changed to a model global variable at one point. I was going to rewrite the functions to use the newer standards, but after about an hour I realized it was going to take more time than I have at the moment to rewrite all the PPC functions. Someone may want to tackle that at some point.