gfortran run-time errors for cm2015 dataset

[smalers]

I received an updated cm2015H.opr file from Kara that allowed me to run the model. Running with cm2015H -check results in the following. Note that 2013 is the last year in the run.

+ Data check for Year =  2013
At line 1171 of file outtbl.for
Fortran runtime error: Index '-2' of dimension 1 of array 'cresid' below lower bound of 1

Line 1171 of outtbl.for is the write statement below:

              if(irpt.eq.2) then
                write(19,632) n, nameo(k), ropnk(k),
     1          cresid(nr), resnam1(nr), itx
              endif
            endif

If I run cm2015H -sim, the following is shown:

  Subroutine Execut

+ Execut;  Year  1908 Month OCT
+ Execut;  Year  1908 Month NOV
+ Execut;  Year  1908 Month DEC
+ Execut;  Year  1909 Month JAN
   Stopped in Chekres, see log file (*.log)
 Stop 1

The log file has:

#
# CallDat; Call data for a right 0
#
#             # Year  Mon  Day Right        Iter   Divert af  Outflow af    Avail af   Bypass_af  Str_Type     Sta_ID       Sta_Name                 Comment
#          ____ ____ ____ ____ ____________ ____ ___________ ___________ ___________ ___________  ___________  ___________  ________________________ _________________________

  Chekres; Problem  Out of subrountine Evasec
           Delta =   4238.750

  Chekres; Input data:
  Iyr  Mon   Nr Cresid               Sum      Cursto       Delta
 ---- ---- ---- ------------ ----------- ----------- -----------
 1909    4    2 3603570         4490.000     251.250    4238.750

   ir  cursto(ir)
 ____ ___________
    7     2140.00
    8     2100.00
    9      250.00
 ____ ___________
T_Sum     4490.00
T_Res      251.25
 ____ ___________
Delta     4238.75
   Stopped in Chekres, see log file (*.log)

I did a comparison of the cm2015H.log file from 15.00.01 and 16.00.48 and see the following differences that may be an issue.

• New version has warnings about some operational rights - don't know if that is causing a run issue.
• Old version had more output to log file at end. New one does not have.

There was not really an indication in the log file of an issue.

[smalers]

Kara suggested trying different start year.

Regardless of iystr value (1909, 1930, 2010) , it seems to have an error in January of the first year in Evasec when simulating and in the last year in outtbl when running check.

  Mdainp; Instream flow Demand file - Annual (*.ifa)
  Subroutine Execut

+ Execut;  Year  1949 Month OCT
+ Execut;  Year  1949 Month NOV
+ Execut;  Year  1949 Month DEC
+ Execut;  Year  1950 Month JAN
   Stopped in Chekres, see log file (*.log)
 Stop 1

[smalers]

From Ray:

The outtbl.for (3/24/21 email) issue is a quick fix (nr = abs(iop...) just above line 1171. However the bigger issue is: 1)I’ve tried to get away from using a negative # as a code it’s a reservoir. There is probably only 1-2 that still use this logic. 2) ‘Outtbl.for’ has some great documentation stuff that may not be used much if at all once I left. Therefore it’s not up to speed with new operating rules.

So let me know if you want the quick fix (or do it yourself) while I scope what’s the required/best step forward while you dig into ‘chekres.for’ issues.

[smalers]

I made the change as instructed. I was able to run the cm2015H dataset with -check and -sim options. I ran the xwb report using Lahey executable that I had and latest gfortran and compared the results in kdiff3. Many of the numbers in the report are the same or different by a few digits, which should be the case especially for input files that are read and echoed in output. Other numbers are clearly quite a bit different and indicative of errors or compiler differences in the executable. Ray and I are looking into some other things and hopefully can track this down. The good news is that the binary files are the same size for old 32-bit and new 64-bit code. Note I had the images reversed before and using the more recent Lahey executable gives a closer comparison.

The following image is from the 64-bit gfortran 16.00.48 executable *.xwb output:

The following is the Lahey stateMod_160047 executable.

[Rayrbennett]

Good work Btw the 16.00.4z has a number of updates to the *.xwb report that became very apparent with the S Platte application. Therefore the comparison is apples to oranges from a number perspective.

You can get the 16.00.47 executable from the transfer site & just skip the -check run if you want something more meaningful.
Ray

Sent from my iPhone

On Mar 31, 2021, at 9:52 AM, Steve Malers @.***> wrote:

I made the change as instructed. I was able to run the cm2015H dataset with -check and -sim options. I ran the xwb report using Lahey 15 executable that I had and latest gfortran and compared the results in kdiff3. Many of the numbers in the report are the same or different by a few digits, which should be the case especially for input files that are read and echoed in output. Other numbers are clearly quite a bit different and indicative of errors in the executable. The images below illustrate that there is an issue with reservoirs ("Diversion to Storage" is zero for af/yr). Ray and I are looking into some other things and hopefully can track this down. The good news is that the binary files are the same size for old 32-bit and new 64-bit code.

The following image is from the 64-bit gfortran executable *.xwb output:

The following is the Lahey 15.01 executable.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[smalers]

I downloaded the stateMod_160047 file from the Google Drive and renamed to have .exe. The first time I ran it warned about opr so I had to copy the updated cm2015H.opr file to deal with change in rule 46 format. I assume that this is the Lahey version.

