Topic: Instantaneous Rain Rate vs 15-minute End Of Rain Event

[RPinCA]

I'm looking for insight between what I perceive as conflicting goals. It's my understanding that a given rain event is defined to end after 15 minutes with no measured rain. Thus, I must first ask: is this an true definition or a misunderstanding on my part?

If it is a true definition, I find it in conflict with computing Instantaneous Rain Rate (IRR) from TBR data. 1, 2 or 3 bucket tips per hour would be treated as 1, 2 or 3 rain events rather than a continuous light rain. However, this is not how I observe rain here in Sacramento. We often see generally continuous rain with less than 4 tips per hour at times, such as in the graph below.

With IRR computed from quantity and time as dQ/dT, it is possible to have an algorithm that rolls off the current IRR such that a new tip simply keeps the current IRR in place. A recent update to the Wunder Weather Station now presents rain quantity updates the second they occur. This provides a dQ of 0.01" and a dT measured in seconds, the result multiplied by 3600 to obtain an hourly rate. I enjoy having an IRR that's updated in real time; I want to know how hard it's raining "right now".

The graph shows a series of rain events on 20 May 2016 in Sacramento as registered by a RainWise wired TBR. An early IRR of 0.42"/hr is seen, followed by 0.18"/hr, then dropping to 0.05"/hr around 17:00. No further rain is detected until ~18:50, so the IRR rolls off to zero. Note that a new bucket tip maintains the current IRR as it rolls off, beginning a new timing period. The algorithm is very exact in this regard.

The second rain event begins at 18:50:06. The second bucket tip is at 19:00:24 for an IRR of 0.05"/hr, as the dT is over 10 minutes and there is no rounding. However, the third bucket tip is at 19:15:44, giving at dT of 15:20 - longer than 15 minutes. In the third rain event, the final bucket tip occurs 24:51 after the preceding tip, well over 15 minutes, yet clearly the final stage of the third rain event.

This is a real-world example of what are clearly three rain events, but two of them would be split if a rain event is defined to end after 15 minutes. With this in mind, the algorithm slightly redefines the 15 minute period to "15 minutes after a bucket tip would have resulted in an IRR of 0.02"/hr or more." Thus, rain events end 45 minutes after the most recent bucket tip, giving results that correspond to observations.

While I am satisfied with the IRR computations for my own use, I still wanted to ask the group about my assumptions. Is the 15-minute rain event a true definition? Is the 45-minute rain event a reasonable definition? Would a "proper" IRR algorithm reset timing after 15 minutes, resulting in five rain events on this day?

Thanks for your consideration of this bit of minutia.

[ValentineWeather]

Not sure I can answer everything but my understanding of rainfall rate is the intensity over a period of time not set in stone what time period.  Never heard of 15 minutes before. I found this definition  http://disc.gsfc.nasa.gov/hydrology/data-holdings/parameters/rainfall_rate.shtml


Rainfall rate is a measure of the intensity of rainfall. It is measured by calculating the amount of rain that falls to the earth surface per unit area per unit of time.

[PaulMy]

From Davis manual:
Rain Rate will show zero and the umbrella icon does not appear until two tips of the rain bucket within a 15–minute period.

It takes two tips of the rain bucket to begin a storm event and 24 hours without rain to end a storm event.

Rain Rate
Press RAINYR to display the current rain rate. Rain Rate may be
displayed as either inches per hour (in/hr.) or millimeters per hour (mm/
hr.). Rain Rate will show zero and the umbrella icon does not appear
until two tips of the rain bucket within a 15–minute period.

Month–to–date precipitation
Press RAINYR again to select the month–to–date precipitation record. Monthly
rain displays the precipitation accumulated since the calendar month began.
Month–to–date precipitation is displayed in inches or millimeters (mm).

Year–to–date precipitation
Press RAINYR a third time to display the year–to–date precipitation record.
Yearly rain displays the precipitation accumulated since the 1st of the month
you’ve chosen as the beginning of your rain season in Setup Mode (See “Screen
13: Rain Season” on page 18). Year–to–date precipitation is displayed in inches
(in) or millimeters (mm).

Daily Rain
Press RAINDAY to display the rain accumulated since 12 midnight.
Any rain accumulated in the last 24 hours displays in the ticker at the
bottom of the screen.

Rain Storm
Rain Storm displays the rain total of the last rain event. It takes two tips of the rain
bucket to begin a storm event and 24 hours without rain to end a storm event.
Press RAINDAY to toggle between the daily rain total and the Rain Storm total.
Rain accumulation may be displayed as either millimeters (mm) or inches (in).

Paul

[gginnj]

Hi,

I'm in the process of setting up my own station. I started with the rain gauge. It's a tipping gauge that I picked up where it just has two wires to connect to the station is was supposed to be for - So, I've hooked up that to my rasperry pi, which sees it as a physical switch - when the bucket tips, the pi sees it as the switch being pressed.
I thought the best way to work with the data is to record it in raw format - by that I mean Date, Time of each tip to a database, where time includes microseconds.

Now My Display for rain data will interpret the raw data - and either display rain intensity or rain quantity.
Rain intensity really is only accurate at that moment (of the bucket tip) - and quantity is cumulative (either by storm or by hour or by day...)

For my purposes - I consider whether a tip is to be included in the current storm (or to group it as a new rain storm event) is it must have been
a tip within 60 minutes of the last bucket tip.

My display will take all the intensities (at each tip), and then display a graph over time (from start of the storm to last piece) - where the Y axis is the
rain intensity (inches/hour) and the X axis is the time within the storm (a ratio based on the start/stop timeframe)

