Is MODFLOW6 and GSFLOW6 Dead?

[Jon Dunn]

I heard that funding has been re-appropriated from MODFLOW6 and GSFLOW6 in favor of developing for WRF-HYDRO?

With the discontinued funding for MODFLOW6, will this effect Flopy as well?

[Ryan Conway]

Do you have a source you could link about the funding cut?

On Sun, Jun 7, 2020, 12:11 AM Jon Dunn <vbal...@gmail.com> wrote:

I heard that funding has been re-appropriated from MODFLOW6 and GSFLOW6 in favor of developing for WRF-HYDRO?

With the discontinued funding for MODFLOW6, will this effect Flopy as well?

--
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/ba93de84-fad4-4325-b3f3-49fec89f232eo%40googlegroups.com.

[Jon Dunn]

That is why I am asking the question here.

I have heard from several people at the Bureau of Reclamation, California DWR, and UC Davis that MODFLOW6 and GSFLOW6 funding is been cut to nearly zero, so they are going to become dead projects. From what I have been told is that the people developing MODFLOW6 are abandoning it to work as support developers for WRF-HYDRO.

Each time I ask someone from the MODFLOW6 developers, they never answer or when they do respond, they will not answer the question about their funding being cut for next fiscal year.

On Monday, June 8, 2020 at 8:50:04 PM UTC-7, Ryan Conway wrote:

Do you have a source you could link about the funding cut?

On Sun, Jun 7, 2020, 12:11 AM Jon Dunn <vba...@gmail.com> wrote:

I heard that funding has been re-appropriated from MODFLOW6 and GSFLOW6 in favor of developing for WRF-HYDRO?

With the discontinued funding for MODFLOW6, will this effect Flopy as well?

--
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 mod...@googlegroups.com.

[Prashanth Khambhammettu]

The modflow6 github repository is fairly active. Maybe that answers part of your question.

https://github.com/MODFLOW-USGS/modflow6  

Thanks,

PK

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/a73379b4-844e-4098-bb5e-7d282314dfffo%40googlegroups.com.

[Jon Dunn]

What I meant is their funding was cancelled starting next federal fiscal year.

That means they are funded until September 30th, and then it will stop.

On Tuesday, June 30, 2020 at 9:11:41 AM UTC-7, KP wrote:

The modflow6 github repository is fairly active. Maybe that answers part of your question.

https://github.com/MODFLOW-USGS/modflow6  

Thanks,

PK

On Sun, Jun 28, 2020 at 11:43 PM Jon Dunn <vba...@gmail.com> wrote:

That is why I am asking the question here.

I have heard from several people at the Bureau of Reclamation, California DWR, and UC Davis that MODFLOW6 and GSFLOW6 funding is been cut to nearly zero, so they are going to become dead projects. From what I have been told is that the people developing MODFLOW6 are abandoning it to work as support developers for WRF-HYDRO.

Each time I ask someone from the MODFLOW6 developers, they never answer or when they do respond, they will not answer the question about their funding being cut for next fiscal year.

On Monday, June 8, 2020 at 8:50:04 PM UTC-7, Ryan Conway wrote:

Do you have a source you could link about the funding cut?

On Sun, Jun 7, 2020, 12:11 AM Jon Dunn <vba...@gmail.com> wrote:

I heard that funding has been re-appropriated from MODFLOW6 and GSFLOW6 in favor of developing for WRF-HYDRO?

With the discontinued funding for MODFLOW6, will this effect Flopy as well?

--
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 mod...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/modflow/ba93de84-fad4-4325-b3f3-49fec89f232eo%40googlegroups.com.

--
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 mod...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/modflow/a73379b4-844e-4098-bb5e-7d282314dfffo%40googlegroups.com.

[Saul Montoya]

Hi everyone

There is an unwritten history about MODFLOW development and related software, and sadly that has a political side.