Then I was able to run the simulation and regenerate the cm2015H.xwb file. As Ray indicated, doing a comparison with this result is an apples to apples comparison. I am going to correct the images in my previous post to reflect this (can't edit both comments at the same time).

[smalers]

It appears that understanding how SAVE is handled may be important.  Based on my understanding, everything in the main program is where the variables global to the program are saved, which makes sense.  The combination of local variables in main (passed to subroutines), and common block data, form the "global" data.  Anything related to SAVE would then be dealing with other variables in subroutines that are initialized/saved in those routines.  The use of gfortran compiler option -fno-automatic (Lahey has -sav option?) seems to be bad practice and should perhaps be removed, but I don't know what implications that has. I tried recompiling StateMod without -fno-automatic. Running the cm2015H simulation gives the following and clearly indicates that the handling of SAVE with or without -fno-automatic is causing different behavior. Is it possible to not use the option and figure out what is going on?

  Mdainp; Instream flow Demand file - Annual (*.ifa)
  Subroutine Execut

+ Execut;  Year  1908 Month OCT
At line 1194 of file directwr.for
Fortran runtime error: Index '0' of dimension 1 of array 'imcdl' below lower bound of 1

The cm2015H.log file has:

________________________________________________________________________
  Mdainp; Soil Moisture Parameter File (format 2) *.str
     cm2015.str                                                                                                                                                                                                         
  Mdainp; rec256 = -1                                                                                                                                                                                                   

________________________________________________________________________
  Execut; Year =  1909

________________________________________________________________________
#
# CallDat; Call data for a right 0
#
#             # Year  Mon  Day Right        Iter   Divert af  Outflow af    Avail af   Bypass_af  Str_Type     Sta_ID       Sta_Name                 Comment
#          ____ ____ ____ ____ ____________ ____ ___________ ___________ ___________ ___________  ___________  ___________  ________________________ _________________________

If I use a MSys2/MinGW 64-bit window and run the gdb on the executable but it can't seem to dump a stack. Arg.

I tried running again using the menus. First I ran check, which worked OK. Then I ran simulate and got:

  Oprinp; Operational Right File (*.opr)
   Stopped in Chekts, see log file (*.log)
 Stop 1

The log file has:

________________________________________________________________________
  Mdainp; Instream Flow Demand - Monthly (*.ifm)
     cm2015.ifm                                                                                                                                                                                                         

  Chekts
  Chekts.f; Problem reading file #   25
    File name: Instream Flow Demand File - Monthly(*.ifm)   ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
    Problem record (next line):
 Chekts.f; End of file #   25 encountered
   File name: Instream Flow Demand File - Monthly(*.ifm)   ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
   Stopped in Chekts

The cm2015.ifm file does exist and has data. The first few lines are as follows.

# Years Shown = Water Years (Oct to Sep)
# The period of record for each time series may vary
# because of the original input and data processing steps.
#
#     TS ID                    Type   Source   Units  Period of Record    Location    Description
#   1 5300584P...MONTH         -      -        CFS    Oct/1908 - Sep/2013 5300584P    5300584, fillFromTS, sca
#   2 5104055_M...MONTH        -      -        CFS    Oct/1908 - Sep/2013 5104055_M   5104055_M, constant=0.00
#
#>EndHeader
#>
#> Yr ID            Oct     Nov     Dec     Jan     Feb     Mar     Apr     May     Jun     Jul     Aug     Sep     Average
#>-e-b----------eb------eb------eb------eb------eb------eb------eb------eb------eb------eb------eb------eb------eb--------e
   10/1908  -      9/2013  CFS  WYR
1909 5300584P          0.      0.      0.      0.      0.      0.      0.      0.    625.   1250.   1250.   1250.      365.
1909 5104055_M         0.      0.      0.      0.      0.      0.      0.      0.      0.      0.      0.      0.        0.
1910 5300584P       1250.      0.      0.      0.      0.      0.   1250.   1250.   1250.   1250.   1250.   1250.      729.

[Rayrbennett]

Have a good trip & time off. Please turn off the call data in *.ctl Don’t know why someone turns that on. Probably someone who thinks output is too big. I’d be quite surprised if they truly use data. I recall using the save command and You are right it is important.

I’ll look into:

1. Dimension issue for ‘imcdl’ (below)
2. Initilization &
3. Save command use.
   this weekend.

Sent from my iPhone

On Mar 31, 2021, at 12:47 PM, Steve Malers @.***> wrote:

It appears that understanding how SAVE is handled may be important. Based on my understanding, everything in the main program is where the variables global to the program are saved, which makes sense. The combination of local variables in main (passed to subroutines), and common block data, form the "global" data. Anything related to SAVE would then be dealing with other variables in subroutines that are initialized/saved in those routines. The use of gfortran compiler option -fno-automatic (Lahey has -sav option?) seems to be bad practice and should perhaps be removed, but I don't know what implications that has. I tried recompiling StateMod without -fno-automatic. Running the cm2015H simulation gives the following and clearly indicates that the handling of SAVE with or without -fno-automatic is causing different behavior. Is it possible to not use the option and figure out what is going on?

Mdainp; Instream flow Demand file - Annual (*.ifa) Subroutine Execut

• Execut; Year 1908 Month OCT At line 1194 of file directwr.for Fortran runtime error: Index '0' of dimension 1 of array 'imcdl' below lower bound of 1 The cm2015H.log file has:

---

Mdainp; Soil Moisture Parameter File (format 2) *.str cm2015.str
Mdainp; rec256 = -1

---

Execut; Year = 1909

---

#

CallDat; Call data for a right 0

#

Year Mon Day Right Iter Divert af Outflow af Avail af Bypass_af Str_Type Sta_ID Sta_Name Comment

____ ____ ____ _____

If I use a MSys2/MinGW 64-bit window and run the gdb on the executable but it can't seem to dump a stack. Arg.

I tried running again using the menus. First I ran check, which worked OK. Then I ran simulate and got:

Oprinp; Operational Right File (.opr) Stopped in Chekts, see log file (.log) Stop 1 The log file has:

---

Mdainp; Instream Flow Demand - Monthly (*.ifm) cm2015.ifm

Chekts Chekts.f; Problem reading file # 25 File name: Instream Flow Demand File - Monthly(.ifm) ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ Problem record (next line): Chekts.f; End of file # 25 encountered File name: Instream Flow Demand File - Monthly(.ifm) ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ Stopped in Chekts The cm2015.ifm file does exist and has data. The first few lines are as follows.

Years Shown = Water Years (Oct to Sep)

The period of record for each time series may vary

because of the original input and data processing steps.

#

TS ID Type Source Units Period of Record Location Description

1 5300584P...MONTH - - CFS Oct/1908 - Sep/2013 5300584P 5300584, fillFromTS, sca

2 5104055_M...MONTH - - CFS Oct/1908 - Sep/2013 5104055_M 5104055_M, constant=0.00

#

>EndHeader

>

> Yr ID Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep Average

>-e-b----------eb------eb------eb------eb------eb------eb------eb------eb------eb------eb------eb------eb------eb--------e

10/1908 - 9/2013 CFS WYR 1909 5300584P 0. 0. 0. 0. 0. 0. 0. 0. 625. 1250. 1250. 1250. 365. 1909 5104055_M 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 1910 5300584P 1250. 0. 0. 0. 0. 0. 1250. 1250. 1250. 1250. 1250. 1250. 729.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[smalers]

I figured out the compiler options to print all warnings.  The attached makefile (.txt added for GitHub issue) sets FFLAGS so that values are NOT automatically initialized to zero and SAVE is not automatically used globally.  The other FFLAGS are commented out and you can see the combinations.  Make sure to save a copy of the previous makefile before using the attached or be prepared to edit FFLAGS as needed.

# This generally works but has some issues at runtime that cause different results and are still being resolved
#FFLAGS = -g -cpp -DCOMPILER=$(COMPILER_ENUM) -fno-align-commons -static -fcheck=bounds -fno-automatic -finit-local-zero $(FFLAGS_ARCH) $(FFLAGS_EXTRA_CHECKS)
# Try removing -fno-automatic, results in runtime errors
#FFLAGS = -g -cpp -DCOMPILER=$(COMPILER_ENUM) -fno-align-commons -static -fcheck=bounds -finit-local-zero $(FFLAGS_ARCH) $(FFLAGS_EXTRA_CHECKS)
# Try removing -fno-automatic and -finit-local-zero and print warnings for uninitialized data
FFLAGS = -g -O1 -Wall -cpp -DCOMPILER=$(COMPILER_ENUM) -fno-align-commons -static -fcheck=bounds $(FFLAGS_ARCH) $(FFLAGS_EXTRA_CHECKS)

Do the compile with something similar to the following to save the output to a file:

make -k statemod 2>&1 | tee statemod-compile-log.txt

Also attached is the log file for the compile result.  Although it is 10,000 lines, the warnings are pretty verbose and repetitive.  Some of the warnings are related to code formatting such as using tabs at the beginning of lines and after column 72 getting truncated.  There are also some warnings specific to logic, for example the following. In this case, if -f-init-local-zero is used, the value of nx would be set to zero and the iteration would always loop from j=1,0 so the code would be ineffective.

bintop.for:417:0:

  417 |           read(nf,rec=j1,err=900) (cunitX(j), j=1,nx)
      |
Warning: 'nx' may be used uninitialized in this function [-Wmaybe-uninitialized]

In this case, the code (below) is probably OK because the if statements cover normal situations. However, to make the compiler happy and prevent coding issues, the code could be changed to if and else if with a trailing else that says something like "Invalid nf value".

c rrb 2005/12/02; Diversion Units
          if(nf.eq.43 .or. nf.eq.49) nx=ndiv
          if(nf.eq.44 .or. nf.eq.50) nx=nres
          if(nf.eq.42 .or. nf.eq.65) nx=ndivw

          j1=j1+1
          read(nf,rec=j1,err=900) (cunitX(j), j=1,nx)

makefile.txt statemod-compile-log.zip

[smalers]

I am cleaning up the code for warnings related to tabs. Below is an example of where this COULD be an issue (but compiler generates executables so it must have some smarts for dealing with tabs, for example auto-converting to 8 characters during compiling). In the following example, the blue indicates tabs and the red indicates a potential problem. In this case there are 4 spaces following the tab. The code normally starts in column 7 so depending on how the tab is expanded, the endif may not be starting in the correct column. Cleaning up such code allows the warnings from -O1 -Wall to receive more scrutiny. This example is calldat.for near line 176.

[smalers]

I updated the code to fix all tab format warnings, which greatly decreased the number of warnings. I also wrote a script count-warnings.bash to summarize warnings from the compile, with output as follows;

Count : Warning text
=====   ============================================================
24 : CHARACTER expression will be truncated
1 : is used uninitialized
634 : Label xxx at (y) defined but not used
6 : Line truncated
204 : may be used uninitialized
114 : Possible change of value
86 : Unused dummy argument
237 : Unused variable

1306 : Warning

Unaccounted for warnings : 0

The warnings can be addressed as follows, with recommendations in bold. The warnings may help resolve remaining differences between Lahey and gfortran executable output.

• CHARACTER expressions... - declare string with larger size
• is used uninitialized - only one case so should initialize
• Label...defined but not used
  • remove if truly unused
  • comment out if may be used in the future
  • add IF statements that use the label only in certain situations, such as IF ( debug...)
• may be used uninitialized - probably should fix but can continued to use -finit-local-zero if necessary
• Possible change of value
  • For REAL to INT can better ensure result if add a small number like .000001, for example to ensure that 1 results from 1.000001 rather than internal .9999999 value, and would need to subtract .0000001 if the number is negative.
  • For REAL(8) to REAL(4) may be OK but may need to use REAL(8) more if precision needs to be retained.
  • Unused dummy argument - may be a symptom of logic not being implemented as assumed in which case need to check logic
  • Unused variable - likely old code in which case need to remove unused code

[smalers]

I ran the latest gfortran executable on the cm2015H dataset and am now getting the error in Checkres as originally reported. I am not sure why the code ran through at one point and hopefully I did not confuse something in reporting previous success.

I set iout=1 in the checkres.for code (is there any way to set this without changing code?) and added an additional write statement. The log file output is below. Given that reservoir 3603570 is the second reservoir from the input file, I suspect it has something to do with how values are being initialized due to behavior of -finit-local-zero and -fno-automatic. The gfortran release notes have the following for version 4.9 (current compiler is 10.2): "GNU Fortran no longer deallocates allocatable variables or allocatable components of variables declared in the main program. The Fortran standard states since 2008 explicitly that variables declared in the Fortran main program automatically have the SAVE attribute." This makes sense because variables in the main program should be initialized once and then only be modified by code in the main program or subroutine calls. It would be really great to not have to use these options but they are apparently also used similarly with Lahey version so the code should ideally be equivalent.

As an experiment, I edited the cm2015.res file and moved the offending reservoir to the top. The program did run through more data but stopped at the same output. Note in the second output that NaN (not a number) is shown for some cursto values. I don't know everything that the code is doing but it looks like focusing on how cursto is handled is a good place to focus. The -Wall compile does show the following related to cursto:

Warning: Possible change of value in conversion from REAL(4) to INTEGER(4) at (1) [-Wconversion]
divres.for:1265:0:

 1265 |      1      divreq1*fac, (divcap(nd)-divmon(nd))*fac, cursto1,

The code is log output and it looks like the format for the first item output may not be of the correct type that could result in unexpected log output. This would not cause the original issue being encountered but is an indication of clean-up related to the compiler warnings.

My next step is to write a simple test program to see how the -finit-local-zero and -fno-automatic options work with each other and then focus on cursto handling. I want to do a visual inspection with kdiff3 of changes I made for tab formatting to make sure nothing was inadvertently changed and will then commit that code so others can see. It may take a few days given other priorities.

Original Data Order

  Chekres; Input data:
  Iyr  Mon   Nr Cresid               Sum      Cursto       Delta
 ---- ---- ---- ------------ ----------- ----------- -----------
 1909    4    2 3603570          250.000     251.250       1.250

  ChekRes; iyr, mon, nr, cresid(nr),iri,ire
  ChekRes;        1909           4           2 3603570                7           9
   Chekres: cresid(nr), nr, ir, curown(ir), sum
   Chekres: 3603570                2           7   2140.00000       2140.00000
   Chekres: cresid(nr), nr, ir, curown(ir), sum
   Chekres: 3603570                2           8   2100.00000       4240.00000
   Chekres: cresid(nr), nr, ir, curown(ir), sum
   Chekres: 3603570                2           9   250.000000       4490.00000

  Chekres;  FYI     Out of subroutine Evasec
           Delta =   4238.750

  Chekres; Input data:
  Iyr  Mon   Nr Cresid               Sum      Cursto       Delta
 ---- ---- ---- ------------ ----------- ----------- -----------
 1909    4    2 3603570         4490.000     251.250    4238.750

 Checkres; Problem x (     4238.75) > small2(       10.00)

  Chekres; Problem  Out of subroutine Evasec
           Delta =   4238.750

  Chekres; Input data:
  Iyr  Mon   Nr Cresid               Sum      Cursto       Delta
 ---- ---- ---- ------------ ----------- ----------- -----------
 1909    4    2 3603570         4490.000     251.250    4238.750

   ir  cursto(ir)
 ____ ___________
    7     2140.00
    8     2100.00
    9      250.00
 ____ ___________
T_Sum     4490.00
T_Res      251.25
 ____ ___________
Delta     4238.75
   Stopped in Chekres, see log file (*.log)

With 3603570 moved to top of cm2015.res File

  Chekres;  FYI     Out of subroutine Divres
           Delta =      0.000

  Chekres; Input data:
  Iyr  Mon   Nr Cresid               Sum      Cursto       Delta
 ---- ---- ---- ------------ ----------- ----------- -----------
 1909    4    3 3603575            0.000       0.000       0.000

  ChekRes; iyr, mon, nr, cresid(nr),iri,ire
  ChekRes;        1909           4           1 3603570                1           3
   Chekres: cresid(nr), nr, ir, curown(ir), sum
   Chekres: 3603570                1           1              NaN   0.00000000
   Chekres: cresid(nr), nr, ir, curown(ir), sum
   Chekres: 3603570                1           2              NaN   0.00000000
   Chekres: cresid(nr), nr, ir, curown(ir), sum
   Chekres: 3603570                1           3   250.000000       250.000000

________________________________________________________________________________

  Chekres;  FYI     Into   subroutine Evasec
           Delta =      1.250

  Chekres; Input data:
  Iyr  Mon   Nr Cresid               Sum      Cursto       Delta
 ---- ---- ---- ------------ ----------- ----------- -----------
 1909    4    1 3603570          250.000     251.250       1.250

  ChekRes; iyr, mon, nr, cresid(nr),iri,ire
  ChekRes;        1909           4           1 3603570                1           3
   Chekres: cresid(nr), nr, ir, curown(ir), sum
   Chekres: 3603570                1           1   2140.00000       2140.00000
   Chekres: cresid(nr), nr, ir, curown(ir), sum
   Chekres: 3603570                1           2   2100.00000       4240.00000
   Chekres: cresid(nr), nr, ir, curown(ir), sum
   Chekres: 3603570                1           3   250.000000       4490.00000

  Chekres;  FYI     Out of subroutine Evasec

... other output omitted ...

  Chekres;  FYI     Into   subroutine Evasec
           Delta =      1.250

  Chekres; Input data:
  Iyr  Mon   Nr Cresid               Sum      Cursto       Delta
 ---- ---- ---- ------------ ----------- ----------- -----------
 1909    4    1 3603570          250.000     251.250       1.250

  ChekRes; iyr, mon, nr, cresid(nr),iri,ire
  ChekRes;        1909           4           1 3603570                1           3
   Chekres: cresid(nr), nr, ir, curown(ir), sum
   Chekres: 3603570                1           1   2140.00000       2140.00000
   Chekres: cresid(nr), nr, ir, curown(ir), sum
   Chekres: 3603570                1           2   2100.00000       4240.00000
   Chekres: cresid(nr), nr, ir, curown(ir), sum
   Chekres: 3603570                1           3   250.000000       4490.00000

  Chekres;  FYI     Out of subroutine Evasec
           Delta =   4238.750

  Chekres; Input data:
  Iyr  Mon   Nr Cresid               Sum      Cursto       Delta
 ---- ---- ---- ------------ ----------- ----------- -----------
 1909    4    1 3603570         4490.000     251.250    4238.750

 Checkres; Problem x (     4238.75) > small2(       10.00)

  Chekres; Problem  Out of subroutine Evasec
           Delta =   4238.750

  Chekres; Input data:
  Iyr  Mon   Nr Cresid               Sum      Cursto       Delta
 ---- ---- ---- ------------ ----------- ----------- -----------
 1909    4    1 3603570         4490.000     251.250    4238.750

   ir  cursto(ir)
 ____ ___________
    1     2140.00
    2     2100.00
    3      250.00
 ____ ___________
T_Sum     4490.00
T_Res      251.25
 ____ ___________
Delta     4238.75
   Stopped in Chekres, see log file (*.log)

[Rayrbennett]

Re running once w/o error & later not running is a key indicator to me that there is something in the compiler or code providing unreliable results (we already knew that).

Re set iout= 1 in chekres you can make that one of many detailed options available in the control file. I typically don’t do that for something like this (debugging) unless I expect it to be useful in the future. Ps you’ll see the variable iout is used in just about every operating rule. I did this to help during development.

Ray

Sent from my iPhone

On Apr 7, 2021, at 9:49 AM, Steve Malers @.***> wrote:

I ran the latest gfortran executable on the cm2015H dataset and am now getting the error in Checkres as originally reported. I am not sure why the code ran through at one point and hopefully I did not confuse something in reporting previous success.

I set iout=1 in the checkres.for code (is there any way to set this without changing code?) and added an additional write statement. The log file output is below. Given that reservoir 3603570 is the second reservoir from the input file, I suspect it has something to do with how values are being initialized due to behavior of -finit-local-zero and -fno-automatic. The gfortran release notes have the following for version 4.9 (current compiler is 10.2): "GNU Fortran no longer deallocates allocatable variables or allocatable components of variables declared in the main program. The Fortran standard states since 2008 explicitly that variables declared in the Fortran main program automatically have the SAVE attribute." This makes sense because variables in the main program should be initialized once and then only be modified by code in the main program or subroutine calls. It would be really great to not have to use these options but they are apparently also used similarly with Lahey version so the code should ideally be equivalent.

As an experiment, I edited the cm2015.res file and moved the offending reservoir to the top. The program did run through more data but stopped at the same output. Note in the second output that NaN (not a number) is shown for some cursto values. I don't know everything that the code is doing but it looks like focusing on how cursto is handled is a good place to focus. The -Wall compile does show the following related to cursto:

Warning: Possible change of value in conversion from REAL(4) to INTEGER(4) at (1) [-Wconversion] divres.for:1265:0:

1265 | 1 divreq1fac, (divcap(nd)-divmon(nd))fac, cursto1, The code is log output and it looks like the format for the first item output may not be of the correct type that could result in unexpected log output. This would not cause the original issue being encountered but is an indication of clean-up related to the compiler warnings.

My next step is to write a simple test program to see how the -finit-local-zero and -fno-automatic options work with each other and then focus on cursto handling. I want to do a visual inspection with kdiff3 of changes I made for tab formatting to make sure nothing was inadvertently changed and will then commit that code so others can see. It may take a few days given other priorities.

Original Data Order

Chekres; Input data: Iyr Mon Nr Cresid Sum Cursto Delta

---

1909 4 2 3603570 250.000 251.250 1.250

ChekRes; iyr, mon, nr, cresid(nr),iri,ire ChekRes; 1909 4 2 3603570 7 9 Chekres: cresid(nr), nr, ir, curown(ir), sum Chekres: 3603570 2 7 2140.00000 2140.00000 Chekres: cresid(nr), nr, ir, curown(ir), sum Chekres: 3603570 2 8 2100.00000 4240.00000 Chekres: cresid(nr), nr, ir, curown(ir), sum Chekres: 3603570 2 9 250.000000 4490.00000

Chekres; FYI Out of subroutine Evasec Delta = 4238.750

Chekres; Input data: Iyr Mon Nr Cresid Sum Cursto Delta

---

1909 4 2 3603570 4490.000 251.250 4238.750

Checkres; Problem x ( 4238.75) > small2( 10.00)

Chekres; Problem Out of subroutine Evasec Delta = 4238.750

Chekres; Input data: Iyr Mon Nr Cresid Sum Cursto Delta

---

1909 4 2 3603570 4490.000 251.250 4238.750

ir cursto(ir)

---

7     2140.00
8     2100.00
9      250.00

---

T_Sum 4490.00 T_Res 251.25

---

Delta 4238.75 Stopped in Chekres, see log file (*.log) With 3603570 moved to top of cm2015.res File

Chekres; FYI Out of subroutine Divres Delta = 0.000

Chekres; Input data: Iyr Mon Nr Cresid Sum Cursto Delta

---

1909 4 3 3603575 0.000 0.000 0.000

ChekRes; iyr, mon, nr, cresid(nr),iri,ire ChekRes; 1909 4 1 3603570 1 3 Chekres: cresid(nr), nr, ir, curown(ir), sum Chekres: 3603570 1 1 NaN 0.00000000 Chekres: cresid(nr), nr, ir, curown(ir), sum Chekres: 3603570 1 2 NaN 0.00000000 Chekres: cresid(nr), nr, ir, curown(ir), sum Chekres: 3603570 1 3 250.000000 250.000000

---

Chekres; FYI Into subroutine Evasec Delta = 1.250

Chekres; Input data: Iyr Mon Nr Cresid Sum Cursto Delta

---

1909 4 1 3603570 250.000 251.250 1.250

ChekRes; iyr, mon, nr, cresid(nr),iri,ire ChekRes; 1909 4 1 3603570 1 3 Chekres: cresid(nr), nr, ir, curown(ir), sum Chekres: 3603570 1 1 2140.00000 2140.00000 Chekres: cresid(nr), nr, ir, curown(ir), sum Chekres: 3603570 1 2 2100.00000 4240.00000 Chekres: cresid(nr), nr, ir, curown(ir), sum Chekres: 3603570 1 3 250.000000 4490.00000

Chekres; FYI Out of subroutine Evasec

... other output omitted ...

Chekres; FYI Into subroutine Evasec Delta = 1.250

Chekres; Input data: Iyr Mon Nr Cresid Sum Cursto Delta

---

1909 4 1 3603570 250.000 251.250 1.250

ChekRes; iyr, mon, nr, cresid(nr),iri,ire ChekRes; 1909 4 1 3603570 1 3 Chekres: cresid(nr), nr, ir, curown(ir), sum Chekres: 3603570 1 1 2140.00000 2140.00000 Chekres: cresid(nr), nr, ir, curown(ir), sum Chekres: 3603570 1 2 2100.00000 4240.00000 Chekres: cresid(nr), nr, ir, curown(ir), sum Chekres: 3603570 1 3 250.000000 4490.00000

Chekres; FYI Out of subroutine Evasec Delta = 4238.750

Chekres; Input data: Iyr Mon Nr Cresid Sum Cursto Delta

---

1909 4 1 3603570 4490.000 251.250 4238.750

Checkres; Problem x ( 4238.75) > small2( 10.00)

Chekres; Problem Out of subroutine Evasec Delta = 4238.750

Chekres; Input data: Iyr Mon Nr Cresid Sum Cursto Delta

---

1909 4 1 3603570 4490.000 251.250 4238.750

ir cursto(ir)

---

1     2140.00
2     2100.00
3      250.00

---

T_Sum 4490.00 T_Res 251.25

---

Delta 4238.75 Stopped in Chekres, see log file (*.log) — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[smalers]

I had a call with Ray about some specific warnings and code cleanup, listed below:

File	Line	Comment
daydata.for	74	Extra code on far right can be removed since has no effect.
dayoutr.for	992	Daily well variable totox was not being output due to being in column 72. Align code so that it is output. Perhaps nobody is looking at daily well output from simulations?
divres2.for	811	In log message, variable ndns26 is being cut of since sliced by column 72. Output is likely 0 or in error. Fix so variable is output.
oopbook2.for	672	Extra code on far right can be removed since has no effect.
outsyt.for	50	Extra code on far right can be removed since has no effect.
outsyta.for	69	Extra code on far right can be removed since has no effect.

The following code is updated to increase string length to avoid truncation. Ray recommended using 45, which I did unless that was insufficient, in which case I set to the necessary string length.

File	Line	Comment
divalt.for	127	Change cwhy size to 50 to store longest literal string, and fix format for output.
divcar1.for	142	Change cwhy size to 51 to store longest literal string, and fix format for output.
divcarl.for	375	Change cwhy size to 51 to store longest literal string, and fix format for output.
divimpr.for	145	Change cwhy size to 45 to store longest literal string, and fix format for output. Also fix near line 227 to fit cSouTyp within 12 characters.
divimpr2.for	129	Change cwhy size to 45 to store longest literal string, and fix format for output.
divresp2.for	350	Change cwhy size to 45 to store longest literal string, and fix format for output.
divresr.for	243	Change cwhy size to 45 to store longest literal string, and fix format for output. Seems like format 280 has extra numbers at end?
divrplr.for	221	Change cwhy size to 45 to store longest literal string, and fix format for output.
oopbook2.for	61	Change cwhy size to 51 to store longest literal string, and fix format for output.
resrg1p.for	76	Change cwhy size to 45 to store longest literal string, and fix format for output.
resrpl.for	76	Change cwhy size to 50 to store longest literal string, and fix format for output.
reportl.for		Change rec32 to rec39 and change length to 39 to avoid truncation.

After changing the above, run:

make veryclean
make -k statemod 2>&1 | tee statemod-compile.log
./count-warnings.bash

which outputs the following. The remaining warnings of concern are mainly related to variable initialization, which if fixed will make the code more robust. Unused labels and variables can be removed or commented out. Possible change of value may or may not be an issue but could be an issue when converting real to/from integer. I am going to do a visual review of the cleaned up code using kdiff3, in particular to make sure tab cleanup did not change anything, and then commit the code and give a copy to Ray Bennett so he can evaluate additional warnings.

Count : Warning text
=====   ============================================================
0 : CHARACTER expression will be truncated
1 : is used uninitialized
634 : Label xxx at (y) defined but not used
0 : Line truncated
204 : may be used uninitialized
114 : Possible change of value
86 : Unused dummy argument
237 : Unused variable

1276 : Warning

Unaccounted for warnings : 0

[smalers]

Ray Bennett provided updated files that address all compiler warnings. I'm using kdiff3 to compare each file and then copy into the repository working files. Below are specific comments as I do the integration. Other cleanup was done such as initializing variables and commenting out unused format statement lines. I'm mainly commenting on things that may need additional attention and only files with such comments are listed below.

The following issues where a variable is set to itself seem strange. Why would that be done rather than initializing to zero or other typical initial value? If I uncomment the line in chekav2.for a warning is generated about unused argument. The assignment to itself is one way to avoid this warning but a comment should be added at a minimum explaining why the assignment is being done like this. I can see how the compiler might in the future complain about this because many compilers do.

chekav2.for:27:12:

   27 |      1 icall, maxsta, numsta, istop, fac, AVAIL, IMCD, AvMin, subtypX)
      |            1
