Proposed Evapotranspiration Algorithm in 3.1.4 Beta

[ryarber]

I'd like some pointers on how to use this data to control my irrigation. I know this will become even more helpful when variables are more advanced.

 

My understanding is that this is how many inches of water that are being lost daily from the soil, right?

 

What factors go in to its calculation? Does it take into account actual rainfall? It is strictly for a 24 hour period (from 12:00AM to 11:59:59PM), right? Is it's data reset daily? Does it recalculate once daily or is it recalculated every time the weatherbug data is updated? Where are the calculations done? Is it uploaded to a server where the numbers are crunched or are the calculations done right on the ISY device?

 

For a practical matter, how do we use this?

 

Thank you.

[IndyMike]

I'd like to second Ryarber's questions, and add some of my own.

 

First, a clarification:

 

My understanding is that this is how many inches of water that are being lost daily from the soil, right?

 

The ET calculation predicts the amount of water lost to evaporation for a particular plant type. There are different calculations for different plant types. As an example, water in a "grass area" will evaporate differently than a crop of corn.

 

A second factor is water loss due to percolation through the soil. In areas with heavy soil (clay) this may no be a significant factor (run-off or saturation could be). In my area (sandy soil) percolation is a huge loss factor.

 

There are tests that can be performed to estimate percolation losses. If you're interested, I can give you a link (a very knowledgeable person on the cocoontech forum).

 

Observations:

 

My ET calc is currently telling me that I'm loosing ~ .6 inches/day with @86 degrees, 58 %RH, and 16 mph average wind speed:

 

1) This appears very high. I have a number of "daily" ET calculators that are reporting less than half this value. The easiest to use is located here: http://www.cranfield.ac.uk/sas/naturalresources/research/projects/dailyet.html

 

2) The above leads me to believe that the ET calculation is a "snapshot" based on current conditions. In other words, if these conditions prevailed for 24 hours your water loss would be XX. Still seems a bit high, but I too lazy to dig into the calculation to determine an instantaneous value. If this is an instantaneous measurement, we will need to devise programs to accumulate the loss over a 24 hour period so that we can use the number the following day.

 

3) What has me confused is that when I switch between the two airports in the area (similar conditions) my ET goes from .5 in/hour to .6. Not sure what this implies - persistence?

 

4) Weatherbug station vary wildly in their reports. The two local schools near me are reporting 97 degrees and 2 MPH. The airports are reporting 87 degrees and 16 MPH. This is likely due to the placement of the measurement devices. You'll need to select a weatherbug station that accurately represents your local conditions. In my case, it appears to be the schools (sheltered by trees).

 

As Ryarber stated, I am very interested in using this calculation. Just need some additional details so I can implement things correctly (did I mention I'm basically lazy?).

 

IM

[Michel Kohanim]

Hello IndyMike and ryarber,

 

Thanks so very much for the observations.

 

We are using the algorithm found here:

http://biomet.ucdavis.edu/Evapotranspir ... mondoc.pdf

 

All calculations are instantaneous. We do use High Low temperatures for day as reported by WB. We also use pressure and wind speed from WB. Most calculators accumulate monthly values and then average them out (especially for high/low temps) the reason for which has historically been the lack of accurate instantaneous information. From our perspective, we can do both but decided that instantaneous would be more advantageous and accurate.

 

We calculate solar insolation and declination using lat/long and the date.

 

How do we use this data is a subject that I am hoping our users will be able to provide more feedback on.

 

With kind regards,

Michel

[Mark Sanctuary]

Since this is the daily ET instead of the potential ET I decided to use the data for daily adjustment of the runtime of each station.

 

I am working on a program example and should have it added to the Wiki in the next day or two.

[Mark Sanctuary]

Actually Michel I was wondering if you could give us one more data point in the Weatherbug module?

 

Irrigation inches/day = ( Evapotranspiration - Rainfall Today )

 

This would save a ton on trying to do math in programs.

[Michel Kohanim]

Hi Mark,

 

I am not sure where to get that data or how to calculate it.

 

With kind regards,

Michel

[IndyMike]

Mark,

 

The ETo number is being reported as inches/day, but it's an instantaneous value (as Michel stated above).

 

In order to be of use you'll need to divide the ETo reported by the interval time (time between updates) and "accumulate" the results over a 24 hour period.

 

EX for a 1 hour update rate:

T0: ETo = .3 inches/day (T0 = midnight)

T1: ETo = .31 inches/day (T1 = 01:00)

T2: ETo = .32 inches/day (T2 = 02:00)

*

*

*

T23: ETo = xx inches/day (T23 = 23:00)

 

Total ETo (daily) = ETo(0)/24 hours + ETo(1)/24 hours + ETo(2)/24 hours...+ ETo(23)/24 hours

 

If your update rate is faster (minutes), you will need to adjust the divisor.

 

Problems with the above -

1) We can't do floating point math at the moment. This will require "scaled integer" math (think Intel 8080).