What I like about the intensity graph - is it truely visualizes the storm itself with intensity over time 
 [ You are not allowed to view attachments ]

Aside from graph, I also display the date/time of each tip (and the cumulative rainfall) for the storm
 [ You are not allowed to view attachments ]
 [ You are not allowed to view attachments ]

I can also switch to quantity view - to see hourly, daily or monthly rainfall - which encompasses all storms - only the intensity graph is storm specific.

RIght now, my page is specifcally for rain display - I'm not sure how I'm going to massage this into historical storage; it would be impractical to have to calculate quantity
   I'm probably going to have a utility that will scan the raw data and write back to a database, the hourly totals - so another front end display can pull those in to show
   temp, humidity, etc for the historical display (but that is later).

[RPinCA]

Here's some C++ code that will compute instantaneous rain rate (IRR) as you wish. It works for me quite reliably during four months of use. Call this routine once per second and mRainRate will be updated properly, giving results like the graph I posted originally. If you call it more than once per second, it will wait until the next second-in-day before updating mRainRate.

When a bucket tip is sensed, the IRR is computed based on delta-quantity and delta-time in seconds. If the current IRR is zero, an IRR of 0.01"/hr is chosen (or deltaQty/hr if for some reason the deltaQty is over 0.01").

In the seconds after the bucket tip, the IRR is computed as though a bucket tip had happened that second. Since it hasn't, if the computed IRR is above the most recent actual IRR, the result is discarded. When the computed IRR falls below the most recent actual IRR, the IRR is updated to the new, decaying value. Done this way, the next time a bucket tip is sensed, the new actual IRR at the time will be the same as the displayed decaying IRR.

IMO there is no reason to do this by-millisecond. Gary (maker of Wunder Weather Station) changed his firmware to provide by-second updates of rain qty. Based on studies I have read on the net, by-second is state of the art and highly precise. This has proven true for me. You won't get any added value from by-ms calculations. However, if you really want to press on with ms, the routine could be modified from Second In Day (SID) to msInDay if you multiply all the relevant values by 1000.

Note that SID can range from 0 to 86399, so you need 32-bit integers for this to work as written. While this is in C++, changing it to C is straightforward. All variables that begin with lower case 'm' are member variables of the class CRainGauge.

Good luck! Please let us know your results.

RP

[gginnj]

I decided to use the microsecond in the calculations in case it ever was needed - where there are two tips within the same second.
In general, if this is occuring then the intensity would wind up as 0 inches/hour since the delta between both tips would be 0 where as
with the microsecond, it would still calculate correctly.  Not so sure however, I want to be around if it's raining that hard.

Right now, I'm using a tip bucket that has a volume of .03" / tip - however, eventually, I'd like to try to work on creating my own
bucket that would have a tip volume equiv to .005" / tip - in that case, in a very heavy rain I can see the potential for multiple tips per second.

I'm finding with .03" / tip - it's taking quite awhile for my gauge to sense the first tip on light rain - and have had some storms that never
made it to the first tip.

[RPinCA]

I decided to use the microsecond in the calculations in case it ever was needed - where there are two tips within the same second. In general, if this is occurring then the intensity would wind up as 0 inches/hour since the delta between both tips would be 0

No... it's deltaQty / deltaTime. I tested for two tips in a second; it calculates properly. This problem is too obvious to have overlooked.

Do whatever you want, but do it for the right reasons.

[gginnj]

No... it's deltaQty / deltaTime. I tested for two tips in a second; it calculates properly. This problem is too obvious to have overlooked.

If your only using whole seconds - and you have two tips in the same second - your delta will be 0 - time2-time1

I think the difference here is my system is based on tips (not time) for logging the activities, whereas your function reads volume once a second, so if there
were two tips in a second, you would see the volume increase by double the tip amount. Your sensor calculates volume for you - my setup doesn't do the
calculations at the sensor - only that an event was triggered (tip).

I can't read volume from my gauge - only that it tipped - so if it tipped twice in a second - and I wasn't using microseconds, I would log the same
time (hh:mm:ss) twice - giving me a delta of 0 for that span - thus why I'd need to drop to microseconds.

My code is pretty much the same as yours on the intensity calculation - and it really isn't any much more of an effort to work with the microseconds.
All I'm doing with the sensor equipment is logging date and time using wget to trigger an API on my website with the values - to keep processing time down.
of course if I lose internet - it also logs locally, and can update when the connection comes back up.

for the graphical/display end - is a web page with php server side for the calculations. Since raw data is being logged, it allows me some flexibility on what
I want to do with the numbers for the display.

[RPinCA]

If your only using whole seconds - and you have two tips in the same second - your delta will be 0 - time2-time1

Call this routine once per second

If you call the routine once per second, you will never have a dT of zero. There is code prior to the snippet I posted that prevents the routine from being called more than once per second. Thus, dT will be a minimum of one.

Clearly you are far wiser and more experienced than I.

Unsubscribe.

[gginnj]

To clarify, your routine works for you and never have a delta less than 1 because you limit how often you read the gauges volume.

I can't read volume from my gauge, so I can't use scheduling or time to determine when to read my sensor, all my gauge can tell me is I tipped, and through calibration, I know the tip is .03 inches. I don't keep a running volume, I only log time and date of the tip. My routine CAN be triggered more than once per second so microseconds are needed. Volume and intensity is calculated by a different routine whether it's being displayed realtime or after the storm has ended.

Two different methods to accomplish the same goal. Both work for their respective gauges.

Your output is great, nice graphing too.