Warning: Unused dummy argument 'icall' at (1) [-Wunused-dummy-argument]

An alternative is something like the following, or add a check that legitimately checks the input argument for valid value. A question is, why is the argument is not used and should it be removed from the code, perhaps not now but in the future?

      if ( icall < 0 ) then
        write(*,*) 'statement avoids warning about unused argument'
      endif

File	Comment
accdiv.for and others	Need to correct typo initilize in over 40 files but don't want to fix yet because will show as file difference.
bomsec.for	Ray changed inextar to rnextar to avoid casting roundoff. Seems OK.
chekav2.for	Line 73 has icall = icall. This looks like an error because the variable is assigned to itself. Am I missing something?
chekava.for	Line 69 has icall = icall. This looks like an error because the variable is assigned to itself.
chekpor.for	Line 93 has rec3 = rec3. This looks like an error because the variable is assigned to itself.
chekts.for	Line 156 has variables assigned to self.
datinp.for	Line 151 has variables assigned to self.
daydivo.for	Line 208 has the same 2 lines twice.
Multiple files.	Ray updated to use current intrinsic functions such as max and nint. The new code is better. I'm not sure why nint is needed for some array indexes such as in daydivo.for and if that changes the logic from before.
dayest.for	Line 94 has variable assigned to self.
demand.for	Line 102 has variable assigned to self.
directfs.for	Line 99 has variable assigned to self.
divres.for	Line 841 commented code was changed by mistake from 100 to 10 value. Fix to have correct history.
divrplp.for	Line 368 has variable assigned to self.
getdiv.for	Line 59 has variable assigned to self.
getdiv2.for	Line 82 has variable assigned to self.
getfile.for	Line 56 has variable assigned to self.
getpln.for	Line 60 has variable assigned to self.
getplnw.for	Line 297 uses SNGL - maybe should use REAL?.
getres.for	Line 108 has variable assigned to self.
getres2.for	Line 103 has variable assigned to self.
getrtn.for	Line 73 has variable assigned to self.
getrtn2.for	Line 78 has variable assigned to self.
getrtnw2.for	Line 78 has variable assigned to self.
getrtnx.for	Line 140 has variable assigned to self.
getwel.for	Line 64 has variable assigned to self.
getwel2.for	Line 72 has variable assigned to self.
Various	A few places, Ray added commas in write commands - OK. Not sure if that fixed any runtime issues.
oprfind.for	Line 122 has variable assigned to self.
outdivc.for	Line 1334 has variable assigned to self.
outgvc.for	Line 45 has variable assigned to self.
outichk.for	Line 48 has variable assigned to self.
outplnd.for	Line 53 has variable assigned to self.
outwelp.for	Lines at the end could be simplified with simple IF rather than using GOTO to STOP.
outwr2.for	Line 65 has variable assigned to self.
parse.for	Line 125 has variable assigned to self.
powresp.for	Line 128 has variable assigned to self.
powsea.for	Line 63 has variable assigned to self.
powseap.for	Line 155 has variable assigned to self.
resrg1p.for	Line 72 has variable assigned to self.
return2.for	Line 124 has variable assigned to self.
rivrtn.for	Line 133 has variable assigned to self.
rtncarry.for	Line 79 has variable assigned to self.
rtnmax.for	Line 103 has variable assigned to self.
rtnmaxe.for	Line 88 has variable assigned to self.
rtnsecw.for	Line 142 has variable assigned to self.
rtnsecwp.for	Line 164 has variable assigned to self.
setdem.for	Line 47 has variable assigned to self.
setgw.for	Line 41 has variable assigned to self.
setloss.for	Line 99 has variable assigned to self.
setqdiv.for	Line 13 has variable assigned to self.
setqdivc.for	Line 103 has variable assigned to self.
setqdivx.for	Line 104 has variable assigned to self.
takou2.for	Line 46 has variable assigned to self.
takout.for	Line 61 has variable assigned to self.
welrig3.for	Line 151 has variable assigned to self.
year2.for	Line 45 has variable assigned to self.
Multiple	Ray inserted spaces for alignment, such as in comments, but tabs are on the same line. Should use all spaces when there is time to change.