I will write on my own perception, I don't have further documents to support my ideas, however my approach seems reasonable.

There is funding for MODFLOW from the US Government. The total amount is stated on some internal reports. Years ago Trump went in conflict with the EPA due to climate change and other topics that were not favourable to the industry. As a way to promote industry, less governmental funds go to science and subsequently to MODFLOW development trying to make a "doomness" on the general audience. 

By sure we need a groundwater software that is independent from political issues.

If you have more accurate information, feel free to correct me.

Saul

Saul Montoya M.Sc. Director Dir: Caminos del Inca 288 dpto 302, Surco, Lima 33  |  Tel.: (511) 4491922  | Cel: Nuevo! (51) 984 115 861  |  Web: gidahatari.com

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/0123edae-7311-4e92-b268-4f628a9896eao%40googlegroups.com.

[Jon Dunn]

That was my thought that Trump was the issue, but its actually a USGS policy change that started before him.

If Trump was the issue, why would the funding shift towards the climate software, WRF-HYDRO, which is way more political.

From what I was told, Trump is no concerned about the USGS cause they do not do significant climate research.

Instead the USGS itself is not happy with the direction that MODFLOW6 was going in.

Personally, I just use MODFLOW-NWT and MODFLOW-2005 and not a fan of USG.

If I needed an unstructured grid, I rather use a finite element model rather than the fancy interpolation scheme done with Unstructured Finite Differences.

My main concern with this post, was if its true about the funding change, will that also affect products such as Flopy and MODPATH, which I heavily rely on.

To view this discussion on the web visit https://groups.google.com/d/msgid/modflow/0123edae-7311-4e92-b268-4f628a9896eao%40googlegroups.com.

[vbal...@gmail.com]

Ok, well I found out a bit more information on whats going on.

There has been a small amount of money appropriated for next fiscal year (Oct 1 to Sep 31) for maintenance and some feature development for MODFLOW6. To get the most out of the small amount of money, its being dispensed to lower level people, whose hourly rate is less than the original developers.

What I am going to do is switch to using MODFLOW-NWT for structured grids, and if I needed unstructured use the California's Finite Element Software IWFM (https://water.ca.gov/Library/Modeling-and-Analysis/Modeling-Platforms/Integrated-Water-Flow-Model). That seems to have more features and looks promising since its been around and actively developed for the last 10 years.

[Jon Dunn, Ph.D., P.E., P.H.]

It looks like with the new president they are not getting future funding for MODFLOW6, so they are likely dead projects after Sept 30th of this year.

Which is why this

https://www.usgs.gov/mission-areas/water-resources/science/modflow-and-related-programs?qt-science_center_objects=0#qt-science_center_objects

wish-list has not been updated since last July to create the illusion of lots of updates coming.

[Richard B. Winston]

The wish list probably should be updated now that two of the four things on it have been accomplished (groundwater transport and buoyancy).

[Saul Montoya]

Modflow 6 wont die, because it will life forever in our souls.

Viva el software libre!

Saul Montoya M.Sc. Director Dir: Caminos del Inca 288 dpto 302, Surco, Lima 33  |  Tel.: (511) 4491922  | Cel: Nuevo! (51) 984 115 861  |  Web: gidahatari.com

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/0132a4e0-ef3e-461d-baec-3ed931ece8a6%40mindspring.com.

[Jon Dunn, Ph.D., P.E., P.H.]

That is true about them adding the transport feature, but its not as useful as simulating surface water-groundwater interaction, which is where most modeling projects are. Transport has to much uncertainly, and there are programs better suited for it, such as MT3D.

