MODFLOW-USG on Linux

[Marius Jigmond]

Has anyone tried to compile and (successfully) run the test problem (biscayne.nam) available with the source code? I was able to compile the code with the Intel compiler and the following flags:

F90FLAGS= -O2 -heap-arrays -fpe0 -traceback

but the run crashes in stress period 2 with "floating invalid" error. The output from the run is:

[mjigmond@head 02_quadtree]$ mfusg biscayne_nix.nam

                                  MODFLOW-USG

    U.S. GEOLOGICAL SURVEY MODULAR FINITE-DIFFERENCE GROUNDWATER FLOW MODEL

                             Version 1.0.00 05/03/2013

 Using NAME file: biscayne_nix.nam

 Run start date and time (yyyy/mm/dd hh:mm:ss): 2013/07/10  7:39:25

 Solving:  Stress period:     1    Time step:     1    Groundwater Flow Eqn.

 Solving:  Stress period:     2    Time step:     1    Groundwater Flow Eqn.

forrtl: error (65): floating invalid

Image              PC                Routine            Line        Source

mfusg              000000000051EA17  sgncn2bcfu1bdadj_        1146  DISU2GNCn1.f

mfusg              000000000057D135  MAIN__                    304  mfusg.f

mfusg              0000000000402F8C  Unknown               Unknown  Unknown

libc.so.6          0000003C4041ECDD  Unknown               Unknown  Unknown

mfusg              0000000000402E89  Unknown               Unknown  Unknown

Aborted (core dumped)

It seems the exception is thrown due to the -fpe0 flag which traps three kinds of exceptions: overflow, the divide-by-zero, and the invalid floating-point exceptions.

Line 1146 in DISU2GNCn1.f is TMPA(II) = TMPA(II) - CORRECTnm which rules out divide-by-zero and possibly overflow depending on magnitude and sign of CORRECTnm.

I should add that removing the -fpe0 flag allows the simulation to complete but I'm not sure if wrong/invalid numbers are written to the output files.

[Michael Ou]

Hi Marius,

You could try printing out TMPA(II) and CORRECTnm on the screen to check if "NaN" is generated. If you see "NaN", it means something wrong in floating-point calculations.

Michael

[Mike Toews]

Hi Marius,

I've encountered the same issue too, and relayed it to Sorab. I believe he has fixed it for a future release.

The floating point exception was caused by using an allocated, but uninitialised array (TMPA) with nonsense values (NaN, -NaN, etc.) rather than zero. There are actually a number of ways to fix it, but removing -fpe0 should do it. You could also redefine TMPA as DOUBLE PRECISION, and/or move the flow accumulation array initialisation code up a few lines in GWF2BCF-LPF-U1.f (near line 2039), before the RETURN call. This array is only used for output, not solving, so it isn't a major issue.

-Mike

[Marius Jigmond]

Thanks, for now I'll just drop the flag until the new version comes out.