The following seem to be used for development and will only be an issue if the developer forgets to change the variable back to zero value.

File	Comment
bomsec.for	Initializes iexit to zero and then immediately checks for nonzero.
carrpl.for	Initializes iexit to zero and then immediately checks for nonzero.
chkver.for	Line 49 iprob is set to zero and then immediately checks for > zero.
coeffa.for	Initializes iexit to zero and then immediately checks for nonzero.
divresr.for	Initializes iexit to zero and then immediately checks for nonzero.
divrplp2.for	Initializes iexit to zero and then immediately checks for nonzero.
divrplr.for	Initializes iprob to zero and then immediately checks for nonzero.
FlowRes.for	Initializes iprob to zero and then immediately checks for nonzero.
getfn.for	Initializes iexit to zero and then immediately checks for nonzero.
FMFlow.for	Initializes iexit to zero and then immediately checks for nonzero.
outcalls.for	Initializes iexit to zero and then immediately checks for nonzero.
outdiv2.for	Initializes iexit to zero and then immediately checks for nonzero.
OutJM.for	Initializes iexit to zero and then immediately checks for nonzero.
outmon.for	Initializes iexit to zero and then immediately checks for nonzero.
outpln.for	Initializes iprob to zero and then immediately checks for nonzero.
outrev.for	Initializes iexit to zero and then immediately checks for nonzero.
outplnmo.for	Initializes iprob to zero and then immediately checks for nonzero.
outwel.for	Initializes iexit to zero and then immediately checks for nonzero.
outwelp.for	Initializes iprob to zero and then immediately checks for nonzero.
outWW.for	Initializes iprob to zero and then immediately checks for nonzero.
outxssmo.for	Initializes iprob to zero and then immediately checks for nonzero.
replace.for	Initializes iprob to zero and then immediately checks for nonzero.
rigsor.for	Initializes iprob to zero and then immediately checks for nonzero.
rtnsecp.for	Initializes iprob to zero and then immediately checks for nonzero.
somnmy.for	Initializes iprob to zero and then immediately checks for nonzero.
splatte.for	Initializes iexit to zero and then immediately checks for nonzero.
welaugp.for	Initializes iexit to zero and then immediately checks for nonzero.
xdebug.for	Initializes iprob to zero and then immediately checks for nonzero.

After making the changes I did a veryclean 64-bit gfortran compile and have zero warnings.

Ray subsequently provided updates for divres.for, dnmfso.for, and dnmfso2.for with minor changes so I added those. When I try to run the resulting executable on the cm2015H dataset (sim), I get the following. The random value of index indicates that iuse is not getting set properly.

  Subroutine Execut

+ Execut;  Year  1908 Month OCT
+ Execut;  Year  1908 Month NOV
+ Execut;  Year  1908 Month DEC
+ Execut;  Year  1909 Month JAN
+ Execut;  Year  1909 Month FEB
+ Execut;  Year  1909 Month MAR
At line 535 of file divres.for
Fortran runtime error: Index '1818306592' of dimension 1 of array 'divreq' above upper bound of 3060

Error termination. Backtrace:

Could not print backtrace: libbacktrace could not find executable to open
#0  0x42c10b
#1  0x4252b4
#2  0x42146b
#3  0x26143e
#4  0x1cee52
#5  0x1c2fdb
#6  0x1c3205
#7  0x1c13c0
#8  0x1c14f5
#9  0x9bb7033
#10  0xb3c2650
#11  0xffffffff

I also tried the 32-bit gfortran compile. This has a single warning as follows. I don't know why this is not printed with 64-bit compile.

outresc.for:407:0:

  407 |           write(114,271) cresid(ir),(dum(13,j)/ryx,j=1,4), resnam1(ir)
      |
Warning: 'ryx' may be used uninitialized in this function [-Wmaybe-uninitialized]

Running the 32-bit executable gives the same error location s 64-bit executable.

[smalers]

If I add -fno-automatic to FFLAGS the 64-bit executable runs through and I was able to do an xwb report. However, given my comments above and the unpredictable nature of errors when dealing with memory initialization, this success may not be robust. If SAVE is needed, it should be added to the declaration of specific variables, and not used for all local variables by default.

Also, see the following:

https://gcc.gnu.org/onlinedocs/gfortran/Old-style-variable-initialization.html

If variables are initialized when declared, then they automatically use SAVE. However, I think that all the initialization that StateMod code has for subroutine local variables uses initialization after declaration so SAFE would not automatically be used. This behavior would need to be compared with Lahey compiler. If variables really need to have their values saved between calls, the code should declare them with SAVE rather than rely on how initialized.

I need to work with Ray to see what is going on.

[Rayrbennett]

A couple of notes:

1. I tried to Set a variable to itself when it’s passed thru the calling statement. I don’t want rhem to suddenly get set to 0 just because they are part of a somewhat generic call statement. If they got set to 0 This is a potential concern to me.

2. I use mint to change a real to an integer. I think this is generic & works but maybe not.

3. My standard is use 9999 as an error to stop & 500 as a hard return. So I reinforced that even if the hard exit or error are currently commented out. Jensen I used ‘iexit’ & ‘istop’ to keep them available. Ray

Open to discuss if you want.

Sent from my iPhone

On Apr 26, 2021, at 6:08 AM, Steve Malers @.***> wrote:

Ray Bennett provided updated files that address all compiler warnings. I'm using kdiff3 to compare each file and then copy into the repository working files. Below are specific comments as I do the integration. Other cleanup was done such as initializing variables and commenting out unused format statement lines. I'm mainly commenting on things that may need additional attention and only files with such comments are listed below.

The following issues where a variable is set to itself seem strange. Why would that be done rather than initializing to zero or other typical initial value?

