Proposed Evapotranspiration Algorithm in 3.1.4 Beta

[peterd]

I would love both rain and ET to be a rolling 24 hour snapshot [...] but this may not be possible with rain being already accumulated for us.

Unfortunately not possible since Rain Today is a WeatherBug supplied value which resets at midnight.

 

I start my irrigation at 11pm

Using our example of 0.5" deficit being the point at which you'd irrigate, if you find that your runtimes to deliver that 1/2 inch of water are too long (run too far into the morning), but you're typically reaching that deficit say every 3 - 5 days, you might want to cut both your runtimes and the trigger point you set by 1/2 or 1/3 and just let the system water more often but for shorter times (shorter cycles seems to be where the current thinking is going anyway).

 

I am not an expert in this

Me neither!

Should this be Allowed Depletion[...]?

I think Allowed Depletion is actually how we'd figure out at what point (how much of a water deficit) we'd irrigate. I've been using 0.5" (since I had nice diagrams & tables for that value) as an example, but as each of us figures out the allowed depletion for our situation we'll know the absolute maximum deficit we can accumulate before watering. I think the presence of various plants and soil types within our landscapes means we'll have to come up with a number which satisfies the least drought tolerant plant (in the most porous soil) which we have. (As an aside, don't forget that lots of the ET research is done with an eye towards irrigation a single crop!)

 

Humph. Wait Soil Absorption has to do with how much of the rain was absorbed. Where is the formula for Soil Absorption based on rainfall? Looking...