2) We don't have a fixed time reference. My updates do not always occur at regular intervals. I'm not sure how to handle this at the moment. I don't know how to calculate the time since the last update.

 

While I think I understand the equations, I'm not nearly as software savy as you and others on the forum. I'm hoping you'll find an eloquent method of performing the above accumulator function. My brute force techniques would be very ugly.

 

IM

Actually Michel I was wondering if you could give us one more data point in the Weatherbug module?

 

Irrigation inches/day = ( Evapotranspiration - Rainfall Today )

 

This would save a ton on trying to do math in programs.

[Michel Kohanim]

Hi IM/Mark,

 

If you can tell me what needs to be done and what it "means" then we can add it to ISY code.

 

I forgot to mention that all calculations are performed within ISY. There are no server anywhere.

 

With kind regards,

Michel

[Mark Sanctuary]

Ultimately were we want to be with calculating ET is having the irrigation inches per day data. Maybe a rolling average of ET inches and rain inches over the last 24 hours is needed. Because once we have irrigation inches data we can calculate station run time to provide the lost water over the last 24 hours.

[IndyMike]

Michel,

 

Per Mark's post above, would it be possible to log weatherbug data to the ISY, with a time-stamp, over a 24 hour period?

 

This would allow you to accommodate missed updates (communication problems) while still providing a running prediction of ETo. I don't know how much data we are talking about, or what the ISY data storage capabilities are.

 

I am currently logging data (via Email) in an attempt to perform an offline calculation of the WB data. Example below:

 

Time,ET,Current_Temp,High_Temp,Low_Temp,Humidity,Wind_Speed_AVG,Wind_Speed,Pressure,Light,Rain_today
15:14:52, ,92 °F,59 °F,37 %,4 mph,3 mph,30.16 inches,94.8 %,0 inches

ET: 0.4752 inches/day
Current Temp: 89.9 °F
High Temp: 92 °F
Low Temp: 59 °F
Humidity: 37 %
Wind Speed Avg: 4 mph
Current Win Speed: 3 mph
Pressure: 30.16 inches
Light: 94.8 %
Rain Today: 0 inches

 

I'm hoping to import this to a spreadsheet using the calculations you provided.

 

First question - The reference you provided requires a measurement of Rs (solar radiation) to solve the following equation. Rs is not provided in the weatherbug data.

 

Rns = (1 - 0.23)Rs

 

I found an approximation of Rs in one of my calculators which involves the following:

 

Rs = (as + bs*n/N)*Ra

Where:

n = actual sunshine duration

N = maximum possible sunshine duration (based on time/date and lat/lon)

as = fraction of extraterrestrial radiation reaching the earth on overcast days (n = 0)

as+bs = fraction of extraterrestrial radiation reaching the earth on clear days (n = N)

as defualt = .25

bs default = .5

 

My question - Since you cannot calculate the n variable in real time... Are you using the weatherbug %light to approximate n/N?

 

Thanks,

IM

[Michel Kohanim]

Hi IM,

 

We use empirical data for the difference between coastal and inland regions as follows:

 * http://cagesun.nmsu.edu/~zsamani/papers/net_radiation_paper.pdf
 * KR = KRA * (Pressure/(101.3))^0.5
 * KRA:
 * Empirical coeff:
 * 0.17 for interior regions
 * 0.20 for coastal regions
 */
