Usually we dedicate much time to developing tutorials and sometimes, just a few times, we actually write an article on this blog. Lately, our aim to discover and code is much greater than our impulse to give our opinion. This post is a special case where we write something without knowing if it is written because we are motivated or because there is something that needs to be written. In any case, writing this post doesn’t make us more free or happy…  “Es macht uns nicht mehr zufrieden”… because we don´t know much about some things related to human nature.

We are convinced that groundwater modeling is a great tool (but not the only one) for the sustainable management of our groundwater resources and open source software is an option to provide high quality and full featured software to any professional in the world. However the disorder in between the software, the packages, the operating systems, and even the trends create some grey areas on the use and application of groundwater modeling. 

We have coded a few and we have read some documentation. We wish to code more and test all the software available but we don’t want to wait 10 years to have an complete overview of the code available now, because in 10 years new software will be available and the circle will continue. We found some common issues on the available open source software for groundwater modeling and those are listed below:

1. Everything is Fortran based. Because most of the code was written in Fortran, because Fortran is fast, because we say so. Actually, we don’t code in Fortran, but we know that any code has its bright side and dark side and the option for Fortran for most of the codes seems more a status-quo than a scientific reason. As an analogy, kids play Fortnite because their friends play it too; no kid wants to play a video game without interaction. 

2. No spatial coupling. The only aquifer that exists with its origin at x=0 and y=0 are the ones located in laboratories. Real aquifers are geospatial and need a system of reference.  

3. No temporal coupling. Scenarios of groundwater exploitation and climate change require handling variable temporal discretization related to dates. Most software handles time as a relative variable where simulation starts from time 0.

4. Few energy in the development of Graphical User Interfaces (GUI). Besides Model Muse, there aren’t any other good examples of a high capacity preprocessor and postprocessor unless you tweak your results to be rendered on Paraview. There is a phrase that we might consider: “Modeling with a GUI doesn’t make you dumb and modeling with the command line doesnt make you smarter”. Every mode has its pro and cons but definitely the visual part is key for teaching, for understanding and for the socialization of model results. Our dreams of a GUI where we can have a Paraview style graphics with aPython console seems to be far away.

5. Coding anarchy. We can define anarchy as the state of disorder due to the absence of authority and that is exactly the case of the available tools of groundwater modeling. We have code that appears and does the same or 90% the same, that is the case of IWFN, WRF-HYDRO, PARFLOW, MODFLOW and MODFLOW-OWHM. The case of MODFLOW and MODFLOW-OWHM is even more confusing because both are supported by the USGS however only MODFLOW is implemented in Flopy. We should optimize the resources and talk more before releasing code that could be excellent, robust but not well “created” or created without a scope of interoperability.

—————
TRANSCOM ISP – Free Sigma HSE Email
Level 6 Domain Names are FREE – Register Now.