Maybe I should have named this "Soil Absorption Factor" or "Relative Soil Absorption." (But don't really want to as it gets wordy. Maybe just "Soil Factor"?) We're not actually specifying this as for instance "inches absorbed per foot of rain" (an absolute absoption value for a particular type of soil). Rather, this is an adjustment based on the absorption ability of various types of soil relative to sand.

 

Peter

[Mark Sanctuary]

I have been studying that screen capture of the spreadsheet. I see now that it is varying the days run not the irrigation station run time...

 

I think I see now what your trying to do with the incrementing deficit and why you want to be able to reset it from a program. This would be much less programs to create.

[Mark Sanctuary]

shorter cycles seems to be where the current thinking is going anyway

 

From what I understand with drip irrigation a shorter run time is not suggested because of the capillary action does not have enough time to spread the water. The guy at the nursery in the irrigation section (keeping in mind I don't know his experience) says drip should run for no less than 1 hour to allow proper capillary action. He is also the one that said for my sandy soil I might want to increase my dipper size to 1 GPH to help with this because the faster flow helps sandy soil spread the water wider from each emitter.

[peterd]

Mark -

 

I think you're right. Shorter cycles for spray, longer for drip. (And even 'though I'm migrating more to drip (even about to re-sod with drip for my lawn), I must have been thinking spray at that moment. )

 

Peter

[Mark Sanctuary]

So lets recap where we are at in the algorithm at this point...

 

Sample_Rate = every_5_minutes
Sample_Count = 288_samples = (1440_minutes / Sample_Rate)
Evapotranspiration_Sample_List = append_list (Evapotranspiration_Sample)
Daily_Evapotranspiration = Evapotranspiration_Sample_List / Sample_Count

This code gets us to the Daily Evapotranspiration variable. This variable is a 24 hour snapshot of 288 samples in the day and is averaged. This data will be used at 11:59PM along with Rain Today for irrigation runs.

 

Soil_Absorption_Factor (sand 1, loam_sand 0.83, sandy_loam 0.67, loam 0.58, clay_loam 0.33, silty_clay 0.25, clay 0.17, concrete 0)

This code gets us to the Soil Absorption Factor variable. This variable is a factor of soil type to adjust the efficiency of soil absorption. User intervention required.

 

Daily_Water_Deficit = Daily_Evapotranspiration - (Rain_Today * (Soil_Absorption_Factor / 100))

This code gets us to the Daily Water Deficit variable. This is the amount of water that needs to be replenished for the day.

 

Irrigation_Requirement = Irrigation_Requirement + Daily_Water_Deficit

This code gets us to the Irrigation Requirement variable. This is the amount of irrigation that is required to replenish for the day. It is incremental so it can collect for days if necessary for lower deficit days. Days would be skipped until the Irrigation Requirement met the irrigation output threshold. ISY programs callback needed for resetting this variable.

 

Did I miss anything?

[Michel Kohanim]

Hi Guys,

 

This is excellent but I still need to know what happens at 24:00:01 ? Do we simply restart the calculation from 0? So, in effect, ET is the average for yesterday and I am still not certain what type of relevance it will have for today. Also, won't the average be skewed since it's now taking night time into consideration when basically there's no sun?

 

In most calculators, ET is based on an average per month (not per day) so perhaps we should also have a monthly ET.

 

Adding soil type and location type (inland vs. mountain vs. beach) is not a problem at all.

 

With kind regards,

Michel

[Mark Sanctuary]

My thought is reset at 24:00:01 and start over. Monthly average is less granular than daily and won't ebb-and-flow with our tracking as well. Since we are going to be having a incremental count of the deficit it should ride up and down with daily ET.

[peterd]

Michel -

 

I think the monthly average is used as historical data in many ET calculators to predict irrigation requirements. The daily average tells us specifically how much water has been removed from the soil (whether by evaporating or by being used by the plants) within the past 24 hours. Tracking this tells us when to water to replenish this.

 

Mark -

 

Maybe you can ask your friend from Johnson Controls to weigh in in this...

 

Peter

[peterd]

Mark -

 

My thoughts:

Sample_Rate = every_5_minutes

Not sure why 5 minutes. My Climate module update, for instance, is set to 60 seconds. So, I would expect to wind up with 1440 samples (more samples = higher resolution average).

Sample_Count = 288_samples = (1440_minutes / Sample_Rate)

Well, I suppose the sample count could be derived from the day divided by the rate, but that might not take into account what might happen if there were lost samples (suppose my DSL hiccups). I think incrementing an actual counter is simplest and most accurate.

Evapotranspiration_Sample_List = append_list (Evapotranspiration_Sample)

This one kind of loses me since I think of an array, linked list or other container of multiple values when I hear "list". Isn't this just an accumulator?

[...] the Daily Evapotranspiration variable. This variable is a 24 hour snapshot of 288 samples in the day and is averaged.

Here again, not sure why 288 samples? Since I think the ET could be sampled on every WeatherBug update (and the user configures how often (& therefore how many times daily) this happens). I'd say instead "This variable is a 24 hour snapshot of all the samples in the day and is averaged."

Soil_Absorption_Factor (sand 1, loam_sand 0.83, sandy_loam 0.67, loam 0.58, clay_loam 0.33, silty_clay 0.25, clay 0.17, concrete 0)

I'm now proposing that this be expressed in the UI as a percentage (sand 100%, loam sand 83%, sandy loam 67%, loam 58%, clay loam 33%, silty clay 25%, clay 17%). (The concrete was tongue-in-cheek. ) That's why it's now divided by 100 in calculating the Daily Water Deficit.

 

I'll post a suggested revised psuedocode shortly.

 

Peter

[Mark Sanctuary]

Dude don't be literal on the sample count thing, it can be anything, I just picked every 5 minutes as a base, no worries. I am sure the ISY can handle storing 1,000,000 if we wanted, pseudo code is suppose to be just the over view idea not writing the actual code. Append list is from my tcl background, it just means add the last sample to the end of the array list. What I am saying is store all samples then divide them by the total samples.

[Mark Sanctuary]

The concrete was tongue-in-cheek.

 

That's why I added it. ha ha

[peterd]

Re: sample frequency - I felt Michel was asking for very specific input, so didn't want this taken literally...

 

Re: append list - ok, so again not literal (i.e. store every sample) but just a way to say add this to a running total...

 

Re: concrete - oops, I mistook the sample frequency for it!

[peterd]

Here's my proposed (slightly revised) psuedocode:

 

In the Climate Module configuration:

Soil_Absorption_Factor (Example values: sand 100%, loam sand 83%, sandy loam 67%, loam 58%, clay loam 33%, silty clay 25%, clay 17%)

The Soil Absorption Factor configuration variable is a factor of soil type to adjust for the relative efficiency of soil absorption. User intervention required. I suggest that this be a value directly entered by the user (as opposed to, say, a soil-type pulldown list) so that they could derive this by measurement or by using the example values.

 

 

Throughout the day at each WeatherBug update:

Evapotranspiration_Tally = Evapotranspiration_Tally + Evapotranspiration_Sample
Sample_Count = Sample_Count + 1
# These are internal variables not available to the user

 

At 23:59 daily:

Daily_Evapotranspiration = Evapotranspiration_Tally / Sample_Count
# This variable is an average of all samples in the previous day.

Daily_Water_Deficit = Daily_Evapotranspiration - (Rain_Today * (Soil_Absorption_Factor / 100))
# Daily Water Deficit is the amount of water that needs to be replenished for the day.
# This is a signed float and can be a negative value in the event of lots of (absorbed) rain.

Irrigation_Requirement = Irrigation_Requirement + Daily_Water_Deficit
# This is the amount of irrigation that is required to replenish water lost since the previous irrigation run.
# This is an unsigned float and cannot be below zero.
# It is incremental so it can collect for days if necessary.
# ISY programs need a way to reset this variable.

My proposal to allow resetting this is to have Irrigation_Requirement appear as a predefined choice within the Variable pulldown of the Actions in Program Details. The only allowable selection would be Init To and the only allowable value selection would be zero. (Of course I defer to UDI if they have a preferred way to handle this.) Note that resetting Irrigation_Requirement to zero is a compromise until we have floating point math. What should really be done each time we irrigate is to subtract the amount of water applied from Irrigation_Requirement. (Thereby carrying an Irrigation Requirement balance.)

 

Daily Evapotranspiration, Daily Water Deficit and Irrigation Requirement are all available for use in programs. It is envisioned that

Irrigation Requirement would facilitate the most straightforward use of ET data within ISY. Irrigation would be deferred by skipping days until the Irrigation Requirement met the irrigation output threshold. The threshold is established within the user's program by setting an IF condition against the value of Irrigation Requirement.

 

Daily Evapotranspiration and Daily Water Deficit are provided in case advanced users want to program some other irrigation strategy.

 

 

 

Except for removing specifics (the sample frequency, the TCL-ism) which might be taken literally and revising the example absorption factors to account for the division by 100 in the Daily_Water_Deficit calculation, I haven't really changed anything. Tried to clarify comments somewhat, but if I failed let me know.

 

Peter

 

edited 6/8 00:30 to clarify the future requirement for user programs to be able to set Irrigation_Requirement to a non-zero value

edited 6/8 08:11 to clarify that Daily_Water_Deficit can be negative, but Irrigation_Requirement cannot

[Mark Sanctuary]

The hard part about text vs face to face on working this out is we could not understand the demeanor of each other and what was being said. So let me apologize if i was rough around the edges in how I expressed myself. This is something I am trying to work on and I guess I sill have some work to do.

 

This looks like a great hashed out definition of what was discussed and to put together!

 

So do we want to test case it in spreadsheet form and see how it works?

[Mark Sanctuary]

And I still think concrete should be in there.

[peterd]

Mark -

 

I also apologize if I took things too literally. Happens to me sometimes. I was thinking the same thing about the limitations of text vs. in-person. Overall, though, I think this has been a good collaboration so far!

 

Maybe we should put back concrete, if only to see if anyone picks up on it!

 

I agree about spreadsheet testing, but I'm not in a good position to do so right now (both because it will be another 6 months before I see a non-zero rain value in my climate module and because of time limitations). It also occurs to me that we don't know how much debugging UDI's initial v3.1.3 implementation of the instantaneous ET calculation may need. I guess if we can find a daily ET calculator we could input the base weather values to check against the ISY ET value...

 

Peter

[Mark Sanctuary]

I think I saw somewhere your in the bay area, well I am in the Sacramento area and I too don't think there will be any rain in the near future either. We will have to find a calculator that we can use to test with.

[peterd]

Yep, Alameda. So I'm guessing that you as well, in Sac'to, probably have no irrigation in the rainy season and no rain in the irrigation season?

 

Only thing about trying to test with a calculator is that we can't get all the actual values out of the ISY. Sounds like we need to find someone (*cough* guinea pig *cough*) back east who's interested in using ET with the ISY and willing to do some data capture (& maybe calculations)...

[Mark Sanctuary]

At 23:59 daily:

I wouldn't mind seeing the running values throughout the day being displayed in the WeatherBug. I think this time listed above really stands for when Irrigation programs would pole the variables and start the Irrigation run.

[Mark Sanctuary]

Well this spring was longer than usual with rain so if we had started this a couple months ago I would have had the perfect test bed. It rained a couple days then it would not for a couple days. I am sure there would have been some irrigation in between the rain. Oh well that's the past.

[Mark Sanctuary]

I am starting to think about the needed programs in the ISY... If its raining like cats and dogs we would need hold off irrigation so one thing I though of we need to check if Rain_Today exceeds the Irrigation_Requirement. This check would need to be done at the end of the day. Maybe something like this...

 

If
       Time is 11:59:00PM
   And Module 'Climate' Rain Today > 2 "
   And Module 'Climate' Irrigation_Requirement > 2 "

Then
       WeatherBug Irrigation_Requirement Set To 0

I don't know what inches to put in here yet so I just picked a number.

[peterd]

If its raining like cats and dogs we would need hold off irrigation [...]

True!

[...] if Rain_Today exceeds the Irrigation_Requirement.

I don't think this could ever happen, since Rain_Today will have already been subtracted from Irrigation_Requirement (happens when Daily_Water_Deficit is calculated).

 

What this does point out is that either (or both) Daily_Water_Deficit and Irrigation_Requirement could want to go negative. I'm sure that's valid for Daily_Water_Deficit (indicating a surplus of water for the day). This is the case shown for 4/15 in the Irrigation Requirement Balance example table. Suppose Irrigation_Requirement were at 0.25", and today's Daily_Evapotranspiration is 0.25". But, Rain_Today is 0.30" (and to simplify this example we'll specify pure sand - so soil absorption's not a factor). So now when the Daily_Water_Deficit is calculated it will be -0.05" (a surplus of water), and Irrigation_Requirement will drop to 0.20" (meaning the plants will be able to wait just that much longer before we need to water them).

 

I'm not sure what it means to have a negative Irrigation_Requirement. Is it any different than the case of a negative Daily_Water_Deficit?

 

Also (and I'm going to edit my earlier post so this thought doesn't get lost), resetting the Irrigation_Requirement to zero is a compromise. The reality is that we'll probably not hit the exact target. I.e. - we want to irrigate 0.5" worth whenever Irrigation_Requirement >= 0.5". After some tuning we find we're typically irrigating when Irrigation_Requirement is between say 0.52" and 0.56" (and maybe we've extended our irrigation time a bit to try to apply 0.54" each time). Once we have floating point math, what we really want is to leave the irrigation time at 0.5" worth, and subtract 0.5" from Irrigation_Requirement every time we irrigate. (This is exactly the approach shown in the table - carrying an Irrigation Requirement balance.)

 

Peter

[IndyMike]

Yep, Alameda. So I'm guessing that you as well, in Sac'to, probably have no irrigation in the rainy season and no rain in the irrigation season?

 

Only thing about trying to test with a calculator is that we can't get all the actual values out of the ISY. Sounds like we need to find someone (*cough* guinea pig *cough*) back east who's interested in using ET with the ISY and willing to do some data capture (& maybe calculations)...

 

Peter and Mark,

 

Private guinea pig reporting for duty...

Data capture is already in process. I've been switching weather stations and finally settled on the NWS at the airport (reliable). My poll rate is currently set for one hour.

 

My current problem - I'm due to climb on a plane in a few hours. I'll be joining you in sunny CA (LA area) for 10 fun filled days of EMI testing. The ISY is setup to Email me the data and I'll load to a spreadsheet (time allowing).

 

The travel situation is exactly the reason I want the ETo calculation. The temp here was 97 yesterday and may hit 100 today. This is way outside our normal range and I don't have a good basis for adjusting the irrigation (manual timer system). Forecast for the weekend is heavy rain. Not sure if I'll come back to a desert or a pond.

 

On a bit different note...

 

I noticed that the Orchestrator dashboard for the weather module includes forecast information. Anyone know how this is being accomplished? Is there a way of using forecast information in programs? I typically water in the early AM. I would consider skipping a day if the forecast indicated a high probability of rain (happens a lot around here).

 

IM

[Mark Sanctuary]

I'm not sure what it means to have a negative Irrigation_Requirement. Is it any different than the case of a negative Daily_Water_Deficit?

 

If we think of the ground as a glass, a negative is just the glass is overflowing, so when the rain stops we are at 0 no matter what, because the glass can't hold 110% it can only hold 100% and then start loosing it again.

[Mark Sanctuary]

I would consider skipping a day if the forecast indicated a high probability of rain (happens a lot around here).

 

I think we want to water for the deficit so the plants don't reach the wilt point. Future rain would be dealt with because its subtracted in the deficit formula. The only loss is a bit of extra water that may not get a chance to evapotranspiratpire before it rains.

 

The one thing that could happen though is it could start raining when the irrigation is already running but if its a light rain we would still want to water.