File Comment accdiv.for and others Need to correct typo initilize in over 40 files but don't want to fix yet because will show as file difference. bomsec.for Ray changed inextar to rnextar to avoid casting roundoff. Seems OK. chekav2.for Line 73 has icall = icall. This looks like an error because the variable is assigned to itself. Am I missing something? chekava.for Line 69 has icall = icall. This looks like an error because the variable is assigned to itself. chekpor.for Line 93 has rec3 = rec3. This looks like an error because the variable is assigned to itself. chekts.for Line 156 has variables assigned to self. datinp.for Line 151 has variables assigned to self. daydivo.for Line 208 has the same 2 lines twice. Multiple files. Ray updated to use current intrinsic functions such as max and nint. The new code is better. I'm not sure why nint is needed for some array indexes such as in daydivo.for and if that changes the logic from before. dayest.for Line 94 has variable assigned to self. demand.for Line 102 has variable assigned to self. directfs.for Line 99 has variable assigned to self. divres.for Line 841 commented code was changed by mistake from 100 to 10 value. Fix to have correct history. divrplp.for Line 368 has variable assigned to self. getdiv.for Line 59 has variable assigned to self. getdiv2.for Line 82 has variable assigned to self. getfile.for Line 56 has variable assigned to self. getpln.for Line 60 has variable assigned to self. getplnw.for Line 297 uses SNGL - maybe should use REAL?. getres.for Line 108 has variable assigned to self. getres2.for Line 103 has variable assigned to self. getrtn.for Line 73 has variable assigned to self. getrtn2.for Line 78 has variable assigned to self. getrtnw2.for Line 78 has variable assigned to self. getrtnx.for Line 140 has variable assigned to self. getwel.for Line 64 has variable assigned to self. getwel2.for Line 72 has variable assigned to self. Various A few places, Ray added commas in write commands - OK. Not sure if that fixed any runtime issues. oprfind.for Line 122 has variable assigned to self. outdivc.for Line 1334 has variable assigned to self. outgvc.for Line 45 has variable assigned to self. outichk.for Line 48 has variable assigned to self. outplnd.for Line 53 has variable assigned to self. outwelp.for Lines at the end could be simplified with simple IF rather than using GOTO to STOP. outwr2.for Line 65 has variable assigned to self. parse.for Line 125 has variable assigned to self. powresp.for Line 128 has variable assigned to self. powsea.for Line 63 has variable assigned to self. powseap.for Line 155 has variable assigned to self. resrg1p.for Line 72 has variable assigned to self. return2.for Line 124 has variable assigned to self. rivrtn.for Line 133 has variable assigned to self. rtncarry.for Line 79 has variable assigned to self. rtnmax.for Line 103 has variable assigned to self. rtnmaxe.for Line 88 has variable assigned to self. rtnsecw.for Line 142 has variable assigned to self. rtnsecwp.for Line 164 has variable assigned to self. setdem.for Line 47 has variable assigned to self. setgw.for Line 41 has variable assigned to self. setloss.for Line 99 has variable assigned to self. setqdiv.for Line 13 has variable assigned to self. setqdivc.for Line 103 has variable assigned to self. setqdivx.for Line 104 has variable assigned to self. takou2.for Line 46 has variable assigned to self. takout.for Line 61 has variable assigned to self. welrig3.for Line 151 has variable assigned to self. year2.for Line 45 has variable assigned to self. Multiple Ray inserted spaces for alignment, such as in comments, but tabs are on the same line. Should use all spaces when there is time to change. The following seem to be used for development and will only be an issue if the developer forgets to change the variable back to zero value.

File Comment bomsec.for Initializes iexit to zero and then immediately checks for nonzero. carrpl.for Initializes iexit to zero and then immediately checks for nonzero. chkver.for Line 49 iprob is set to zero and then immediately checks for > zero. coeffa.for Initializes iexit to zero and then immediately checks for nonzero. divresr.for Initializes iexit to zero and then immediately checks for nonzero. divrplp2.for Initializes iexit to zero and then immediately checks for nonzero. divrplr.for Initializes iprob to zero and then immediately checks for nonzero. FlowRes.for Initializes iprob to zero and then immediately checks for nonzero. getfn.for Initializes iexit to zero and then immediately checks for nonzero. FMFlow.for Initializes iexit to zero and then immediately checks for nonzero. outcalls.for Initializes iexit to zero and then immediately checks for nonzero. outdiv2.for Initializes iexit to zero and then immediately checks for nonzero. OutJM.for Initializes iexit to zero and then immediately checks for nonzero. outmon.for Initializes iexit to zero and then immediately checks for nonzero. outpln.for Initializes iprob to zero and then immediately checks for nonzero. outrev.for Initializes iexit to zero and then immediately checks for nonzero. outplnmo.for Initializes iprob to zero and then immediately checks for nonzero. outwel.for Initializes iexit to zero and then immediately checks for nonzero. outwelp.for Initializes iprob to zero and then immediately checks for nonzero. outWW.for Initializes iprob to zero and then immediately checks for nonzero. outxssmo.for Initializes iprob to zero and then immediately checks for nonzero. replace.for Initializes iprob to zero and then immediately checks for nonzero. rigsor.for Initializes iprob to zero and then immediately checks for nonzero. rtnsecp.for Initializes iprob to zero and then immediately checks for nonzero. somnmy.for Initializes iprob to zero and then immediately checks for nonzero. splatte.for Initializes iexit to zero and then immediately checks for nonzero. welaugp.for Initializes iexit to zero and then immediately checks for nonzero. xdebug.for Initializes iprob to zero and then immediately checks for nonzero. After making the changes I did a veryclean 64-bit gfortran compile and have zero warnings.

Ray subsequently provided updates for divres.for, dnmfso.for, and dnmfso2.for with minor changes so I added those. When I try to run the resulting executable on the cm2015H dataset (sim), I get the following. The random value of index indicates that iuse is not getting set properly.

Subroutine Execut

• Execut; Year 1908 Month OCT
• Execut; Year 1908 Month NOV
• Execut; Year 1908 Month DEC
• Execut; Year 1909 Month JAN
• Execut; Year 1909 Month FEB
• Execut; Year 1909 Month MAR At line 535 of file divres.for Fortran runtime error: Index '1818306592' of dimension 1 of array 'divreq' above upper bound of 3060

Error termination. Backtrace:

Could not print backtrace: libbacktrace could not find executable to open

0 0x42c10b

1 0x4252b4

2 0x42146b

3 0x26143e

4 0x1cee52

5 0x1c2fdb

6 0x1c3205

7 0x1c13c0

8 0x1c14f5

9 0x9bb7033

10 0xb3c2650

11 0xffffffff

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[smalers]

I added some write statements to divres.for to track down the error. Here is what I think is going on. The error is:

At line 535 of file divres.for
Fortran runtime error: Index '1818306592' of dimension 1 of array 'divreq' above upper bound of 3060

I printed out the value of IUSE at different places. Many times it is OK, but before the crash has:

 ND=         408 Lr=         338 IOPDES(2,Lr)=           1 NDUSER(ND)=         408
 IUSE=         408
 Before d: reservoir check, IUSE=         408
 Before reservoir check, IUSE=         408
 Before reservoir check, IUSE=  1818306592

This shows that the assignment of IUSE is not occurring for this call to the subroutine. The questions are then:

1.IUSE is not explicitly declared locally and is not in the common blocks so it is an implicitly declared integer variable, right?. This is OK although adding IMPLICIT NONE over time would be good.

2. Why is IUSE not getting assigned a value or no warning about it? Maybe the compiler is not smart enough to detect this issue because the GO TO statements jump over its initialization in this instance.
3. Maybe code that worked with the global initialization and SAVE allowed things to work when it should not have, for example by using the previous call's IUSE value.

I talked to Ray Bennett. He indicated that there are cases where, for example, log messages may not be wrapped appropriately and may require an IF statement to ensure that log message is only printed for valid data. Ray is going to run the South Platte and Colorado dataset and clear up such issues. There may be more cases that are discovered over time so it will be important to run all the datasets to ensure that as much code as possible is run.

[smalers]

I committed the code from Ray Bennett. The next changes should hopefully fix runtime issues found running the Arkansas and Colorado datasets.

[smalers]

Ray provided another update dated 2021-05-05 to address runtime errors. There were about 40 files changed. Below are my comments as I reviewed the code during assimilation. Some are suggestions to make troubleshooting easier.

1. Many of the changes involve passing the name of the calling routine to DNMFSO2 using cCallBy variable to help developers. I do a similar thing in Java code where necessary but typically the variable is named routine. cCallBy is a bit confusing because in the name is more appropriate for the called routine (not the calling routine). A variable name like routine in the calling code could be used to refer to the current routine. Only subroutines like DNMFSO2 would have a parameter cCallBy. Also, if all subroutines defined a variable like routine, this could be output in logging messages rather than hard-coding the routine name, which would require multiple edits if the routine name changes. This is just feedback but troubleshooting the runtime errors is the most important priority. I realize that making changes in logging is a lot of work because of the number of lines of code.
2. directfs.for - line 255 logging message routine name does not match the file? I tried to skim changes for similar issues and this is the only one I noticed.
3. More cases of initialize typos have been introduced, such as initilize - I'm going to leave them as is so as to stay consistent with Ray's code until there is a better time to clean up. There are 42 cases of the above typo in the latest code update. I fixed hundreds of these in previous code review. Typos make it hard to do a search for initialization comments. When I see a bad spelling, I usually use grep to search all the files and then fix all occurrences.
4. Many routines set iout to control debugging but this requires a recompile. Ray has mentioned that output can be configured at runtime. However, I don't see how iout can be turned on in the *.ctl file, such as by ichk. Maybe more granular run-time configuration for turning on debugging would be helpful so the executable does not need to be recompiled to set iout? For example, the control file could indicate the routine name and iout value. Then general code could be called to set iout. This would add a little overhead but would be more flexible for troubleshooting.
5. dmnfso.for line 129 has a specific logging message for the date. I assume this routine is replaced by dmnfso2.for. To avoid code duplication, dmnfso routine can just call dmnfso2 when an empty calling routine name. Then dmnfso2 can check for empty routine and have different logic. Or, use a routine name like unknown. Otherwise, duplicating done results in a maintenance problem.
6. dmnfso2.for needs to have the GPL 3 license notice inserted at the top similar to other files. I can add if Ray does not add in the next round of code updates.
7. In general, it is more obvious and easier to pinpoint issues when controlling variables are passed in subroutines rather than using common block. Ray has added a couple of variables itarx and iter to routines to control execution. I don't know if there are other variables that should be passed similarly rather than using common block. The common blocks are useful for input data that don't change. I'm not suggesting any specific changes. I think the changes are going in the right direction.

I did a clean compile and ran on the cm2015H dataset for full 1909 to 2015 period. It ran through, but I did not do any output comparisons.

+ Execut;  Year  2003 Month SEP
+ Execut;  Year  2003 Month OCT
   Stopped in Chekres, see the log file (*.log)
 Stop 1

The cm2015H log file has the following, indicative of nr not being properly initialized.

  Execut; Year =  2004

________________________________________________________________________
#
# CallDat; Call data for a right 0
#
#             # Year  Mon  Day Right        Iter   Divert af  Outflow af    Avail af   Bypass_af  Str_Type     Sta_ID       Sta_Name                 Comment
#          ____ ____ ____ ____ ____________ ____ ___________ ___________ ___________ ___________  ___________  ___________  ________________________ _________________________
   Chekres; Problem nr < maxres,isub,nr,maxres
   Chekres; isub, nr, maxres           9   538976288        1001
   Stopped in Chekres

