OpenCDSS / cdss-app-statedmi-main

StateDMI main application, tests, and documentation
GNU General Public License v3.0
1 stars 0 forks source link

Duplicate well rights need to be removed from well rights file #108

Closed smalers closed 2 years ago

smalers commented 2 years ago

The following is feedback from Kara Sobieski that indicates duplicate well rights.


Below are two issues that I have identified in the WER file that I created using your commands and the new version of StateDMI (version 5.1.0 dev) you provided Kara.

Structure 100567 in 1954 is missing well rights associated with 1005404 and 1005405. I checked your parcel-model-supply-before-wer file and the wells are associated with the parcel (ID 21011145), but they don't have receipt information. Could this be the reason they aren't getting picked up?

The other issue I noticed is that the groundwater aggregates appear to have duplicate water rights. For example - Groundwater aggregate 67GW_017 has two entries for the one water right associated with WDID 6705702. See the screenshot of the WER below.

image

I've attached the WER file that I ran using your commands and StateDMI version 5.1.0.dev. Note that I still haven't tested APEX rights.

smalers commented 2 years ago

StateDMI 5.1.1 includes a fix to remove duplicate well rights from the wer file. A message is printed to the log file to indicate duplicate wells.

As for the first question above, structure 1005404 has two rights. One has use type MUN and therefore by default is ignored when reading well rights (only IRR and ALL types are returned). The second has units A for storage and is not returned. Querying net amount rights for structure 1005405 has a similar situation.

I'll leave this issue open until there is confirmation from modelers.

smalers commented 2 years ago

From Brenna:

Steve thanks for all your work on the new StateDMI version 5.1.1. We took a look at it, and had no issues with the cds and ipy files. For the WER file there still seems to be a few issues. First, there is still a duplicate issue. It is a different duplicate issue this time around. For instance below is a picture of the structure 1300975 in the WER file, note that the same information is pasted three times.

image

Based on the log file, what I believe is happening is when StateDMI reaches a structure in the WES file that it cannot find well rights for in HydroBase, like a municipal aggregate structure, it then re-does the last structure it could find rights for. Structure 1300975 is followed by two structures in the WES that are municipal aggregate structures that StateDMI could not complete.

Another issue I noticed is that it pulled in a well that is not in our list files as being associated with any structures in our structure file. Well 6705608 showed up as part of structure 67_GW022, however it is not listed as an associated well in the groundwater aggregate list file.

image

Lastly, I noticed on GitHUB that you still had a question concerning the issue we found with structure 1000567. You said you are only pulling wells with use type of IRR or All, however there are many wells that have IRR as a use type, with other uses that isn't "All" uses. For instance a well can have IRRMUNSTK, IRRMUNCOMINDFIRDOMAUG, IRRDOM, etc. This issue is the main reason that in my test file I am ending up with wells that you aren't because I include all use types that include IRR.

smalers commented 2 years ago

Below is my response. I will update this issue as I work on it.

Issue 1 - Duplicate wells

Brenna was somewhat correct. The code allows looking up the location from a StateMod well list file (wes) or a StateCU location (str) file. The problem was that the location was not found and should have gone to the next location. Instead it continued and processed the previous location again. This was a one line change in the code.

Issue 2 - Well is used that should not be

I found one issue where when processing well rights a list of a location's groundwater supplies is not correct. Because this involves parcels, it is necessary to loop through all the supplies (WDIDs and permit receipt) associated with the parcels. The code was checking to see that WDID and receipt of the supply matched. For some reason, some parcel had WDID and receipt and some had WDID but receipt was blank. This led to some supplies being repeated when processing rights. I updated to allow receipt to be missing, which is consistent with other code. This at least cleaned up confusion in the log file showing duplicate supplies. The rights in output are not duplicated in any case.

As for why 67_GW022 includes supply from 6705608? This supply is NOT shown in the parcel report from the WriteParcelsToFile command by default. However, turning the verbose mode on for the command shows that this identifier shows up in early years as a well supply but in years when there is also surface supply, with the association. This causes 6705608 to show up as a groundwater supply when the well rights code asks "tell me water supplies" for the parcel. One solution is to change the code to return only well supplies when no surface water, but this gets complicated because of the year issue above. Another solution is to filter the returned groundwater supplies by the aggregate/system list for the well. This is the code change I made. I don't know if this nuance is going to cause issues that need to be addressed with more code changes.

Issue 3 - Well right use

StateDMI queries the net amounts well rights data. Then it checks to see if any uses that it is interested in are found in the returned right. For example, IRR,ALL (the default) checks to see if either IRR or ALL are found in the HydroBase concatenated list of 3-character uses. Therefore, it would match IRR, ALL, or any combination with these strings concatenated with other strings. I realize that the documentation does not describe this parameter (only a tooltip) so I will add that. A message is printed to the log file such as: Removing right WDID=1005404 appropriation date=1954-08-01 because use (MUN) does not match a requested use (IRR,ALL). This is confirmed because the Ark2020.wer with extended columns on the right shows the use and there are strings that have more uses, such as shown below. No code change is necessary.

1000567.001 CLEAR SPRINGS RANCH P-111000567          36006.00000    2.27    1948 -999                                  Well     1005638              WDID     1005638  1948-07-31 36006.00000 IRRMUNDOM                      9080344  1949-05-31                                   0.00     0.00                    1018.85
1000567.002 CLEAR SPRINGS RANCH P-121000567          36340.00000    1.94    1949 -999                                  Well     1005639              WDID     1005639  1949-06-30 36340.00000 IRRMUNDOM                      9080345                                               0.00     0.00                     870.74
1000567.003 CLEAR SPRINGS RANCH P-011000567          38229.00000    2.60    1954 -999                                  Well     1005628              WDID     1005628  1954-09-01 38229.00000 IRRMUNDOM                      9080514  1954-09-01                                   0.00     0.00                    1166.97
1000567.004 CLEAR SPRINGS RANCH P-031000567          36402.00000    3.94    1949 -999                                  Well     1005630              WDID     1005630  1949-08-31 36402.00000 IRRMUNDOM                      9080348                                               0.00     0.00                    1768.40
1000567.005 VENETUCCI WELL NO 1     1000567          33542.00000    1.00    1941 -999                                  Well     1005401              WDID     1005401  1941-11-01 33542.00000 IRR                            9079999  1941-11-01                                   0.00     0.00                     450.18

This changes are in StateDMI 5.1.3.

smalers commented 2 years ago

Brenna at WWG indicates that the software is working. I'm closing this issue.