Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Stream Processing Tutorial Issue #41

Open
boatmorrow opened this issue Feb 15, 2023 · 5 comments
Open

Stream Processing Tutorial Issue #41

boatmorrow opened this issue Feb 15, 2023 · 5 comments

Comments

@boatmorrow
Copy link
Contributor

First:

This code is super cool, and the tutorials are great. Thanks for all the work! Super.

Second - I'm running on macOS. pygsflow installed with pip.

mfnwt and gsflow compiled for Mac using pymake. I can run the full GSFLOW tutorials, so pygsflow, prms, gsflow, and mfnwt all work fine.

Third, I have a fair amount of experience using flopy - just for background.

I'm trying to build my own GSFLOW model using the following the builder tutorial steps. All goes fine, until I build and try to run the first mfnwt model. I am getting an:

                              MODFLOW-NWT-SWR1 
U.S. GEOLOGICAL SURVEY MODULAR FINITE-DIFFERENCE GROUNDWATER-FLOW MODEL
                         WITH NEWTON FORMULATION
                         Version 1.2.0 03/01/2020                        
                BASED ON MODFLOW-2005 Version 1.12.0 02/03/2017                       

                SWR1 Version 1.04.0 09/15/2016

Using NAME file: ElkCreek_100m.nam
Run start date and time (yyyy/mm/dd hh:mm:ss): 2023/02/15 15:11:39

Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation.

Backtrace for this error:
#0 0x10c522145
#1 0x10c521799
#2 0x7ff81c2b8c1c
#3 0x10c086a74
#4 0x10bfba364
#5 0x10c16e878
#6 0x7ff81bf5b30f
False

I'm fairly confident this has something to do with the streamflow and sfr package creation, because I can reproduce this error using the tutorial notebooks IF I use the "sagehen_50m_streams.bin" produced in tutorial 05.

In Tutorial 05 - sagehen_50m_streams.bin goes to "data/temp", but is read from data/sagehen/50m_tutorials on tutorial 06.

If I run mfnwt using the streams.bin from 50m_tutorials, it runs successfully.

However, changing tutorial 06 to read sagehen_50m_streams.bin from data/temp rather than the static data/sagehen/50_tutorials I get the following on running the model:

FloPy is using the following executable to run the model: /Users/wpgardner/soft/modflow/pymake/examples/mfnwt

                              MODFLOW-NWT-SWR1 
U.S. GEOLOGICAL SURVEY MODULAR FINITE-DIFFERENCE GROUNDWATER-FLOW MODEL
                         WITH NEWTON FORMULATION
                         Version 1.2.0 03/01/2020                        
                BASED ON MODFLOW-2005 Version 1.12.0 02/03/2017                       

                SWR1 Version 1.04.0 09/15/2016

Using NAME file: sagehen_50m.nam
Run start date and time (yyyy/mm/dd hh:mm:ss): 2023/02/15 15:59:24

Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation.

Backtrace for this error:
#0 0x1041f8145
#1 0x1041f7799
#2 0x7ff81c2b8c1c
#3 0x103d5ca74
#4 0x103c90364
#5 0x103e44878
#6 0x7ff81bf5b30f
False

Same error as my model....

SO, my questions are:

  1. Is there some different processing that occurred to get "sagehen_50m_streams.bin" found in data/sagehen/50m_tutorials?

  2. Can you reproduce this issue if you use the binary streams file produced from tutorial 05?

Thanks,

Payton Gardner
@jlarsen-usgs
Copy link
Contributor

@boatmorrow

Hi, the processing between the two versions of "sagehen_50m_streams.bin" should be identical. The one that is stored in the "data/sagehen/50m_tutorials" is there for two reasons 1) to allow users to run notebooks in any order, and 2) to allow for easier debugging on the development side when something goes wrong.

I reran the complete workflow in the notebooks, subsituting the code output for the stored output and wasn't able to reproduce the error on Windows. I also successfully ran the full sagehen_50m.py script which is located in the examples\frontiers folder of the repository.

I have tinkered around in the code to fix some bugs as they've come up since the most recent release. Did you install pyGSFLOW from the development branch or from pypi?

@boatmorrow
Copy link
Contributor Author

I installed with pypi. Will try dev. Can you try on a linux machine? I will install on my linux server and run there too.

@boatmorrow
Copy link
Contributor Author

boatmorrow commented Feb 16, 2023 •
edited
Loading

Ok, reinstalled with development branch and everything works. The release branch stream processing has something wrong with it. I might suggest updating release. I'm happy to push my osx compiled binaries to the repository if you want them. I also slightly modified frontiers/sagehen_50m.py to use the osx binaries if it's a Mac. But, given the Survey led development, I get it if you don't want the osx hassle.

@jlarsen-usgs
Copy link
Contributor

@boatmorrow

I think it would be great to add osx support to gsflow and pyGSFLOW. Can you send me your pymake recipie for GSFLOW? I'm planning on doing an updated release sometime soon, however, there are a couple of additions/fixes I'd like to make in the code before the next release.

@boatmorrow
Copy link
Contributor Author

boatmorrow commented Feb 17, 2023 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jlarsen-usgs @boatmorrow