Another concern with transport is the same people developed Seawater Intrusion Package for MODFLOW-2005 (https://pubs.usgs.gov/tm/6a46/), which was abandoned as soon as they were no longer funded for it. Now its left for people to find out that it does not work, and when they submit a bug fix they get brushed off. That is why I would not use the new transport code.

[Jeremy White]

For what its worth, I've been using the new transport process in MF6 with the density-dependent options in an effort to better understand uncertainty and data assimilation in these types of problems - its worked awesome for me, easy to use and stable. Its probably also worth pointing out the MF6 has SFR2-style capabilities to simulate sw-gw exchange...I think MF6 really well designed and implemented and positioned to be a solid simulation platform for a while to come.

[Mak.Gurukul]

I can't agree more than  Jeremy's statement.

[Jon Dunn, Ph.D., P.E., P.H.]

That is true, but both of you are private consultants that make money on your extensions to MODFLOW6, so I would say your opinion is biased.

Also, the SFR in MODFLOW6 only supports rectangular cross sections which is not a good assumption compared to trapezoid or six point cross sections.

I was surprised they named it SFR when it more closely reflects the 1980s stream package (STR not SFR) and is not useful for modern simulation of stream-aquifer interaction.

That is even stated in the "Known Limitations" section of the release notes:
https://water.usgs.gov/water-resources/software/MODFLOW-6/release_6.2.1.pdf

[ashutosh singh]

Hi,

Can you please state that when you mean the 'modern simulation' which set of equations do you want to use.

I have tried to work with fully coupled groundwater-surface water physically based model with Newton Krylov solvers and could not ever get convergence. That code included one of the ways to represent streams which included lots of physics.

Till date I haven't seen a code which works as efficient as ModflowNWT and Modflow6. Having said that ofcourse there might be a code I am unaware of which includes the stream-aquifer interaction represented in a better way. Does anyone know such groundwater surfacewater interaction code.

Ashutosh Singh

To view this discussion on the web visit https://groups.google.com/d/msgid/modflow/d8813213-04d8-426c-8cc7-aa8253f1d81an%40googlegroups.com.

[Chris Russoniello]

Jon,

Except that my recollection is that STR never had 'routing' or the ability to/for gaging, which was the major improvement of SFR (not SFR2/LAK).

I'm super excited about MF6. The developers have been doing a great job to make it accessible and useful and have been listening to the user base. The new abilities they baked-in to the code is super nice for better representing different situations (including SW/GW interax). For instance, you can easily turn CHD boundaries on/off in different stress periods, which you couldn't do without writing your own Fortran code, previously.

If you haven't given MF6 a try, the ModelMuse and floppy implementations are free. Hatari labs has generated some really nice online tutorials if you want a walk-through.

PS, I'm not a private consultant ;).

-CR

[Jeremy White]

Jon Dunn – opinions are biased, that is why they are opinions.  I wonder what your biases are?  You dont appear to be very fond of MODFLOW6 or GSFLOW...And “who is Jon Dunn”?  Even with all those acronyms, you don’t exists anywhere on the internets so Im guessing you are using a pseudonym to hide...#sad

Yes,  Im a consultant - not sure why that matters?  I solve real-world problems and support decision makers with modeling towards making the best use of limited natural resources - lots of fun to be had!  I don’t have any mf6 extensions and I don’t make money from software - all the software I work on is open-source and free (that doesn't mean its any good tho!) . I do like what mf6 brings to the table in terms of current capabilities and forethought in its design...although Im not a fan of fortran - Haha!

You are right about mf6 currently only supporting rectangular cross sections. But MF6 is open-source and community contributions are encouraged ( in fact, seems like the community is supportive of mf6 because contributions appear to taking off!).  So if you feel more advanced channel geometry options are important for settings you are modeling (and/or might be important for other settings), then, by all means, contribute!  Be part of the solution and get involved with a great simulation platform that is mf6.

Ashutosh Singh - Im not an expert on numerical solutions but the mf6 dev team is really good at what they do and Im sure they are exploiting any and all numerical tricks!

[Jon Dunn, Ph.D., P.E., P.H.]

Quick answer, since it seems like I have angered the mob.

My original question, which no one ever answered was, is MODFLOW6 and GSFLOW6 dead projects in terms of funding from the USGS.

If so, then does that affect FloPy and ModelMuse.

@ Ashutosh A better alternative is the California's  Integrated Water Flow Model (IWFM)
https://water.ca.gov/Library/Modeling-and-Analysis/Modeling-Platforms/Integrated-Water-Flow-Model

It is based on finite elements, which is mathematically correct compared to unstructured finite differences.

Also because of the California Sustainable Groundwater Management Act, has stable funding for the next 20 years.

By proper models, I mean they should be built using MODFLOW-NWT from MF-2005 with structured grids or in IWFM for unstructured grids. Otherwise you are just doing a fancy conductance weighted interpolation with ghost nodes, which over-estimates the solution.

In fact California now requires all groundwater basins to include a conjunctive use model to prove sustainability. The state recommends using MODFLOW-2005 based versions or their software, IWFM, and not modflow-6 core based models.

@CR Models should never use CHD!!! That is only meant for silly examples to illustrate features or for undergraduates building a class project. Setting a model to a fixed head boundary controls the entire solution and its result has no predictability. A decent model should always use head dependent stress, such as the General Head Boundary. That comment only goes the show that the developers are focused on features that make models easier, but not more accurate or better at prediction--which is the point of modeling.

J

[Randall Hanson]

Sorry Chris not true. We added various diversions to STR back in my Ventura model study and we had Hymod to develop gaging since 1988. The best newest version on Modflow is MF-OWHM...check it out!!

No one should ever use constant heads and the best new versions of boundary conditions like GHB and others and better wells is MF-OWHM!!

Cheers,

Randy Hanson

Sent from my iPhone

On Apr 6, 2021, at 6:59 PM, Jeremy White <jtwhi...@gmail.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/modflow/4353e4d0-cb07-4ede-b3cf-7e9093175226n%40googlegroups.com.

[Scott Elliott Boyce]

No comment on the topic of this discussion, but I wanted to clarify about the RIV vs STR vs SFR.
I am a bit of a MODFLOW history buff and like to give kudos to the originators for what they have done.

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

First, so this does not get lost in my long rant about RIV-STR-SFR, I wanted to bring up about seeing that Randall mentioned MF-OWHM (sometimes called MODFLOW-OWHM or OneWater). He and I go way back with working together, so thanks for the shameless promotion 😉

I wanted to provide the current links for it. There are a couple of false/incorrect pages out there that google seems to always yield when people search for it.

Home page:

• https://www.usgs.gov/software/modflow-one-water-hydrologic-flow-model-conjunctive-use-simulation-software-mf-owhm

Source Code Repository:

• code.usgs.gov/modflow/mf-owhm
  • I am happy to sponsor anyone that would like an account with code.usgs.gov gitlab style git server.
    

Report:

• https://doi.org/10.3133/tm6A60

There also are a number of comparisons of IWFM vs MF-OWHM and their utility for the California Sustainable Groundwater Management Act.

A good one for those interested in the two simulation engines (since Jon recommended IWFM):

Department of Water Resources. 2020. Water Budget Handbook. Sacramento, CA: California Department of Water Resources. 446 pp. Available online at: https://water.ca.gov/-/media/DWR-Website/Web-Pages/Programs/Groundwater-Management/Data-and-Tools/Files/Water-Budget-Handbook.pdf

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

Now for the long rant about SFR and STR.

RC, I think you are referring to the River Package (RIV) which is a reformulated General Head Boundary (GHB, https://water.usgs.gov/ogw/modflow/MODFLOW-2005-Guide/index.html?ghb.htm) and does not route flow. I also think RIV was part of the original MODFLOW. On a funny side note, just about every package is just a reformulated GHB but just adds representative terminology and additional calculations to determine the GHB BHEAD and CONDuctance (for example SFR calculates the stream stage, which becomes the BHEAD and the streambed hydraulic conductivity becomes COND).

The Stream Package (STR, https://water.usgs.gov/ogw/modflow/MODFLOW-2005-Guide/index.html?str.htm) specifies a rectangular stream network and instantaneously routes flow through the network. The STR package did include Stream Observations (https://water.usgs.gov/ogw/modflow/MODFLOW-2005-Guide/index.html?stob.htm) and the HydMod package (https://water.usgs.gov/ogw/modflow/MODFLOW-2005-Guide/index.html?hyd.htm) came out as well. HydMod provided time series output for multiple packages (such as STR/SFR).

Falling back to STR, its formulation was later refined in became the basis of the first release of HEC-RAS. HEC-RAS enhanced the concepts to include multiple bottom geometries and moved the stream depth calculation to the center of the reach (STR estimates stream depth at the start). This led to the rewrite of STR to make Stream Flow Routing (SFR) to bring in the features of HEC-RAS and a lot of additional new features. Along the way there were a lot of enhancements added though applied projects (such as Randall mentioned with advanced diversion options being added).

Later SFR2 came out to include stream bed unsaturated flow and a linkage to UZF. At that time it became trendy to have companion observation packages (for example MNW2 added MNWI, when MNW1 pretty much had the two packages as one), so with SFR2 came the GAGE package (which could be easily obtained from HydMod or in SFR by setting ISTCB2>0 or in MF-OWHM using the database output options, DBFILE).

I am not overly familiar with the MF6 SFR outside of their release documents and skimming through their code, but I can imagine it is quite challenging developing a stream flow routing option that supports structured grids, unstructured and vertices. That is probably why the selected to keep MF6-SFR simpler with rectangular bottoms, but I assume they follow the more modern technique of calculating depth and flow at the mid-point instead of the beginning of the reach.

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

The next topic are constant heads (CHD, https://water.usgs.gov/ogw/modflow/MODFLOW-2005-Guide/index.html?chd.htm) or better known as Dirichlet boundary conditions. It is a very appealing option due to its simplicity, but outside of classroom examples or trying to reproduce a lab experiment it should never be used. The problem with constant heads is that it fixes the solution with an infinite amount of water. A classic example would be to have a WEL next to a CHD, which would create the illusion of infinite water availability cause the well would just be pulling water from the constant head. If a fixed head is needed it should use the GHB (a Cauchy boundary condition) with a high conductance, then through calibration its value can later be reduced to create a more realistic boundary that is head dependent. For the case of the GHB, the WEL would extract water from the boundary but the rate becomes limited by the GHBs CONDuctance resulting in a head drop. Also, CHD cells are effectively removed from the simulation resulting in the cells hydraulic properties being moot. While GHB is something attached to the cell that provides flow into it, preserving its properties.

Something you may want to skim over is the first 23 pages (43 in the pdf) of this report https://pubs.usgs.gov/tm/06/a60/tm6A60.pdf, which talks a lot about that. I must admit there are a few math mistakes in that report (mostly innocuous stuff, such as the wrong units for Sy and missing an x in ∂x). That report was used as textbook for a university course and the professor just let me know. I am hoping that an update will be posted soon.

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

and last of the last, since I saw Jeremy knocked Fortran, I figured I tease him with a few quotes from my email signature (always good to end a long rant with a laugh). But then I do sleep with a copy of the original IBM Fortran manual under my pillow 😴

 C++ has its place in the history of programming languages.
Just as Caligula has his place in the history of the Roman Empire.
                                            --Robert Firth.

 In C++ it's harder to shoot yourself in the foot, but when you do, you blow off your whole leg.
                                            --Bjarne Stroustrup (one of the creators of C++)

 The great thing about Object Oriented code is that it can make small, simple problems look like large, complex ones.
                                            --John D. Cook

 Also, C++ better watch out; I am building a Fortran Standard library that will give it a run for its money 😉
https://code.usgs.gov/fortran/bif

Scott

[Saul Montoya]

Very interesting discussion about the development of Modflow. 

I wanted to post an article about "What we dont see in the latest development of open source groundwater models" that would be very partial, could be even misleading but somehow reflects (a bit) of the "common" enduser experience. A enduser that is not so hydrogeek, that has limited hydrogeological background, that works on Windows and might not know Python and has no idea of what Fortran is.

Of what I have seen, the code development is entirely focused on solving groundwater flow, but few or less have been done to the development of preprocessors and postprocessor or the integration of time and geospatial reference systems inside the code.

If you have any idea about the topic, let me know.

Saul Montoya M.Sc. Director Dir: Caminos del Inca 288 dpto 302, Surco, Lima 33  |  Tel.: (511) 4491922  | Cel: Nuevo! (51) 984 115 861  |  Web: gidahatari.com

To view this discussion on the web visit https://groups.google.com/d/msgid/modflow/6dc004a2-0213-4860-9843-bcf8e7346147n%40googlegroups.com.

[Peter Mock]

Hi Scott-

Thank you for stepping up and writing this excellent response to recent statements.  Well said.

I do think CHDs can be helpful early in the construction and "shakedown" of very large, complex, "fragile" groundwater models, but agree in general with your preference for GHBs.

The thoughts on C++ were hilarious!

Cheers,

Peter

Another concern with transport is the same people developed Seawater Intrusion Package for MODFLOW-2005 ( https://pubs.usgs.gov/tm/6a46/), which was abandoned as soon as they were no longer funded for it. Now its left for people to find out that it does not work, and when they submit a bug fix they get brushed off. That is why I would not use the new transport code.

On Wednesday, February 24, 2021 at 7:39:57 AM UTC-8 saulm...@gidahatari.com wrote:

Modflow 6 wont die, because it will life forever in our souls.

Viva el software libre!

Saul Montoya M.Sc. Director Dir: Caminos del Inca 288 dpto 302, Surco, Lima 33  |  Tel.: (511) 4491922  | Cel: Nuevo! (51) 984 115 861  |  Web: gidahatari.com

On Wed, Feb 24, 2021 at 4:57 AM Richard B. Winston < rbwi...@mindspring.com> wrote:

The wish list probably should be updated now that two of the four things on it have been accomplished (groundwater transport and buoyancy).

On Feb 23, 2021, at 11:45 PM, "Jon Dunn, Ph.D., P.E., P.H." < vbal...@gmail.com> wrote:

It looks like with the new president they are not getting future funding for MODFLOW6, so they are likely dead projects after Sept 30th of this year.

Which is why this

https://www.usgs.gov/mission-areas/water-resources/science/modflow-and-related-programs?qt-science_center_objects=0#qt-science_center_objects

wish-list has not been updated since last July to create the illusion of lots of updates coming.

On Tuesday, September 1, 2020 at 7:46:27 PM UTC-7 Jon Dunn, Ph.D., P.E., P.H. wrote:

Ok, well I found out a bit more information on whats going on.

There has been a small amount of money appropriated for next fiscal year (Oct 1 to Sep 31) for maintenance and some feature development for MODFLOW6. To get the most out of the small amount of money, its being dispensed to lower level people, whose hourly rate is less than the original developers.

What I am going to do is switch to using MODFLOW-NWT for structured grids, and if I needed unstructured use the California's Finite Element Software IWFM ( https://water.ca.gov/Library/Modeling-and-Analysis/Modeling-Platforms/Integrated-Water-Flow-Model). That seems to have more features and looks promising since its been around and actively developed for the last 10 years.

To view this discussion on the web visit https://groups.google.com/d/msgid/modflow/6dc004a2-0213-4860-9843-bcf8e7346147n%40googlegroups.com.

Peter A. Mock. Ph.D., R.G.

Principal Scientist
Peter Mock Groundwater Consulting, Inc.

Hydrology, Geology and Environmental Science