nr is passed to chekres subroutine. The call is made in 62 places in the code from 36 routines. The following command lists the routines called:

grep -i 'call chekres' *.for | cut -d ' ' -f 1 | sort -u
JMStore.for:
JMStore.for:c
carrpl.for:
directby.for:
directex.for:
divcar.for:
divcar1.for:
divcarl.for:
divmultR.for:
divres.for:
divresp.for:
divresp2.for:
divresr.for:
divrpl.for:
divrplp.for:
divrplp2.for:
divrplr.for:
evasec.for:
junk-divres.for:
oopbook.for:
oopbook2.for:
oopdiv.for:
powres.for:
powres2.for:
powsea.for:
powseap.for:
replace.for:
resoop.for:
resrg1.for:
resrg1p.for:
resrgp.for:
resrpl.for:
rsrspu.for:
rsrspup.for:
sjrip.for:
welrech.for:

The following command lists the places called:

grep -i 'call chekres' *.for
JMStore.for:c               Step 19; Call Chekres for Roundoff issues
JMStore.for:          call chekres(io99,maxres, 1, 53, iyr, mon, nsR, nowner,
carrpl.for:      call chekres(nlog, maxres, in1, isub1, iyr, mon, nr,nowner,
carrpl.for:        call chekres(nlog, maxres, in1, isub1, iyr, mon, nd,nowner,
carrpl.for:      call chekres(nlog, maxres, in1, isub1, iyr, mon, nr,nowner,
carrpl.for:          call chekres(nlog, maxres, in1, isub1, iyr, mon, nd,nowner,
directby.for:        call chekres(nlog, maxres, 1, 17, iyr, mon, nr2,nowner,
directex.for:        call chekres(nlog, maxres, 1, 17, iyr, mon, nr2,nowner,
divcar.for:        call chekres(nlog, maxres, in1, isub1, iyr, mon, nr2,nowner,
divcar.for:        call chekres(nlog, maxres, 1, 11, iyr, mon, nd2,nowner,
divcar1.for:      call chekres(io99, maxres, in1, isub1, iyr, mon, nr,nowner,
divcar1.for:        call chekres(io99, maxres, in1, isub1, iyr, mon, nr,nowner,
divcarl.for:         call chekres(nlog, maxres, in1, 45, iyr, mon, nr2,nowner,
divcarl.for:        call chekres(nlog, maxres, in1, isub1, iyr, mon, nr2,nowner,
divmultR.for:        call chekres(io99,maxres, 1, 52, iyr, mon, nrs,nowner,
divres.for:      call chekres(nlog, maxres, in1, isub1, iyr, mon, nr,
divres.for:      call chekres(nlog, maxres, in1, isub1, iyr, mon, nr,
divresp.for:        call chekres(nlog, maxres, 1, 19, iyr, mon, nr,nowner,
divresp2.for:        call chekres(nlog, maxres, in, isub, iyr, mon, ndR,nowner,
divresp2.for:        call chekres(nlog, maxres, in, isub, iyr, mon, ndR,nowner,
divresp2.for:        call chekres(nlog, maxres, in, isub, iyr, mon, nsR,nowner,
divresr.for:      call chekres(nlog, maxres, 0, 21, iyr, mon, nr,nowner,
divresr.for:      call chekres(nlog, maxres, 1, 21, iyr, mon, nr,nowner,
divresr.for:        call chekres(nlog, maxres, 1, 21, iyr, mon, nrD,nowner,
divrpl.for:      call chekres(nlog,maxres,1, 4, iyr, mon, nr,nowner,
divrplp.for:        call chekres(nlog, maxres, in, isub, iyr, mon, nr,nowner,
divrplp.for:        call chekres(nlog, maxres, in, isub, iyr, mon, nsR,nowner,
divrplp2.for:        call chekres(nlog, maxres, in, isub1, iyr, mon, nsR,nowner,
divrplr.for:      call chekres(nlog, maxres, 0, 22, iyr, mon, nr,nowner,
divrplr.for:        call chekres(nlog, maxres, 1, 22, iyr, mon, nrD,nowner,
evasec.for:          call chekres(nlog,maxres, 0,16, iyr, mon, nr, nowner,
evasec.for:        call chekres(nlog,maxres, 1,16, iyr, mon, nr, nowner,
junk-divres.for:      call chekres(nlog, maxres, in1, isub1, iyr, mon, nr,
junk-divres.for:      call chekres(nlog, maxres, in1, isub1, iyr, mon, nr,
oopbook.for:      call chekres(io99,maxres, 1, 8, iyr, mon, nr,nowner,
oopbook2.for:        call chekres(nlog,maxres, in1, isub, iyr, mon, nr,nowner,
oopbook2.for:        call chekres(nlog,maxres, in1, isub, iyr, mon, nr,nowner,
oopbook2.for:        call chekres(nlog,maxres, in1, isub, iyr, mon, nr,nowner,
oopbook2.for:        call chekres(nlog,maxres, in1, isub, iyr, mon, nr,nowner,
oopdiv.for:        call chekres(nlog, maxres, 1, 8, iyr, mon, nRes,nowner,
powres.for:      call chekres(nlog, maxres, in1, isub1, iyr, mon, nr,nowner,
powres.for:      call chekres(nlog, maxres, in1, isub1, iyr, mon, nr,nowner,
powres2.for:      call chekres(nlog, maxres, in1, isub1, iyr, mon, nr,nowner,
powres2.for:      call chekres(nlog, maxres, in1, isub1, iyr, mon, nr,nowner,
powsea.for:      call chekres(io99,maxres, 1, 9, iyr, mon, nr,nowner,
powseap.for:        call chekres(nlog,maxres, 1, 9, iyr, mon, nr,nowner,
replace.for:        call chekres(nlog, maxres, in1, isub1, iyr, mon, nr,nowner,
resoop.for:      call chekres(io99,maxres, 1, 8, iyr, mon, nr,nowner,
resrg1.for:      call chekres(nlog, maxres, in1, isub1, iyr, mon, nr,nowner,
resrg1.for:      call chekres(nlog, maxres, in1, isub1, iyr, mon, nr,nowner,
resrg1p.for:      call chekres(nlog, maxres, 1, 18, iyr, mon, nr, nowner,
resrgp.for:      call chekres(nlog, maxres, in1, isub1, iyr, mon, nr,nowner,
resrgp.for:      call chekres(nlog, maxres, in1, isub1, iyr, mon, nr,nowner,
resrpl.for:      call chekres(io99,maxres, in, isub, iyr, mon, nr, nowner,
resrpl.for:      call chekres(io99,maxres, in, isub, iyr, mon, nrd, nowner,
resrpl.for:      call chekres(io99,maxres, in, isub, iyr, mon, nr,nowner,
resrpl.for:      call chekres(io99,maxres, in, isub, iyr, mon, nrd,nowner,
rsrspu.for:        call chekres(io99,maxres, 1, 6, iyr, mon, nr,nowner,
rsrspup.for:        call chekres(io99,maxres, 1, 6, iyr, mon, nr,nowner,
sjrip.for:      call chekres(io99,maxres, 1, 15, iyr, mon, nr,nowner,
welrech.for:      call chekres(nlog, maxres, in1, isub1, iyr, mon, nr,nowner,
welrech.for:        call chekres(nlog, maxres, in1, isub1, iyr, mon, nr,nowner,

I'm going to see where things stand with Ray before doing anything else.

[Rayrbennett]

Re # 4 see documentation for control file. It’s typically independent of variable ‘iout’. Re # 6 don’t know why it is missing your GPL 3 license stuff. Code is very old, maybe it got missed. Other: you may want to check options that list GNU limits on use of code to be sure it does not conflict with what you seem to be doing with GPL 3 headed. This should be documented as an option like -simulate.
Ray

Sent from my iPhone

On May 12, 2021, at 11:07 AM, Steve Malers @.***> wrote:

Ray provided another update dated 2021-05-05 to address runtime errors. There were about 40 files changed. Below are my comments as I reviewed the code during assimilation. Some are suggestions to make troubleshooting easier.

Many of the changes involve passing the name of the calling routine to DNMFSO2 using cCallBy variable to help developers. I do a similar thing in Java code where necessary but typically the variable is named routine. cCallBy is a bit confusing because in the name is more appropriate for the called routine (not the calling routine). A variable name like routine in the calling code could be used to refer to the current routine. Only subroutines like DNMFSO2 would have a parameter cCallBy. Also, if all subroutines defined a variable like routine, this could be output in logging messages rather than hard-coding the routine name, which would require multiple edits if the routine name changes. This is just feedback but troubleshooting the runtime errors is the most important priority. I realize that making changes in logging is a lot of work because of the number of lines of code. directfs.for - line 255 logging message routine name does not match the file? I tried to skim changes for similar issues and this is the only one I noticed. More cases of initialize typos have been introduced, such as initilize - I'm going to leave them as is so as to stay consistent with Ray's code until there is a better time to clean up. I fixed hundreds of these in previous code review. Typos make it hard to do a search for initialization comments. When I see a bad spelling, I usually use grep to search all the files and then fix all occurrences. Many routines set iout to control debugging but this requires a recompile. Ray has mentioned that output can be configured at runtime. However, I don't see how iout can be turned on in the *.ctl file, such as by ichk. Maybe more granular run-time configuration for turning on debugging would be helpful so the executable does not need to be recompiled to set iout? For example, the control file could indicate the routine name and iout value. Then general code could be called to set iout. This would add a little overhead but would be more flexible for troubleshooting. dmnfso.for line 129 has a specific logging message for the date. I assume this routine is replaced by dmnfso2.for. To avoid code duplication, dmnfso routine can just call dmnfso2 when an empty calling routine name. Then dmnfso2 can check for empty routine and have different logic. Or, use a routine name like unknown. Otherwise, duplicating done results in a maintenance problem. dmnfso2.for needs to have the GPL 3 license notice inserted at the top similar to other files. I can add if Ray does not add in the next round of code updates. In general, it is more obvious and easier to pinpoint issues when controlling variables are passed in subroutines rather than using common block. Ray has added a couple of variables itarx and iter to routines to control execution. I don't know if there are other variables that should be passed similarly rather than using common block. The common blocks are useful for input data that don't change. I'm not suggesting any specific changes. I think the changes are going in the right direction. I did a clean compile and ran on the cm2015H dataset for full 1909 to 2015 period. It ran through, but I did not do any output comparisons.

• Execut; Year 2003 Month SEP

• Execut; Year 2003 Month OCT Stopped in Chekres, see the log file (*.log) Stop 1 The cm2015H log file has the following, indicative of nr not being properly initialized.

  Execut; Year = 2004

---

#

CallDat; Call data for a right 0

#

Year Mon Day Right Iter Divert af Outflow af Avail af Bypass_af Str_Type Sta_ID Sta_Name Comment

____ ____ ____ _____

Chekres; Problem nr < maxres,isub,nr,maxres Chekres; isub, nr, maxres 9 538976288 1001 Stopped in Chekres nr is passed to chekres subroutine. The call is made in 62 places in the code from 36 routines. The following command lists the routines called:

grep -i 'call chekres' *.for | cut -d ' ' -f 1 | sort -u JMStore.for: JMStore.for:c carrpl.for: directby.for: directex.for: divcar.for: divcar1.for: divcarl.for: divmultR.for: divres.for: divresp.for: divresp2.for: divresr.for: divrpl.for: divrplp.for: divrplp2.for: divrplr.for: evasec.for: junk-divres.for: oopbook.for: oopbook2.for: oopdiv.for: powres.for: powres2.for: powsea.for: powseap.for: replace.for: resoop.for: resrg1.for: resrg1p.for: resrgp.for: resrpl.for: rsrspu.for: rsrspup.for: sjrip.for: welrech.for: The following command lists the places called:

grep -i 'call chekres' *.for JMStore.for:c Step 19; Call Chekres for Roundoff issues JMStore.for: call chekres(io99,maxres, 1, 53, iyr, mon, nsR, nowner, carrpl.for: call chekres(nlog, maxres, in1, isub1, iyr, mon, nr,nowner, carrpl.for: call chekres(nlog, maxres, in1, isub1, iyr, mon, nd,nowner, carrpl.for: call chekres(nlog, maxres, in1, isub1, iyr, mon, nr,nowner, carrpl.for: call chekres(nlog, maxres, in1, isub1, iyr, mon, nd,nowner, directby.for: call chekres(nlog, maxres, 1, 17, iyr, mon, nr2,nowner, directex.for: call chekres(nlog, maxres, 1, 17, iyr, mon, nr2,nowner, divcar.for: call chekres(nlog, maxres, in1, isub1, iyr, mon, nr2,nowner, divcar.for: call chekres(nlog, maxres, 1, 11, iyr, mon, nd2,nowner, divcar1.for: call chekres(io99, maxres, in1, isub1, iyr, mon, nr,nowner, divcar1.for: call chekres(io99, maxres, in1, isub1, iyr, mon, nr,nowner, divcarl.for: call chekres(nlog, maxres, in1, 45, iyr, mon, nr2,nowner, divcarl.for: call chekres(nlog, maxres, in1, isub1, iyr, mon, nr2,nowner, divmultR.for: call chekres(io99,maxres, 1, 52, iyr, mon, nrs,nowner, divres.for: call chekres(nlog, maxres, in1, isub1, iyr, mon, nr, divres.for: call chekres(nlog, maxres, in1, isub1, iyr, mon, nr, divresp.for: call chekres(nlog, maxres, 1, 19, iyr, mon, nr,nowner, divresp2.for: call chekres(nlog, maxres, in, isub, iyr, mon, ndR,nowner, divresp2.for: call chekres(nlog, maxres, in, isub, iyr, mon, ndR,nowner, divresp2.for: call chekres(nlog, maxres, in, isub, iyr, mon, nsR,nowner, divresr.for: call chekres(nlog, maxres, 0, 21, iyr, mon, nr,nowner, divresr.for: call chekres(nlog, maxres, 1, 21, iyr, mon, nr,nowner, divresr.for: call chekres(nlog, maxres, 1, 21, iyr, mon, nrD,nowner, divrpl.for: call chekres(nlog,maxres,1, 4, iyr, mon, nr,nowner, divrplp.for: call chekres(nlog, maxres, in, isub, iyr, mon, nr,nowner, divrplp.for: call chekres(nlog, maxres, in, isub, iyr, mon, nsR,nowner, divrplp2.for: call chekres(nlog, maxres, in, isub1, iyr, mon, nsR,nowner, divrplr.for: call chekres(nlog, maxres, 0, 22, iyr, mon, nr,nowner, divrplr.for: call chekres(nlog, maxres, 1, 22, iyr, mon, nrD,nowner, evasec.for: call chekres(nlog,maxres, 0,16, iyr, mon, nr, nowner, evasec.for: call chekres(nlog,maxres, 1,16, iyr, mon, nr, nowner, junk-divres.for: call chekres(nlog, maxres, in1, isub1, iyr, mon, nr, junk-divres.for: call chekres(nlog, maxres, in1, isub1, iyr, mon, nr, oopbook.for: call chekres(io99,maxres, 1, 8, iyr, mon, nr,nowner, oopbook2.for: call chekres(nlog,maxres, in1, isub, iyr, mon, nr,nowner, oopbook2.for: call chekres(nlog,maxres, in1, isub, iyr, mon, nr,nowner, oopbook2.for: call chekres(nlog,maxres, in1, isub, iyr, mon, nr,nowner, oopbook2.for: call chekres(nlog,maxres, in1, isub, iyr, mon, nr,nowner, oopdiv.for: call chekres(nlog, maxres, 1, 8, iyr, mon, nRes,nowner, powres.for: call chekres(nlog, maxres, in1, isub1, iyr, mon, nr,nowner, powres.for: call chekres(nlog, maxres, in1, isub1, iyr, mon, nr,nowner, powres2.for: call chekres(nlog, maxres, in1, isub1, iyr, mon, nr,nowner, powres2.for: call chekres(nlog, maxres, in1, isub1, iyr, mon, nr,nowner, powsea.for: call chekres(io99,maxres, 1, 9, iyr, mon, nr,nowner, powseap.for: call chekres(nlog,maxres, 1, 9, iyr, mon, nr,nowner, replace.for: call chekres(nlog, maxres, in1, isub1, iyr, mon, nr,nowner, resoop.for: call chekres(io99,maxres, 1, 8, iyr, mon, nr,nowner, resrg1.for: call chekres(nlog, maxres, in1, isub1, iyr, mon, nr,nowner, resrg1.for: call chekres(nlog, maxres, in1, isub1, iyr, mon, nr,nowner, resrg1p.for: call chekres(nlog, maxres, 1, 18, iyr, mon, nr, nowner, resrgp.for: call chekres(nlog, maxres, in1, isub1, iyr, mon, nr,nowner, resrgp.for: call chekres(nlog, maxres, in1, isub1, iyr, mon, nr,nowner, resrpl.for: call chekres(io99,maxres, in, isub, iyr, mon, nr, nowner, resrpl.for: call chekres(io99,maxres, in, isub, iyr, mon, nrd, nowner, resrpl.for: call chekres(io99,maxres, in, isub, iyr, mon, nr,nowner, resrpl.for: call chekres(io99,maxres, in, isub, iyr, mon, nrd,nowner, rsrspu.for: call chekres(io99,maxres, 1, 6, iyr, mon, nr,nowner, rsrspup.for: call chekres(io99,maxres, 1, 6, iyr, mon, nr,nowner, sjrip.for: call chekres(io99,maxres, 1, 15, iyr, mon, nr,nowner, welrech.for: call chekres(nlog, maxres, in1, isub1, iyr, mon, nr,nowner, welrech.for: call chekres(nlog, maxres, in1, isub1, iyr, mon, nr,nowner, I'm going to see where things stand with Ray before doing anything else.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[smalers]

Good point on the GPL license notice in dmnfso2.for. I don't know why that slipped through when I added but there were many files and I must have skipped. If Ray does not add I will do it when I get a chance.

[smalers]

I added the GPL license notice to dnmfso2.for.

[smalers]

I fixed the logging message in directfs.for line 255 to match the routine name.

[smalers]

I fixed typos such as initilize.

[smalers]

I fixed chekres.for error message for nr to be the correct sign.

[smalers]

The cm2015H dataset now runs for both 64-bit and 32-bit gfortran versions and the output is very close. Some numbers in the xwb output are off by 1 so that looks OK. Future work can focus on 64-bit comparison of gfortran and Lahey output.

Comparing the xwb output for Lahey 16.00.47 and gfortran 16.00.48 shows significant differences. Need to track these down with Ray Bennett.

[smalers]

Code Udpates

Ray provided more changes in 2021-05-30 zip file. I copied the following changes. However, I noticed typos again in the files when visually inspecting so I am suspicious that Ray did not pull in the latest code I provided in a May 25 email, which is where I had fixed typos and a few other issues. I checked the statemod-16.00.48-2021-05-25-code.zip file that I sent and it has typos fixed. Some typos like initilize are important because there are sections in the code for initializing code and if there is a typo it is hard to search for that section. Some of the typos are showing up in report output such as outtop.for and have been misspelled for years. How do I find typos? My editor highlights them and some are more obvious than others. When I find one, I search the code and fix everywhere.

I'm listing the files copied again here and typos that need to be re-fixed. I may actually not have them all right copying from the code. However, at this point I just want to get the same code compiling so that I can try some model runs. These zip hand-offs point out the benefits of version control and kdiff3 because it is easy to see when code is different. In summary, I copied all of Ray's files in the zip file other than dattim_gfortran.for, even though previous edits that I had made to correct typos and a couple of other minor things were lost, in order to ensure that the code is consistent with Ray. Reimplementing my previous changes will need to occur when there is time.

File	Needed Change
accdiv.for	initilize
bomsec.for	initilize
carrpl.for	initilize (multiple)
chekres.for	Line 93 warning should have > in message, line 158 need to remove troubleshooting message from me.
coeffa.for	initilize (multiple)
count.for	initilize (multiple)
datinp.for	initilize (multiple), algorythm, inconsitant, amentation (should be augmentation), Reservor, multiple tabs in comments were cleaned up previously.
dattim_gfortran.for	I previously fixed so that year would be 2-digit as per Lahey. Leave my previous changes so that formatting works as intended for now. I have recommended switching the code to use 4-digit year throughout.
daydist.for	resevoirs
directfs.for	opeating (should be operating), Estiate, line 255 log message does not match file name.
directwr.for	initilize
divcarl.for	Has many new changes - no issues that I can see.
divres.for	initilize (multiple), reservr, remaing
divresp2.for	exchaged (multiple), reservr (multiple), assied (should be assigned).
divresr.for	initilize (multiple)
divrig.for	Seems to have been changed to an earlier version. I'm coping Ray's latest.
divrplp.for	exchaged (multiple), reservr.
dnmfso2.for	Seems to have reverted to older version with some logging differences, MINMUM, this version does not have the GPL 3 notice that I previously inserted.
dsamod.for	Algorythm
execut.for	Seems to have reverted to an earlier version with more comments and logging changes. I'm copying Ray's latest.
getcall.for	initilize
getfn.for	initilize (multiple), Reservr
getrep.for	reservr
getres.for	Enhansement, warningc, porportinal, NOte. Reservor (multiple)
getres2.for	Reservor (multiple)
getver.for	Reconmend
oprinp.for	reservr (multiple), Resevoir, reservor (multiple)
outbal2.for	Resevoir, Reservior (multiple), TsTool (should be TSTool)
outcall.for	estiamted
outcallr.for	estiamted
outichk.for	Seems to have reverted to an older version. Line 355 has different format but probably OK.
outrchr.for	Resevoir, Reservior
outtbl.for	initilize
outtop.for	Reservior
parse.for	initilize
parse_gfortran.for	initilize
planeva.for	reservor
powres.for	I think I previously cleaned up some tab formatting.
powsea.for	initilize (multiple), Exchangec (multiple)
powseap.for	reservor
resrgp.for	initilize
resrpl.for	Seems to have reverted to an older version, with some logging changes. Reservior
riginp.for	reservior, resevoir, opeating
rivrtn.for	Avatmp (variable comment), currrent, diverson, amy (any), especailly (multiple), Rejust
skipn.for	initilize
statem.for	initilize, exchaged (multiple), Algorythm, resevoirs, reservior

Differences between Lahey and gfortran

After compiling with make veryclean and make statemod I ran the cm2015H simulation and then created the xwb report. The run took about 1.5 hours and my computer has OK power and lots of memory. The comparison of the Lahey 16.00.47 and gfortran 16.00.48 xwb file shows some differences, more in some years, and typically relatively small. Some differences are in the thousands. The following shows the section at the end. For example, the difference in annual diversions to storage is 1774 acft out of 259586 or less than one percent. What is the cause of these differences?

• Different code logic between 16.00.47 and 16.00.48 (bug fixes in 16.00.48 and/or initialization/SAVE logic)?
• Numerical roundoff differences during iteration?
• Lahey and gfortran compiler options different for handling of initialization and SAVE?
• Some other fundamental difference?

Do these differences need to be explored more? I've attached zip files of the xwb reports.

Lahey:

                               Water Budget  ACFT

                Stream                 From/To        From        From       Total              From River        Well   Reservoir   Reservoir      Stream   Reservoir          To       SoilM       Total                   
 Year   Mo      Inflow      Return   GWStorage       SoilM    Plan (5)      Inflow  Divert (6)     by Well   Depletion Evaporation     Seepage     Outflow      Change       SoilM      Change     Outflow       Delta      CU (1)    Loss (2) Pumping (3) Salvage (4)
                   (+)         (+)         (+)         (+)         (+)          NA         (-)         (-)         (-)         (-)         (-)         (-)         (-)         (-)         (-)          NA          NA          NA          NA          NA          NA
                  ( 1)        ( 2)        ( 3)        ( 4)        ( 5)        ( 6)        ( 7)        ( 8)        ( 9)        (10)        (11)        (12)        (13)        (14)        (15)        (16)        (17)        (18)        (19)        (20)        (21)
 ____ ____ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________
Ave   OCT      237990.     318394.          0.       1177.          0.     557561.     344818.          0.          0.       1258.          0.     232052.     -21744.       2379.      -1202.     557561.          0.      30812.       4093.          0.          0.
Ave   NOV      170813.     195877.          0.         77.          0.     366767.     168332.          0.          0.        269.          0.     213792.     -15704.       1164.      -1087.     366767.          0.      13845.        756.          0.          0.
Ave   DEC      155652.     198387.          0.          0.          0.     354039.     183317.          0.          0.       -561.          0.     192564.     -21281.       1137.      -1137.     354039.          0.      16801.        247.          0.          0.
Ave   JAN      149980.     182929.          0.          0.          0.     332910.     177626.          0.          0.       -532.          0.     179323.     -23508.        915.       -915.     332910.          0.      17620.        203.          0.          0.
Ave   FEB      145716.     162363.          0.          0.          0.     308079.     161484.          0.          0.         95.          0.     168321.     -21821.        665.       -665.     308078.          0.      15921.        188.          0.          0.
Ave   MAR      200559.     184085.          0.        563.          0.     385207.     192917.          0.          0.        766.          0.     218633.     -27672.        913.       -350.     385207.          0.      19116.        435.          0.          0.
Ave   APR      415019.     240331.          0.       1633.          0.     656983.     291160.          0.          0.       1627.          0.     366728.      -4165.       3577.      -1944.     656983.          0.      32804.       2250.          0.          0.
Ave   MAY     1257444.     364815.          0.       3362.          0.    1625622.     532961.          0.          0.       3744.          0.    1010740.      74813.      10366.      -7003.    1625621.          1.     109481.       6524.          0.          0.
Ave   JUN     1576446.     462821.          0.       3304.          0.    2042571.     717149.          0.          0.       5339.          0.    1200424.     116352.       7542.      -4238.    2042571.          1.     186452.      11523.          0.          0.
Ave   JUL      716653.     442331.          0.       9908.          0.    1168893.     629355.          0.          0.       5094.          0.     514141.      10394.        793.       9115.    1168892.          0.     172882.       9267.          0.          0.
Ave   AUG      336841.     388398.          0.       7408.          0.     732647.     497022.          0.          0.       3656.          0.     252280.     -27719.        982.       6426.     732647.          0.     110666.       5926.          0.          0.
Ave   SEP      244600.     354363.          0.       4414.          0.     603376.     413605.          0.          0.       2378.          0.     211841.     -28861.       1433.       2980.     603376.          0.      64676.       4889.          0.          0.
 ____ ____ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________
Ave   Tot     5607716.    3495097.          0.      31847.          0.    9134651.    4309746.          0.          0.      23134.          0.    4760842.       9084.      31865.        -19.    9134649.          3.     791074.      46300.          0.          0.
                                                                                       295090. (6,7)
                                                                                   ___________
                                                                                      4604837.

  Note: (1) Consumptive Use (CU) = Diversion (Divert) * Efficiency + From Well * Efficiency
           + max (Resevoir Evaporation (Evap), 0.0).
        (2) Loss is not part of the Stream Water Balance.
            It is the portion of a diversion, well pumping and reservoir seepage that does not return to the stream.
        (3) Pumping is not part of the Stream Balance.
            Its impact on the stream is included in the From River by Well and Well Depletion columns.
        (4) Salvage is not part of the Stream Water Balance.
            It is the portion of well pumping that does not impact the stream.
        (5) From Plan is water imported to the system by a Type 35 operating rule
        (6) Divert does not include diversions by an instream flow or a T&C plan.
            To avoid double accounting with reservoir storage it has been reduced as follows:
              Diversion to Storage                       259586. af/yr
              Diversion to Carrier                            0. af/yr
              Reservior to Carrier                        35504. af/yr
              Reservior Release when storage change = 0       0. af/yr
              Plan Carrier                                    0. af/yr
              Total                                      295090. af/yr
        (7) Divert does include diversions by a administration plan.  This may be tracked
            at a later date but it will require the TsTool, a time series processor, be updated

gfortran:

                               Water Budget  ACFT

                Stream                 From/To        From        From       Total              From River        Well   Reservoir   Reservoir      Stream   Reservoir          To       SoilM       Total                   
 Year   Mo      Inflow      Return   GWStorage       SoilM    Plan (5)      Inflow  Divert (6)     by Well   Depletion Evaporation     Seepage     Outflow      Change       SoilM      Change     Outflow       Delta      CU (1)    Loss (2) Pumping (3) Salvage (4)
                   (+)         (+)         (+)         (+)         (+)          NA         (-)         (-)         (-)         (-)         (-)         (-)         (-)         (-)         (-)          NA          NA          NA          NA          NA          NA
                  ( 1)        ( 2)        ( 3)        ( 4)        ( 5)        ( 6)        ( 7)        ( 8)        ( 9)        (10)        (11)        (12)        (13)        (14)        (15)        (16)        (17)        (18)        (19)        (20)        (21)
 ____ ____ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________
Ave   OCT      237990.     318378.          0.       1177.          0.     557545.     344800.          0.          0.       1259.          0.     232053.     -21744.       2379.      -1202.     557545.          0.      30813.       4093.          0.          0.
Ave   NOV      170812.     195973.          0.         77.          0.     366863.     168426.          0.          0.        269.          0.     213803.     -15713.       1164.      -1087.     366863.          0.      13845.        756.          0.          0.
Ave   DEC      155652.     198600.          0.          0.          0.     354252.     183529.          0.          0.       -561.          0.     192635.     -21351.       1137.      -1137.     354252.          0.      16801.        247.          0.          0.
Ave   JAN      149980.     183083.          0.          0.          0.     333064.     177770.          0.          0.       -532.          0.     179464.     -23639.        915.       -915.     333064.          0.      17610.        203.          0.          0.
Ave   FEB      145716.     162515.          0.          0.          0.     308230.     161628.          0.          0.         95.          0.     168485.     -21978.        665.       -665.     308230.          0.      15914.        188.          0.          0.
Ave   MAR      200559.     184195.          0.        563.          0.     385317.     193028.          0.          0.        766.          0.     218729.     -27769.        913.       -350.     385317.         -0.      19108.        436.          0.          0.
Ave   APR      415019.     240449.          0.       1633.          0.     657101.     291272.          0.          0.       1626.          0.     366857.      -4288.       3577.      -1944.     657101.          0.      32802.       2250.          0.          0.
Ave   MAY     1257445.     364833.          0.       3362.          0.    1625640.     532989.          0.          0.       3744.          0.    1010806.      74738.      10365.      -7003.    1625639.          1.     109489.       6524.          0.          0.
Ave   JUN     1576446.     462812.          0.       3304.          0.    2042562.     717134.          0.          0.       5339.          0.    1199900.     116883.       7542.      -4238.    2042562.          1.     186451.      11523.          0.          0.
Ave   JUL      716653.     442335.          0.       9908.          0.    1168897.     629363.          0.          0.       5095.          0.     514037.      10493.        793.       9115.    1168896.          0.     172882.       9267.          0.          0.
Ave   AUG      336841.     388401.          0.       7408.          0.     732650.     497016.          0.          0.       3657.          0.     252266.     -27697.        981.       6427.     732650.          0.     110660.       5926.          0.          0.
Ave   SEP      244600.     354374.          0.       4413.          0.     603387.     413619.          0.          0.       2379.          0.     211816.     -28839.       1433.       2979.     603387.          0.      64674.       4889.          0.          0.
 ____ ____ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________ ___________
Ave   Tot     5607716.    3495950.          0.      31845.          0.    9135506.    4310574.          0.          0.      23137.          0.    4760855.       9097.      31864.        -19.    9135504.          2.     791050.      46302.          0.          0.
                                                                                       296858. (6,7)
                                                                                   ___________
                                                                                      4607432.

  Note: (1) Consumptive Use (CU) = Diversion (Divert) * Efficiency + From Well * Efficiency
           + max (Resevoir Evaporation (Evap), 0.0).
        (2) Loss is not part of the Stream Water Balance.
            It is the portion of a diversion, well pumping and reservoir seepage that does not return to the stream.
        (3) Pumping is not part of the Stream Balance.
            Its impact on the stream is included in the From River by Well and Well Depletion columns.
        (4) Salvage is not part of the Stream Water Balance.
            It is the portion of well pumping that does not impact the stream.
        (5) From Plan is water imported to the system by a Type 35 operating rule
        (6) Divert does not include diversions by an instream flow or a T&C plan.
            To avoid double accounting with reservoir storage it has been reduced as follows:
              Diversion to Storage                       261360. af/yr
              Diversion to Carrier                            0. af/yr
              Reservior to Carrier                        35497. af/yr
              Reservior Release when storage change = 0       0. af/yr
              Plan Carrier                                    0. af/yr
              Total                                      296858. af/yr
        (7) Divert does include diversions by a administration plan.  This may be tracked
            at a later date but it will require the TsTool, a time series processor, be updated

cm2015H.xwb.gfortran64.16.00.48.zip cm2015H.xwb.Lahey16.00.47.zip

[smalers]

I fixed all the typos and other things listed in the table and provided Ray Bennett with a zip file of the current code. Keep this issue open until more explanation of differences is determined.

[smalers]

I am closing this issue. As of changes made to 16.00.48 I have been able to run the cm2015 dataset. Any new problems that are found can be addressed in new issues.