double kr = 0.18*sqrt(pressure/101.3);

/**
 * estimate RS
 * http://cagesun.nmsu.edu/~zsamani/papers/net_radiation_paper.pdf
 * rs = kr*sqrt(tmax - tmin)* ra
 */
double rs = kr*sqrt(maxTemp - minTemp)*ra;

/*
 * total solar radiation
 * http://biomet.ucdavis.edu/Evapotranspiration/PMmonXLS/PMmondoc.pdf
 */
double rs0 = ra*(0.75+2.00*0.00001*el);

/**
 * Net solar radiation
 */
double rns = (1-0.23)*rs;

/**
 * Cloudiness functions
 */
double f = (1.35*rs/rs0)-0.35;

/**
 * Rho = Steffan Boltzman constant
 * 0.0000000049
 */
/**
 * net clear sky emissivity
 */
double epsilon = 0.34-0.14*sqrt(ea);
/**
 * net long wave radiation
 */
double rnl = (-f*epsilon*0.0000000049)*((pow(maxTemp+273.15,4)+pow(minTemp+273.15,4))/2);
/**
 * net radiation
 */
double rn = rns+rnl;

 

I am still unclear as exactly what you would like captured, manipulated, stored, and used and in what intervals (currently, the interval is the polling interval as defined in the climate module).

 

There was a bug where we used max temp instead of max-min temp in calculating rs. That will explain why your readings are a little bit higher than the calculators.

 

With kind regards,

Michel

[Mark Sanctuary]

How about some pseudo code...

 

## Store the last 24 hours of evapotranspiration
evapotranspiration_list = append_list (evapotranspiration)

## Store how many evapotranspiration data points was collected in the last 24 hours
samples_count = list_length (evapotranspiration_list)

## Average the stored evapotranspiration data points
evapotranspiration_average = average_list (evapotranspiration_list) / samples_count

## Subtract rain today average from the evapotranspiration average
irrigation_inches = ( evapotranspiration_average - rain_today )

This is based on that the weatherbug "rain today" data is already an average for the current day otherwise it also would need this kind of code to track it too.

 

The idea I had is to start the irrigation at 11:30pm when the rain today number is the highest.

[peterd]

Mark -

 

Exactly. But if the ISY is keeping the tally, I wouldn't subtract the rain before presenting the ET total because of the differing soil absorption rates.

 

Peter

[Mark Sanctuary]

I think soil would be something each person would need to figure out and adjust the wait statement in each station program.

 

I don't think we want to get into soil type and crop type in the weatherbug module.

[peterd]

Mark -

 

Yes. Your post appeared just as I was editing mine for clarity. See revised post.

 

Peter

[peterd]

Michel -

 

I'm working on an in-depth post, but first a question: Which of the calculations from the paper you reference have you implemented - ETh (as described in Step 4), ETos (as described in Step 5) or ETrs (as described in Step 6)? ETos would be the obvious choice as it is calculated for grass (lawn). (As an aside, I find their labeling of these confusing as it seems that after Step 3 it should be 4a, 4b or 4c - since these are 3 different calculations.)

 

Cheers,

Peter

[Mark Sanctuary]

I am not suggesting we replace the current line of Evapotranspiration in the weatherbug but rather add another line below Evapotranspiration called Irrigation inches. This way both type of data would be there for some that may just want to use evapotranspiration only for their scheduling.

 

Temperature: 72.8 F

High Temperature: 73 F

Low Temperature: 58 F

Feels Like: 73 F

Temperature Rate: 2.6 F

Humidity: 49%

Humidity Rate: -0.02 inches/h

Dew Point: 53 F

Wind Speed: 3 mph

Average Wind Speed: 1 mph

Wind Direction: NNE

Average Wind Direction: NW

Guest Speed: 13 mph

Gust Direction: SSW

Rain Today: 0.04 inches

Rain Today Average: 0.04 inches/day<---- Add this if rain today is not an average.

Rain Rate: 0 inches/h

Light: 94.5 %

Light Rate: 0 %/h

Evapotranspiration: 0.4001 inches/day

