ncar / nws_hydro_models

Hydrology models adapted from NWS conceptual modeling approaches and code.

NWS_hydrology_models

Hydrology models adapted from NWS conceptual modeling approaches and code.

nws_hydro_models's Issues

Can't compile .exe

After the command "make -f Makefile" in the src_bin/driver/ folder, I get the following warning/ error:
Warning: Possible change of value in conversion from REAL(8) to REAL(4) at (1) [-Wconversion]
make: *** [Makefile:161: compile_calib] Error 1

And the executable file won't compile so I then can't run the SnowSacUH.exe.

Any ideas on how to fix this?

Double precision compilation flags

While removing tiny from aesc19.f would eliminate differences between compilers when they do not explicitly specify real-8 with a compilation flag (see issue #12), it does not eliminate differences between compilers with and without the compilations flag. For example, if we set tiny=0.0 and recompile with the addition of the -r8 flag in PGI (for both pgf70 and pgf90), the peak SWE increases dramatically (Fig.1). The same type of behavior is more marked in ifort with and without -autodouble (Fig. 2), but completely different behavior is displayed when gfortran uses the -fdefault-real-8 flag. In all of these cases, tiny was set to 0.0 in aesc19.f, which means that this is probably not directly related to issue #12. However, it does seem to be an issue in the snow19 routines, and could very well have to do with rounding/precision errors impacting the behavior of if and goto statements in aesc19.f. In my opinion, it is best not to use the NWS_hydro_models with a double precision flag until this bug is located.

Fig. 1. Daily SWE time series after runs compiled in PGI with the -r8 flag and without it.

Fig. 2. Daily SWE time series after runs compiled in ifort with the -autodouble flag and without it.

Fig. 3. Daily SWE time series after runs compiled in gfortran with the -fdefault-real-8 flag and without it.

Differences between model versions compiled with `ifort`, `gfortran`, and `pgi`

This issue addresses differences between compilations (without explicit double precision flags) of the SHARP branch. The case with double precision flags will be addressed in a separate issue. I used three compilers on hydro-c1 at UCAR with the following flags:

1. ifort (IFORT) 15.0.2 20150121
   • sac_77: ifort -O3 -f77rtl
   • snow19: ifort –O3
   • UTIL: ifort -O3 -warn all -check all
2. GNU Fortran (Debian 4.9.2-10) 4.9.2
   • sac_77: gfortran -O3 -fno-align-commons -ffree-line-length-none flags77
   • snow19: gfortran -O3 -fno-align-commons -ffree-line-length-none flags2
   • UTIL: gfortran -O3 -fno-align-commons -ffree-line-length-none
3. PGI 15.7-0 64-bit target on x86-64 Linux -tp sandybridge
   • sac_77: pgf77 -O3
   • snow19: pgf90 –O3
   • UTIL: pgf90 -O3 -Kieee

Note that the Makefile in this commit does not use any flags for PGI because the FC and FC77 variables do not match pgf90 or pgf77 as expected in the if statements that turn on these flags.

These compilers produced different results, particularly in the wintertime.

Fig. 1. SWE timeseries: The lower set of lines shows swe in mm, plotted on the left axis. The upper set of lines shows the difference in swe in mm between the simulation using PGI and the other two compilers.

@anewman89 suggested checking a change he had made to include a tiny offset in aesc19.f for when the precision of an ascii restart file caused problems in the comparison. tiny is an intrinsic function with tiny(x) - Returns the smallest positive number that can be represented on the current computer for real argument x, but in the current commit, tiny does not call an argument x; it is treated as an uninitialized variable.

When I tried to print out the values of tiny to the screen, the PGI compiled code produced different results than when PGI compiled the same code without a print statement. This suggests a memory error.. I ran the program with valgrind, which identified a leak at the line where tiny is used:

==40656== Conditional jump or move depends on uninitialised value(s)
==40656==    at 0x40421E: aesc19_ (aesc19.f:25)
==40656==    by 0x402857: pack19_ (PACK19.f:218)
==40656==    by 0x40C252: exsnow19_ (exsnow19.f:142)
==40656==    by 0x40F2ED: MAIN_ (multi_driver.f90:282)
==40656==    by 0x401CC3: main (in ~/NWS_hydro_models/Snow17SacUH/src_bin/Snow17SacUH.exe)

The values printed for tiny were inconsistent. Here is a subset of the values printed to the screen in valgrind:

 tiny=  -1.7005811E+38
 tiny=    0.000000    
 tiny=  -1.7005811E+38
 tiny=   8.5123166E-02
 tiny=  -1.7005811E+38
 tiny=   8.3787210E-02
 tiny=  -1.7005811E+38
 tiny=   0.1242791    
 tiny=  -1.7005811E+38
 tiny=    0.000000    
 tiny=  -1.7005811E+38
 tiny=   0.1852178    
 tiny=  -1.7005811E+38
 tiny=    0.000000 

Three equivalent independent solutions that successful matched the PGI compiled output to that of the other compilers (bringing the black line down to match the red and blue lines in Fig. 1, and reproducing simulated streamflow to within +/-0.01 cfs) were:

1. Use the -Msave flag on f90 and f77: This initializes all undefined values at zero.
2. Set tiny = 0.0 before line 15 in aesc.f.
3. Remove tiny completely.

The consistency of these options with ifort and gfortran implies that ifort and gfortran initialize tiny to 0.0 when compiled.

@andywood noted that the precision of the ascii state files has been increased since @anewman89 ran into the issue that required tiny in the first place. I am doing frequent restarts in my application, so I tested that a version of the code without tiny still has exact restarts. I did this by running two simulations from 2005-10-01 to 2006-09-30:

1. a continuous run for the entire period
2. a run that stops and restarts from a state file every day.

I compared the output files from the two scenarios, and they are equivalent. This suggests that for better reproducibility, tiny can and should be removed. Doing so is conveniently also truer to the original code.

compilation with ifort or gfortran

@andywood : I am trying to compile this model with either ifort or gfortran. In both cases, I get errors about elev being allocatable. The gfortran error was a little more descriptive:
Error: NAMELIST attribute conflicts with ALLOCATABLE attribute in 'elev' at (1). I'm pretty sure this tracks to lines 52 and 64 in def_namelists.f90. I suspect the same error will appear for the variable latitude once this is fixed. Is there a reason for latitude and elev to be ALLOCATABLE? or can they be real(dp), dimension(:)?