[5pt] Improve CatFIM site tracking from version to version

[EmilyDeardorff]

Currently we don't have an established part of the CatFIM workflow to track which CatFIM sites have been added or removed or mapped vs unmapped between versions.

Improve CatFIM site tracking from version to version, so when we release a new version we can, 1. catch bugs that we might’ve introduced (that accidentally got rid of sites) and 2. keep the field informed of why certain sites are no longer there.

Create an updated version of the CatFIM site comparison tools that compares the most recent 3-4 versions of CatFIM and creates site tracker tables (outlined below) for stage-based and flow-based CatFIM.

site	version 1	version 1 notes	version 2	version 2 notes	version 3	version 3 notes
hgjs7	mapped		unmapped	Missing all flows.	not included
gndr8	not included		mapped		mapped

[EmilyDeardorff]

I've updated the CatFIM site comparison tool, so now it creates tables with the following structure. This tool can produce a comparison of two or more CatFIM output folders. It will automatically sort the input paths into flow-based and stage-based comparison CSVs.

I'm thinking about adding an optional argument that would make the output CSVs only retain sites where there is a status change. I'm also thinking about including a few more data columns, perhaps HUC8.

[RobHanna-NOAA]

I wonder if we have to put in output data for this tool to say which sites are now on the ahps_restricted_sites list. ie.. what if one drops off becuase of an earlier version to the new one.. ie) added that site to the restricted sites list since the last push.

[RobHanna-NOAA]

getting real crazy, and you mentioned it earlier.. what if we did feed in the older version of the sites package while we are processing CatFIM in the first place and added a new column for the reason for the change. ie) now on restricted sites, or flow data no longer available, etc. The one thing you would not be able to compare is status messages from one to the next. The text has changed quite a bit. This does put us back a little from "status" column to "error" versus "warning", but then again a single "status" column is so much cleaner. It does not mean we can not have error and warning as two separate field for processing and just roll them together into a "status' column at last min.

[EmilyDeardorff]

Common site Changes from 4.5.2.11 to 4.5.11.1 - Stage-based CatFIM

I've included a few example sites for each change.

1. AHPS site altitude value invalid (previous status: "OK")

Site	HUC
bdkn4	2030105
bruf1	3140203
bvcl1	8080103
clba1	3150204
douf1	3110205

2. All stages failed to inundate (previous status: "OK")

Site	HUC
bwki1	17040219
coau1	16030006
eccu1	16020102
glgm8	10020008
hali1	17040219

3. Site resulted with no valid inundated files (previous status: "missing NWM segments, OK")

Site	HUC
ches1	3040201
rbgw3	7070004
roww2	5020004

4. Was OK, no longer being pulled from AHPS (previous status: "OK")

Site	HUC
alxo2	11130303
blwm6	3170009
slgl1	11140204
grot2	12060202
burk1	10250016