Irrigation: 0.3601 inches/day<---- Add this so we don't have do ugly bit integer logic math in the programs.

 

...

[Michel Kohanim]

Hi Mark, I am still confused as to what needs to be done. Are you suggesting that we just have an average of rain today? How is this related to irrigation?

 

One thing I do not wish to do is to confuse everyone. From what I gather, rain today is already a total of inches for rain today. What is average?

 

peterd, thanks so very much. Indeed we are using ETs (ETos).

 

With kind regards,

MIchel

[Mark Sanctuary]

Then if "rain today" is the total then no change there.

 

Is rain accounted for in the Evapotranspiration equation? If not then we need to subtract the rain because it has done part of the job of replacing the water that has gone away. You know Gods big sprinkler system in the sky.

 

Temperature: 72.8 F

High Temperature: 73 F

Low Temperature: 58 F

Feels Like: 73 F

Temperature Rate: 2.6 F

Humidity: 49%

Humidity Rate: -0.02 inches/h

Dew Point: 53 F

Wind Speed: 3 mph

Average Wind Speed: 1 mph

Wind Direction: NNE

Average Wind Direction: NW

Guest Speed: 13 mph

Gust Direction: SSW

Rain Today: 0.04 inches

Rain Rate: 0 inches/h

Light: 94.5 %

Light Rate: 0 %/h

Evapotranspiration: 0.4001 inches/day

Irrigation: 0.3601 inches/day<---- Add this so we don't have do ugly bit integer logic math in the programs.

[peterd]

Michel -

 

First, a big thanks for implementing this. When we were discussing finding a public domain source for the algorithm, I really didn't anticipate this would make it to beta w/in such a short timeframe. I'm also happy to see from the discussion here that you're looking for input to change/refine this during the beta.

 

I'll begin by saying that I'm no expert on ET (still learning along with many of us), so please accept this as my humble opinion based on what I think I've learned so far. I know this is a long post, but hope it will help all of us refine our understanding of this subject. For all the complexity in implementing this, the concept is simple. Quoting the PDF I mention below, "An ET-based control system manages the irrigation system by calculating water lost from the landscape, measured in inches and then replaces lost water using the irrigation system."

 

Here are the resources I've found most helpful:

 

The best single info source I've found is the Irrisoft website http://www.irrisoft.net/wr/insite.cfm. They have a download-able "Landscape Water Management Manual" PDF which explains ET and irrigation very well. They also have a program "InSite Irrigation Scheduling" which is free to use with historical ET data (they make their money on subscriptions to live ET data).

 

