From 2b9b14bf74e5f2612dc68a3fd7bde486157b5cee Mon Sep 17 00:00:00 2001 From: langevin-usgs Date: Tue, 6 Feb 2024 16:57:13 -0700 Subject: [PATCH] docs(release): update release notes (#1587) * docs(release): update release notes * fine tuning of release notes and minor changes to IDP section in mf6io. * add Scott Boyce to CITATION.cff --- CITATION.cff | 5 ++ doc/ReleaseNotes/develop.tex | 7 +- doc/mf6io/framework/processing_of_input.tex | 71 +++++++++++---------- 3 files changed, 44 insertions(+), 39 deletions(-) diff --git a/CITATION.cff b/CITATION.cff index 2b38284daa0..6f2774cd4b5 100644 --- a/CITATION.cff +++ b/CITATION.cff @@ -58,6 +58,11 @@ authors: alias: w-bonelli affiliation: U.S. Geological Survey orcid: https://orcid.org/0000-0002-2665-5078 +- family-names: Boyce + given-names: Scott E. + alias: ScottBoyce + affiliation: U.S. Geological Survey + orcid: https://orcid.org/0000-0003-0626-9492 - family-names: Banta given-names: Edward R. affiliation: U.S. Geological Survey diff --git a/doc/ReleaseNotes/develop.tex b/doc/ReleaseNotes/develop.tex index 9f398792507..05253619fd4 100644 --- a/doc/ReleaseNotes/develop.tex +++ b/doc/ReleaseNotes/develop.tex @@ -39,13 +39,12 @@ \item This release contains a fix for a longstanding issue related to the use of AUXMULTNAME and time series. Previous release notes included the following description of a known issue: \textit{``The AUXMULTNAME option can be used to scale input values, such as riverbed conductance, using values in an auxiliary column. When this AUXMULTNAME option is used, the multiplier value in the AUXMULTNAME column should not be represented with a time series unless the value to scale is also represented with a time series.''} With this release, the Input Data Processor (IDP) is now used to read stress package input files, and the limitation with AUXMULTNAME and time series no longer applies. % \item xxx % \item xxx - % \item xxx \end{itemize} \underline{ADVANCED STRESS PACKAGES} \begin{itemize} - \item Added functionality to support zero values for each grid dimension when specifying the CELLID for SFR reaches that are not connected to an underlying groundwater grid cell. For example, for a DIS grid a CELLID of 0 0 0 should be specified for unconnected reaches. Warning messages will be issued if NONE is specified for unconnected reaches. Specifying a CELLID of NONE will eventually be deprecated and will cause MODFLOW 6 to terminate with an error. - \item Added functionality to support specification of a DNODATA (3.0E+30) BEDLEAK value for LAK package connections to identify lake-GWF connections where conductance is solely a function of aquifer properties in the connected GWF cell and lakebed sediments are assumed to be absent. Warning messages will be issued if NONE is specified for LAK package connections. Specifying a BEDLEAK value equal to NONE will eventually be deprecated and will cause MODFLOW 6 to terminate with an error. + \item Added functionality to support zero values for each grid dimension when specifying the CELLID for SFR reaches that are not connected to an underlying groundwater grid cell. For example, for a DIS grid a CELLID of 0 0 0 should be specified for reaches with no connection to a groundwater cell. Warning messages will be issued if NONE is specified for the CELLID of an unconnected reach. Specifying a CELLID of NONE will eventually be deprecated and will cause MODFLOW 6 to terminate with an error. + \item Added functionality to support specification of a DNODATA (3.0E+30) BEDLEAK value for LAK package connections. This DNODATA value is used to identify lake-GWF connections where conductance is solely a function of aquifer properties in the connected GWF cell. In this case, the lakebed sediments are assumed to be absent and all resistance to flow is assumed to be within the GWF cell. Warning messages are now issued if NONE is specified for LAK package connections. Specifying a BEDLEAK value equal to NONE will eventually be deprecated and will cause MODFLOW 6 to terminate with an error. \item SFR diversion would not be updated if the outflow of its upstream reach is zero. If diversion was not zero in the previous stress period, it would report mass balance error in the SFR budget. This bug was fixed by always updating the diversion. % \item xxx \end{itemize} @@ -59,7 +58,7 @@ \underline{EXCHANGES} \begin{itemize} - \item A model budget error would occur when a constant-head cell in one model had a direct connection to an active cell in another model. For the model budget to be calculated correctly a new term called ``FLOW-JA-FACE-CHD'' was added to the GWF model budget. This term is only included in the table when the GWF Model is connected to another GWF Model using a GWF-GWF Exchange. + \item A model budget error would occur when a constant-head (CHD) cell in one model had a direct connection to an active cell in another model. For the model budget to be calculated correctly a new term called ``FLOW-JA-FACE-CHD'' was added to the GWF model budget. This term is only included in the budget table when the GWF Model is connected to another GWF Model using a GWF-GWF Exchange. Additionally, the CHD budget calculation for a very specific (and rare) configuration was also incorrect. The incorrect budget calculation occurred when the following conditions were met: (1) a GWF model was connected to another GWF model with a GWF-GWF Exchange; (2) the model as well as the Exchange had the XT3D option enabled, and (3) the model was configured with a CHD cell that is either an Exchange cell, i.e. a cell that is part of the EXCHANGEDATA block, or a cell directly connected to such an Exchange cell. The size of the error depends on the degree of anisotropy around the particular CHD cell and shows up as a discrepancy in the volume budget table reported in the GWF list file. The program has been updated with the correct budget calculation. % \item xxx % \item xxx \end{itemize} diff --git a/doc/mf6io/framework/processing_of_input.tex b/doc/mf6io/framework/processing_of_input.tex index 81dbfeb71d2..6af3f1a933b 100644 --- a/doc/mf6io/framework/processing_of_input.tex +++ b/doc/mf6io/framework/processing_of_input.tex @@ -1,58 +1,59 @@ An effort is underway to process program input early in program runtime, before the simulation is created, in a general way that is not dependent on any given component. This capability is called the \mf Input Data Processor (IDP). Components that have been updated to use IDP no longer directly read or process file inputs but instead access input data from internally managed memory locations. -\subsection{Supported components} +\subsection{Supported Components} -A specific set of \mf components has been updated in the current version to use the Input Data Processor, as shown in Table~\ref{table:idmsupported}. Two integration steps have been taken for each file type listed in the table. First, IDP has been updated to support the reading and loading of variable input data for the component. File types listed in the table, each previously read and processed by the component, are now processed by IDP. Second, the component itself has been refactored to retrieve input from managed memory locations in a predictable way. Components and associated file types shown in table~\ref{table:idmsupported} are described in more detail in later sections of this document. +A specific set of \mf components has been updated in the current version to use the IDP routines, as shown in Table~\ref{table:idmsupported}. Two integration steps have been taken for each file type listed in the table. First, IDP has been updated to support the reading and loading of variable input data for the component. File types listed in the table, each previously read and processed by the component, are now processed by IDP. Second, the component itself has been refactored to retrieve input from managed memory locations in a predictable way. Components and associated file types shown in table~\ref{table:idmsupported} are described in more detail in later sections of this document. \begin{table}[H] -\caption{IDP integrated components} +\caption{Components and subcomponents that are read using Input Data Processor (IDP) routines} \small \begin{center} -\begin{tabular*}{\columnwidth}{l l l l} +%\begin{tabular*}{\columnwidth}{l l} +\begin{longtable}{p{6cm} p{4cm}} \hline \hline -\textbf{Component Type} & \textbf{Subcomponent Type} & \textbf{Component} & \textbf{File Type} \\ +\textbf{Component / Subcomponent} & \textbf{File Type} \\ \hline -SIM & NAM & SIM/NAM & mfsim.nam \\ -GWF & NAM & GWF/NAM & GWF name file \\ -GWT & NAM & GWT/NAM & GWT name file \\ -GWF & CHD & GWF/CHD & CHD6 \\ -GWF & DIS & GWF/DIS & DIS6 \\ -GWF & DISU & GWF/DISU & DISU6 \\ -GWF & DISV & GWF/DISV & DISV6 \\ -GWF & DRN & GWF/DRN & DRN6 \\ -GWF & EVT & GWF/EVT & EVT6 \\ -GWF & EVTA & GWF/EVTA & EVT6 \\ -GWF & GHB & GWF/GHB & GHB6 \\ -GWF & IC & GWF/IC & IC6 \\ -GWF & NPF & GWF/NPF & NPF6 \\ -GWF & RCH & GWF/RCH & RCH6 \\ -GWF & RCHA & GWF/RCHA & RCH6 \\ -GWF & RIV & GWF/RIV & RIV6 \\ -GWF & WEL & GWF/WEL & WEL6 \\ -GWT & DIS & GWT/DIS & DIS6 \\ -GWT & DISU & GWT/DISU & DISU6 \\ -GWT & DISV & GWT/DISV & DISV6 \\ -GWT & CNC & GWT/CNC & CNC6 \\ -GWT & DSP & GWT/DSP & DSP6 \\ -GWT & IC & GWT/IC & IC6 \\ -EXG & GWFGWF & EXG/GWFGWF & GWF6-GWF6 \\ -EXG & GWFGWT & EXG/GWFGWT & GWF6-GWT6 \\ -EXG & GWTGWT & EXG/GWTGWT & GWT6-GWT6 \\ +SIM/NAM & mfsim.nam \\ +GWF/NAM & GWF name file \\ +GWT/NAM & GWT name file \\ +GWF/CHD & CHD6 \\ +GWF/DIS & DIS6 \\ +GWF/DISU & DISU6 \\ +GWF/DISV & DISV6 \\ +GWF/DRN & DRN6 \\ +GWF/EVT & EVT6 \\ +GWF/EVTA & EVT6 \\ +GWF/GHB & GHB6 \\ +GWF/IC & IC6 \\ +GWF/NPF & NPF6 \\ +GWF/RCH & RCH6 \\ +GWF/RCHA & RCH6 \\ +GWF/RIV & RIV6 \\ +GWF/WEL & WEL6 \\ +GWT/DIS & DIS6 \\ +GWT/DISU & DISU6 \\ +GWT/DISV & DISV6 \\ +GWT/CNC & CNC6 \\ +GWT/DSP & DSP6 \\ +GWT/IC & IC6 \\ +EXG/GWFGWF & GWF6-GWF6 \\ +EXG/GWFGWT & GWF6-GWT6 \\ +EXG/GWTGWT & GWT6-GWT6 \\ \hline -\end{tabular*} +\end{longtable} \label{table:idmsupported} \end{center} \normalsize \end{table} -\subsection{Scope of change} +\subsection{Scope of Change} The Input Data Processor introduces transparent changes that are beyond the scope of this document. Input logging differences, however, are readily apparent when comparing to earlier versions of \mf. These differences are primarily related to timing as input files processed by IDP are read before the simulation has been created. Logging appears in the simulation log (mfsim.lst) in part because simulation models and their associated listing files do not exist at the time when input is read. In addition, input logging reflects only what was read and loaded to memory as further processing and use is deferred to the simulation components that the input is intended for. Summaries of memory managed variables, including input data variables loaded by IDP, are possible to view in the simulation listing files with a Simulation Name File option described later. -\subsection{Example logging blocks} +\subsection{Example of Logging} -Below is example simulation logging (mfsim.lst) for two model package input files read and loaded by the Input Data Processor. The first logging block results from processing a DIS6 input file and the second logging block results from processing an NPF6 input file. Variable names in the blocks are described in later sections of this document. +Below is an example of simulation logging (to the mfsim.lst output file) for two model package input files read and loaded by IDP routines. The first logging block results from processing a DIS6 input file and the second logging block results from processing an NPF6 input file. Variable names in the blocks are described in later sections of this document. \small \begin{lstlisting}[style=modeloutput]