UZF's evapotranspiration extending runtimes

[Michael Krasowski]

Hi all,

I'm running into a bit of block. I'm working on a study area with an unconfined, alluvial aquifer. I've always envisioned using the uzf package with the ET option enabled, but for an equivalent model with ET off and then on, the run times go from ~20 minutes to ~20 hours. Any ideas on what's happening here? It's also super finicky and with different inputs often crashes with the error TOO MANY WAVES IN UNSATURATED CELL or something similar when I turn on the ET option. Any insight here would be greatly appreciated. The calibration for the few successful ~20 hour runtimes has been the best of anything I've tried so I'd really like to be able to use it.

Thanks,

Mike

[Richard B. Winston]

This probably isn't the advice you want but I think the UZF package should not be used in nearly all models. It makes the models more complicated and less stable but because of the uncertainties in its inputs, it will only rarely make the model predictions better.

[Michael Krasowski]

Thanks for your input! And yeah, I have tossed around the idea of going back to the RCH package. Part of the reason I was excited to use the UZF package is because I come from a surface water modeling background. Because of that, my inclination is to input precip into a model and have the model do all of the partitioning. That's not really possible with the standard RCH package, right? UZF brings in the unsaturated processes obviously, but it also prevents you from having to install drains across the model to accommodate exfiltration and allows for ET processes. Is there an alternative method to go from precip to recharge with the RCH package?

[Richard B. Winston]

You are correct. With the recharge package, you have to estimate how much of the precipitation becomes recharge yourself rather than letting the model do it.

[Randall Hanson]

Hey Michael,

Try Modflow-OWHM because we can do what you are wanting to do.

Sent from my iPhone

On May 18, 2021, at 8:28 PM, Michael Krasowski <mike...@gmail.com> wrote:



--
You received this message because you are subscribed to the Google Groups "MODFLOW Users Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to modflow+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/modflow/3646d503-28c2-47bf-a165-c46173b249den%40googlegroups.com.

[Randall Hanson]

Yes and all you need to do is specify arrays or precipitation, potential ET, and land use and MF-OWHM calculates recharge (natural and artificial), pumpage, and runoff all for you during the simulation. This allows you to use fundamental data types directly and also makes climate change projections super easy.

Let us know if you need guidance.

Cheers 

Randy Hanson

One-Water Hydrologic

http://www.one-waterhydrologic.com/

Sent from my iPhone

On May 18, 2021, at 11:31 PM, Richard B. Winston <rbwi...@mindspring.com> wrote:



--

You received this message because you are subscribed to the Google Groups "MODFLOW Users Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to modflow+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/modflow/6c2bbb12-03f9-4135-ade6-397de1464956%40mindspring.com.

[Scott Elliott Boyce]

Generally you only need to run UZF if the delay from surface infiltration to saturated groundwater is greater than a time step. Often the lag from infiltration does not affect the overall semi-annual budget, especially considering other model construction errors relative to not catching the time lag. 

Most projects that I know of only use UZF if there is a large depth to groundwater (~200m) or if the travel time to groundwater is greater than 30 days (typically for a model with monthly stress periods and weekly time steps).

What you may want to do is give the model a run using MODFLOW-OWHM. We have continued to maintain and patch UZF bugs. If MODFLOW-OWHM does not work and you are comfortable sharing the model, I am happy to run it in the debugger and see if it is a code error (UZF has lots of div/0 errors and negative power errors that I have been slowing fixing in my spare time). 

You can pull a the current copy of MODFLOW-OWHM (released 2 days ago) by going to:

https://code.usgs.gov/modflow/mf-owhm

and then if you scroll down to the readme, there are direct download links.

Or you can just go here: https://code.usgs.gov/modflow/mf-owhm/-/raw/release/bin/mf-owhm.exe

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

The part that Randall is talking about is the Farm Process (FMP) which is a land-scape/land-use simulation that is run inside of MODFLOW
(which is what makes MODFLOW-2005/MODFLOW-NWT into MODFLOW-OWHM, as well as a number of improvements on MODFLOW-2005/NWT). 

In FMP you can specify crop properties and use the software to estimate unknown irrigation demand and recharge. Recharge from FMP either travels immediately to saturated groundwater or can be passed to UZF to simulate delayed recharge from irrigation and precipitation.

If you want to know about it, the most recent publication is located at:

Boyce, S.E., Hanson, R.T., Ferguson, I., Schmid, W., Henson, W., Reimann, T., Mehl, S.M., and Earll, M.M., 2020, One-Water Hydrologic Flow Model: A MODFLOW based conjunctive-use simulation software: U.S. Geological Survey Techniques and Methods 6–A60, 783 p., https://doi.org/10.3133/tm6A60

the doi link redirects here: https://pubs.er.usgs.gov/publication/tm6A60

Hope that helps out.

Feel free to reach out at me directly if you have questions or need me to run the model in the debugger.

Scott

seb...@usgs.gov

[Michael Krasowski]

Richard, Thanks for the insight! Sounds like setting up my own precip-to-recharge partitioning algorithm might be my best option

Randall, Thank you for your response! It sounds like OWHM would be right up my alley. Unfortunately we have developed our current project in FloPy and it doesn't appear to support OWHM (yet?). I will definitely be keeping an eye out for opportunities to use it in the future.

Hi Scott, Very good to know about the intended use cases for UZF. Our system is very near-surface (~100 ft thick aquifer with max depth to water something like 20 ft). Wow, very fresh version of OWHM! Unfortunately as I noted above, our project is currently using FloPy and it doesn't look like OWHM is supported yet. Thank you for the reference links, those are going to the top of my reading list.


(This is my first time using google groups, not sure how the reply system works, hopefully this makes sense!)

[Scott Elliott Boyce]

Some good news is that anything that runs on MF-2005 or MF-NWT, so you can build the those models with FloPy and run them with MF-OWHM. 

I have two PhD students that are building OWHM models, one is using ModelMuse and the other is using FREEWAT. Both are using them to build the base part of the model (pretty much a MF-NWT model), then they are building the OWHM specific extensions manually through QGIS (the newer input structure is very easy to maintain). 

You may even want to trying running your model with OWHM just to have access to a lot of its implicitly included features (such as better warning messages and all numbers are double precision instead of single). You also can manually enable in the Name file the WARN package and additional output files (checkout my option block cheatsheets). Another example is that the OC package is optional in in OWHM since all its features can be done with simple keywords in the BAS option block. 

Another perk is I actively use OWHM in my current projects and most in my office are using it, so I frequently uncover bugs in MODFLOW. For example, I discovered over the weekend that MNW2 does not report the correct well head in a well whose pumping exceeds its production capacity. In particular, the output just prints the head in the cell rather than the bottom of the well screen. This is particularly important if the well is located in a convertible layers and enables the partial penetration correction cause it previously the well would under-estimate pumpage by incorrectly reducing the seepage interface flow.

With regards to FloPy, there has been some unofficial development for OWHM specific features, both by outside contributors (http://www.freewat.eu) and some of the actual FloPy developers. Unfortunately, the lead FloPy developer absolutely refuses to incorporate into the official release support MF-OWHM and I doubt he will change his mind. I personally do not want to make a forked repo, as was done with GSFLOWpy. 

Note that the output files are standard MODFLOW-2005 format, so those should work with FloPy. Most people I know only use it for post-processing rather than model building. For pre-processing, ModelMuse is a better option. I am hoping at some point ModelMuse will support OWHMv2 to provide GUI access. I think it is a better option than FloPy.

Lastly, the following image shows all the versions of MODFLOW that are included in OWHM and should run in OWHM: