StateMod 17.0.2 does not run SP2016_H dataset

smalers commented 3 years ago

Subject of the issue

StateMod does not run the SP2016_H dataset. It complains about the plan data.

Environment

StateMod version 17.0.2
Windows operating system

Steps to reproduce

Tried to run the SP2016_H.RSP scenario in the testing framework.

Expected Behavior

Dataset should run.

Actual Behavior

There is something going on with handling plans that is different for gfortran and Lahey versions.

The gfortran executables (32-bit and 64-bit) log files have the following:

________________________________________________________________________
  Datinp; Plan Station File (*.pln)

  GetFile; Opening Plan_Data                               *.pln
    SP2016.pln
  Subroutine GetPln nlog =           99

________________________________________________________________________

  GetPln; Number of Plan Types
    # Type Description                Number
 ____ ____ _________________________ _______
 ____ ____ _________________________ _______
    0   NA Total                           0

  GetPln; Number of Plans        =            0

________________________________________________________________________
 GetPln; Problem provided a plan file but number of plans read =     0
         Reconmmend you check plan input or remove the file
         Note an inital plan storage is required on input

________________________________________________________________________
 GetPln; Stopped in GetPln

The Lahey log file has the following. Lahey seems to handle the plan data OK but complains about operating rule type 46, which is a known issue that can be corrected by updating the rule data.

________________________________________________________________________
  Datinp; Plan Station File (*.pln)

  GetFile; Opening Plan_Data                               *.pln
    SP2016.pln
  Subroutine GetPln nlog =  99
  GetPln; Reading efficiency data 1.00000000 1

________________________________________________________________________

  GetPln; Number of Plan Types
    # Type Description                Number
 ____ ____ _________________________ _______
    1    1 T&C_Requirement                82
    2    2 Well_Augmentation              51
    3    3 Reuse_Reservoir                21
    4    4 Reuse_Diversion                24
    5    7 Transmountain_Import           17
    6    8 Recharge_Plan                  49
    7   10 Special_Well_Augmentation       5
    8   11 Accounting_Plan                29
    9   12 Release_Plan_Limit            157
   10   13 Changed Water Right           347
 ____ ____ _________________________ _______
   10   NA Total                         782

  GetPln; Number of Plans        =  782

AND LATER...
________________________________________________________________________
  Oprinp; Problem with Operating right type = 46 ID = Welch.04a
          Expect the destination to be Multiple in
          order to allow 1 to 10 destinations to be
          specified.
          Recommend you revise the operating rule file.

karasobieski commented 3 years ago

Please attach StateMod Version 17.0.02 executable (or a link to the executable) to this issue so I can look into it.

karasobieski commented 3 years ago

Attached is a revised OPR file (remove the TXT) that corrects the known Type 46 format for Version 17.00.02. Additionally, the release limit plan information for OPR ID 64025260.05 was revised. In order to have as close of a comparison as possible to Version 15.00.01 results, attached is a revised OPR file (remove theTXT) that only corrects the release limit plan information for OPR ID 64025260.05.

SP2016_H simulates using the revised OPR file and Version 15.00.01.
I wasn't able to simulate SP2016_H using the revised OPR file and Version statemod-17.0.2-gfortran-win-64bit b.c of the Plan file issue identified above.

SP2016_rev1702.opr.txt

SP2016_rev1501.opr.txt

smalers commented 3 years ago

Version 17.0.3 fixes the typos (reconmend, inital) in the plan warning. I had to make an update to support the testing framework.

smalers commented 3 years ago

I'm trying to keep this moving along.

I modified development code to improve error handling reading the plans. There is an error reading the first plan. The current code on my computer is as follows. Based on this, the error is indicated in the first plan.

183           ! smalers 2021-09-13 The following does not provide a good indication if an error
184           !read(55,*,end=906, err=906)
185           read(55,*,end=906, iostat=ierror)
186      1      Pid(i), rec24, cgoto, Pon(i), iplnTyp(i),
187      1      Peff1, iPrf(i), iPfail(i), psup1, Psource(i),
188      1      iPacct(i)
189           if ( ierror .ne. 0 ) then
190             write(nlog,*) 'Error reading plan ', i
191             if ( i .gt. 1 ) then
192               write(nlog,*) 'Last plan read: ', Pid(i-1)
193             endif
194             ! Go to exit messages.
195             goto 906
196           endif

The first plan contains:

0802593     AuroraWellAugPlan       0802593            1       2       0       0       0       0 "Pumping     "0