This diagram from the Irrisoft PDF shows very succinctly how a daily ET reading can be used to determine how often to water and how much water to deliver. (Of course we have to figure out how to translate "how much" into "how long" to run the irrigation, but I'll get to that in a minute.)

 

 

So, based on this it seems that the instantaneous value doesn't help directly. When I track this value w/in the ISY, I see great variations over a short time (as sun and wind conditions change). And, according to the Irrisoft manual, the ASCE formula you've implemented requires hourly readings, and the daily number seems most useful in calculating irrigation frequency and system run-time.

 

The diagram mentioned above does simplify out one factor. As Mark points out, the daily rainfall total should be subtracted from the daily ET value

to give a final daily number representing the water loss for the day. However, since rainfall rates and soil types have a huge effect on rainfall absorption, maybe this should be done in user code. (For example, the same daily rainfall total can mean something far different in terms of its impact on daily irrigation requirements depending on not only soil (e.g. clay vs. sandy), but also how fast the rain has fallen. The entire daily total falling on clay soil within an hours time could have a negligible effect on irrigation needs, while the same amount falling on sandy soil spread over 24hrs could result in a surplus delaying irrigation for one or more days.) Ideally, once we have floating point variables, this will be no problem. (BTW, with only integer variables currently, I understand Mark's request for this calculation w/in the ISY, so it may be worth including. And that alone might be sufficient for some folks, but doesn't take into account irrigation less frequently than daily.)

 

Here's what I think would be most useful to have w/in ISY: A daily ET value (averaged out from at least hourly readings), calculated at a time of day just before the Weatherbug daily rainfall total resets (so both daily values can be examined at once) - just as Mark suggests in his pseudocode. And, a running total of daily ET readings, with a way to programmatically reset the total. (I used to believe in daily irrigation, but the more I learn about the subject the more I think it should be only once every several days, thus the running total...)

 

For those of us who live in areas (such as my location in the SF Bay area) where 99% of rain is confined to a rainy season (and no irrigation happens during that time), the running total would be enough. For those who live in areas where it rains on and off throughout the year, the daily number can be used along with the daily rainfall total to implement a set of programs to account for rainfall rates, totals, and soil absorption ("Effective Rain").

 

Or, per Mark's suggestion, a built-in rain subtraction used instead. What would make that approach really slick would be a place in the configuration where a user could input a soil Absorption Factor (value 0 to 1, defaulted to 1) so that the irrigation inches total presented would take into account Effective Rain. If going down that path, you could have 4 values in the climate module: Daily ET, Running Total ET, Daily Irrigation Inches (Daily ET - (Rain Today * Absorption Factor)), Running Total Irrigation Inches. I think with those 4, it would be easy for anyone to implement as simple or comprehensive an irrigation strategy as they want, either daily or less frequently.

 

How I would use this is as follows. First, I'll use the InSite program to figure out the baseline for irrigation (how much water does each zone deliver per minute, how does soil absorption affect this, what are the differences in water requirements based on different types of grass/plants/trees in each zone, etc.). Once I have a baseline for the driest month of the year (and the historical ET value this is based on), I'll create my irrigation timer program(s) for the ISY, with the times calculated to deliver a specific amount of water (in inches) to the landscape. Finally, I'll create the trigger program(s) which will look at the running total ET (or Running Total Irrigation Inches) to determine when to irrigate (and reset the running total). I think figuring out how often to water will be enough, but if it turns out I need to adjust the run-times for the various zones based on different ET & rain rates I'll use the daily ET (or Irrigation Inches) values to set a "scaling factor" as a multiplier to use within the timer program(s).

 

Hope this helps.

 

Peter

[Mark Sanctuary]

peterd covered just about everything I am thinking of so I am "liking" his last post.

 

One note I can build a javascript webpage for Michel after we land on a solution that would help the user figure out their runtimes based on what the ISY puts out so we would not need to send them to an outside edu website for calculating the runtimes. I actually have done a rough draft this webpage idea based off this link.

 

http://irrigation.wsu.edu/Content/Calcu ... -Times.php

[peterd]

Just as a P.S. to my earlier post, if the ISY implemented an Absorption Factor based on soil type. Assuming Sand as having the highest absorption (i.e. 100%), the factors for the major soil types (based on their relative absorption rates in inches/hr) would be:

 

Clay 0.17

Silty Clay 0.25

Clay Loam 0.33

Loam 0.58

Sandy Loam 0.67

Loamy Sand 0.83

Sand 1

 

Peter

[Mark Sanctuary]

I think doing the math for Irrigation inches now is much easier and quicker than waiting for the floating point math to be added to programs. I vote for doing it and just adjusting the length of runtime in the wait statement in the program.

[peterd]

Mark -

 

Glad you're "liking" my post. Hope Michel does, too.

 

By "doing the math for Irrigation inches now" I assume you mean having UDI implement the value I am calling "Daily Irrigation Inches." That's sufficient for one of the 2 approaches to irrigation (fixed frequency - e.g. daily - with varying duration). For the other (fixed duration with varying frequency) the "Running Total Irrigation Inches" is the equivalent. Note that this requires some way to reset (or decrement) the running total in the program once irrigation completes.

 

I do agree that in the absence of floating point variables the value of the ET data increases by an order of magnitude if UDI implements the ET minus Effective Rain calculations. I also would strongly urge the implementation of running totals, as this is also extremely difficult to do in ISY programs today (w/o floating point variables), and covers the other major school of irrigation thought.

 

Peter

[Mark Sanctuary]

By "doing the math for Irrigation inches now" I assume you mean having UDI implement the value I am calling "Daily Irrigation Inches."

Yes, sorry my children were asking me questions at the same time I was typing so I just pressed the send button so I could pay attention to them hence the funkness...