9/7/2021 Work Session

[rburghol]

• Review stuff here: 8/2/2021 HARP Weekly Work Session #109
  • N51019 outlier data
  • Verify units on ET - PRECIP calcs
• 3 methods of ET
  • Hamon - This is what the CBP model uses for current (we need this, we will make WDMs with it)
  • Hargreaves/Samani - the CBP calculates change in ET over time due to CC, and then scales Hamon with it
    • We will also produce a separate WDM with JUST this data and maybe play around with it in terms of model storm fit during calibration period.
  • Another method (modeled? measured?) comes with NLDAS2 - we won't use this, but keep our mind on it.
• Compile source code for populating WDMs (src here)
• Group Goals:
  1. Experts when we Q/A: need to understand context and units;
  2. Ask questions about what we’re seeing to think about implications;
  3. Work elevated this year within DEQ;
  4. Opportunity for contributing to proactive approach management (maybe I’m being naive
  5. TMDL - Total Maximum Daily LOAD (mass/time) - Contribute beyond water quantity - e.g. quality, TMDL, impact of managing concentration vs. load

[snhandelsman]

water.deficit.precipitation.NLSegs.Errors (1).pdf

[rburghol]

Thanks @snhandelsman -- this looks interesting -- 2008 was a drought in some places, though that looks strange. Next we need to see the calculations and source units that go into this, as well as the raw data itself. Maybe a good way to format that will be a table of inputs (rain, et) with their units, and the calculated the 7-day rolling values for the period of October-December. Annotate it with the equations that created the rolling values, so we can see what generates that and if there is some mathematical quirk that we did not anticipate. My suspicion is that there is some bunk data in there, but who knows?

[kylewlowe]

9/13 UPDATE:

The issue seems to be with the land segment precipitation data for the two corresponding segments. The time series on deq4 says that it was raining from Oct. 29th to Dec. 31st in 2008. Because the workflow of the data goes from NLDAS grid data (the raw data source) into land segment data using the NLDAS2_ASCII_to_LSegs source code function. After searching through the grids that correspond to the land segments, there is no issues with the timeseries data for the grids. Meaning that the problem is with the grid to land segment transformation process.

We re ran the batch script on the command line and it seemed to have fixed itself. The data for the land segments no longer looks abnormal. Both the timeseries and graphs look fixed. See below screenshots of time series

Old:

New:

[jdkleiner]

Nice job confirming the source of the issue is in the grid-to-land segment transformation process. Curious that rerunning the batch script seems to have fixed itself, any thoughts on what may have caused the issue in the original batch script run?

[kylewlowe]

@jdkleiner
I'm not sure what the issue was. Last time we ran into a similar problem, we assumed that the terminal timed out in the middle executing the function for the year. Meaning the last bit didn't finish downloading. However, previously, a vale of 0.01 was repeated for the rest of the year in the timeseries. The varying but continuously high precipitation values for this particular issue makes me think it was caused by something different. I'm not familiar enough with the source code for the function to say for sure what happened.