Note that there is no space between the ending quote and the following zero. See Fortran List Directed I/O that indicates that quoted strings are allowed.

As a test I removed the double quotes. Then the error shows up in the second plan. However, I assume the string is formatted the way it is to force the full string to be filled in. It seems that it should not be necessary to pad the string but that could be tested.

As a second test I used the quotes but made sure there was a space after the second quote and the following zero. This also caused the error to move to the second plan.

My recommendation is to at a minimum put a space between the double quote and data before or after. I don't think it is necessary to put in the spaces in the quoted strings. This would need to be tested with Lahey executable to make sure it still works.

Also, the treatment of strings is not consistent in the file. In some places, plan names use quoted strings and in other places underscores to fill out the string. If spaces are in the name, why not use quotes around the name, but I don't see a reason to do extra spaces at the end of the name.

Rayrbennett commented 3 years ago

Your analysis looks right. My recollection is that the file is free format that typically requires at least 1 space between data. Apparently Lahey accepted this type of free format input or it operated with no warning.
Ray

Sent from my iPhone

On Sep 13, 2021, at 11:08 PM, Steve Malers @.***> wrote:

I'm trying to keep this moving along.

I modified development code to improve error handling reading the plans. There is an error reading the first plan. The current code on my computer is as follows. Based on this, the error is indicated in the first plan.

183 ! smalers 2021-09-13 The following does not provide a good indication if an error 184 !read(55,,end=906, err=906) 185 read(55,,end=906, iostat=ierror) 186 1 Pid(i), rec24, cgoto, Pon(i), iplnTyp(i), 187 1 Peff1, iPrf(i), iPfail(i), psup1, Psource(i), 188 1 iPacct(i) 189 if ( ierror .ne. 0 ) then 190 write(nlog,) 'Error reading plan ', i 191 if ( i .gt. 1 ) then 192 write(nlog,) 'Last plan read: ', Pid(i-1) 193 endif 194 ! Go to exit messages. 195 goto 906 196 endif The first plan contains:

0802593 AuroraWellAugPlan 0802593 1 2 0 0 0 0 "Pumping "0 Note that there is no space between the ending quote and the following zero. See Fortran List Directed I/O that indicates that quoted strings are allowed.

As a test I removed the double quotes. Then the error shows up in the second plan. However, I assume the string is formatted the way it is to force the full string to be filled in. It seems that it should not be necessary to pad the string but that could be tested.

As a second test I used the quotes but made sure there was a space after the second quote and the following zero. This also caused the error to move to the second plan.

My recommendation is to at a minimum put a space between the double quote and data before or after. I don't think it is necessary to put in the spaces in the quoted strings. This would need to be tested with Lahey executable to make sure it still works.

Also, the treatment of strings is not consistent in the file. In some places, plan names use quoted strings and in other places underscores to fill out the string. If spaces are in the name, why not use quotes around the name, but I don't see a reason to do extra spaces at the end of the name.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

rg727 commented 2 years ago

Hello, I am trying to the SP2016_H dataset as above and running into the same issue.

Environment StateMod version 15.00.01 which compiled successfully Linux Operating System

Steps to Reproduce Tried to run the SP2016_H.RSP scenario in the testing framework. Swapped in the adjusted operating rule file from karasobieski above: SP2016_rev1501.opr.txt

Expected Behavior Dataset should run.

Actual behavior Dataset does not run and still gets stuck in GetPln Capture

Can you please let me know if there are other adjustments that need to be made in the plan file as well? I tried to follow the thread above, but I'm still getting stuck.

Thank you! Rohini

Rayrbennett commented 2 years ago

Please provide a copy of your plan file (.pln) and response file (.rsp).rrb On Friday, July 15, 2022 at 10:07:20 AM PDT, Rohini Gupta @.***> wrote:

Hello, I am trying to the SP2016_H dataset as above and running into the same issue.

Environment StateMod version 15.00.01 which compiled successfully Linux Operating System

Steps to Reproduce Tried to run the SP2016_H.RSP scenario in the testing framework. Swapped in the adjusted operating rule file from karasobieski above: SP2016_rev1501.opr.txt

Expected Behavior Dataset should run.

Actual behavior Dataset does not run and still gets stuck in GetPln

Can you please let me know if there are other adjustments that need to be made in the plan file as well? I tried to follow the thread above, but I'm still getting stuck.

Thank you! Rohini

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were assigned.Message ID: @.***>

rg727 commented 2 years ago

Please see attached for the pln and rsp files. SP_Files.zip

OpenCDSS / cdss-app-statemod-fortran