Proposed Evapotranspiration Algorithm in 3.1.4 Beta

[Mark Sanctuary]

Irrigation_Unapplied_Remainder

I don't think this variable exists. I think Michel suggested this because he did not understand that the decision as to whether irrigation is needed yet is simply looking at whether Irrigation Requirement has met or exceeded Water Applied per Irrigation. If you want to know whether to adjust your irrigation times, then add an email to yourself of Irrigation Requirement after running the System command which subtracts Water Applied per Irrigation - at that point it will be the remainder. (As an aside, going back to that example Irrigation Requirement Balance table I posted, having some remainder should not be a problem. Only if it were consistently high would adjustment be needed (maybe longer times, maybe shorter...)

Personally I want it fully automated and don't want to be emailed to adjust runtimes, and have planned a use for this variable already (see code example on this post a few pages back). When we have heat waves that really sucks the water out of the plants and soil I want to have the system respond on its own with lengthening the runtime automatically. My guess is that Michel was suggesting this very thing because of the code example I showed and is giving us the option this way.

 

Maybe [...] we should note the "Daily" variables are running totals that are displayed throughout the day and at 23:59:59 really is the moment the final measurement is taken before the "Yesterday" copy happens at 00:00 and "Daily" measurements reset.

But are these in fact running totals?

 

If you did these calculations repeatedly throughout the day (and at the moment they are specified as happening only once @ 23:59(:59)), would the results be useful? As an average, Daily ET could swing up or down as more samples were collected depending on the instantaneous ET samples. Daily Water Deficit could rise at first, then fall if it rained later in the day. I think the real value in these is as a record of how what happened yesterday (sun, wind, rain...) affects whether irrigation is needed today.

Useful because the GUI looks ugly if there is just a big fat ZERO looking at you all day long. I would like to see how the averages are coming along throughout the day.

 

Please ignore the sarcasm, tired and just goofing around.

[Mark Sanctuary]

4. Reset Daily_Water_Deficit, Irrigation_Requirement, and Irrigation_Unapplied_Remainder. I think this command would only be used to reset the system and start over and this would be the variables that would start over... this may need adjusting after testing the next ISY firmware release.

Changed my mind about this, only reset Irrigation_Requirement, and Irrigation_Unapplied_Remainder. This way we can trigger a reset on just the irrigation needs. Also I can't think of when I might want to reset Daily_Water_Deficit outside of the ISY managing it.

[Mark Sanctuary]

Are we going to be using the "Yesterday" values for our Irrigation runs or are we going to be using the "Daily" values?

 

Because if we are going to just use the "Yesterday" values then do we really even want to see the "Daily" values in the GUI or have access to the "Daily" data in programs.

[peterd]

Are we going to be using the "Yesterday" values for our Irrigation runs or are we going to be using the "Daily" values?

 

Because if we are going to just use the "Yesterday" values then do we really even want to see the "Daily" values in the GUI or have access to the "Daily" data in programs.

I think the confusion has been that I've been calling "Daily" the value I would use today (i.e. the value calculated at 23:59:59). While technically calculated yesterday (just), this is still the most recent (complete) Daily value we have access to.

 

If the label Daily_ is too misleading, then let's come up with a better convention (Daily_Water_Deficit becomes Water_Deficit_Yesterday and Daily_Evapotranspiration becomes Evapotranspiration_Yesterday) and not show any "today" values.

[peterd]

Mark -

 

Re having a remainder variable:

 

While I used the example of "email me", couldn't you just retest Irrigation_Requirement after the main irrigation run (and after the decrement) and if over X then enable a "Top Up" program to give some additional water?

 

Personally, I think this ET stuff is very hard to understand (I know I need to think hard about it). My perspective is to make it simple to do the 99% solution, possible to do the 1% "extra mile" and hard to get confused & off-track about the whole thing. That's why I'd look for ways to accomplish that 1% with a minimum of extra variables, commands, etc...

 

Peter

[Michel Kohanim]

Mark,

 

Please do not confuse me. Most of the variable names you have stated do not exist in Peter's algorithm. Please do be kind enough to stay consistent otherwise we run the risk of having an infinite loop of going back and forth. Thanks.

 

Peter,

 

Let me see if I understand:

Michel -

We're not testing against Irrigation Requirement - Water Applied Per Irrigation, so no need for a "Need this Much Water" variable (Irrigation Requirement is how much water we need.

 

Irrigation Requirement is automatically decremented by Water Applied Per Irrigation every time the watering cycle is completed. So, the user can decide whether or not to water again. i.e if this value is > 0, then the user might want to reapply water. Correct? Now, what is maximum number of inches for Irrigation Requirement?

 

As far as reset, I am assuming that you might want to reset Irrigation Requirement at boot up.

 

I have to think about persistent values.

 

Soil absorption factor will be a drop down with percentages from 0% to 100% with meaningful names for those that we know. Do you happen to have a list?

 

With kind regards,

Michel

[ryarber]

I have another question. Are the irrigation cycles going to be triggered by the module or will they be triggered by a program written in the programs section? If done by the module, there needs to be a way to hold an irrigation cycle if you need to hold it. For instance, if I am having a party at the house, I don't want my guests being sprayed. Also, if I have just applied chemicals to the yard, I may want to hold irrigation for the night.

 

In the past, I have assigned a KPL button to hold irrigation cycle for the night.

[peterd]

Are the irrigation cycles going to be triggered by the module or will they be triggered by a program written in the programs section?

Your program makes the decision whether to irrigate based on checking how much water has left the soil vs how much you expect to replenish. You can add your own test of what time of day you want to start, disable the program, etc.

 

Peter

[peterd]

Mark,

 

Please do not confuse me. Most of the variable names you have stated do not exist in Peter's algorithm. Please do be kind enough to stay consistent [...]

Michel -

Agreed as to consistency, but to be fair after reflection I do suggest we revise a couple of variable names just to avoid confusion among users (see my recent post re "Daily_" vs "_Yesterday" naming convention). The base names stay the same, but for clarity I suggest:

 

Water_Deficit_Yesterday instead of Daily_Water_Deficit

Evapotranspiration_Yesterday instead of Daily_Evapotranspiration

 

If you agree, I can update my algorithms post accordingly.

Irrigation Requirement is automatically decremented by Water Applied Per Irrigation every time the watering cycle is completed.

If by "automatically" you mean "when the user's program triggers it" then yes.

So, the user can decide whether or not to water again. i.e if this value is > 0, then the user might want to reapply water. Correct?

This is what Mark is seeking. I think most users will simply let any non-zero remainder ride. (And I think Mark can do what he wants to without our adding another variable.)

 

Here's an example which may help:

- My ET values for the day are typically 3 to 5 mm.

- I've decided that I'll allow about 12mm water loss from the soil before watering, so I write my program to test Irrigation Requirement >= 12mm.

- I aim to replenish 12mm on each watering, so I set 12mm for Water Applied per Irrigation in my Climate Module configuration.

- New installation so we start with Irrigation Requirement at zero.

- Three days pass with ET values of 3mm, 4mm and 3mm. Not yet 12mm so no irrigation yet.

- The fourth day has an ET of 5mm. Now Irrigation Requirement reaches 15mm.

- My program applies 12mm, triggers the decrement by 12mm and Irrigation Requirement is now 3mm.

 

So is the 3mm a problem? I don't think so. If a similar ET pattern continued I'd simply water again in 3 days instead of 4... I believe Mark's concern is if somehow on occasion a single day's ET was so high as to leave a very large balance (say 6, 8 or 10mm in our example). He'd like to water again to try to replenish that remaining water loss. I'm not saying that's not a valid approach, but I think most users would let this ride since it may simply mean that their next full cycle will run the next day instead of 3 or 4 days out. If a large Irrigation Requirement balance was happening to me often, I'd adjust my Water Applied per Irrigation value (and my program's IF comparison) to better match the ET pattern.

 

Now, what is maximum number of inches for Irrigation Requirement?

I think this is our best guess here. Irrigation Requirement is cumulative water loss from the soil, and how much loss to allow between waterings is ultimately based on the root length of the plants (short for grass, long for trees, etc...). The examples I've seen all deal with daily ET values below one inch (so several days before an inch is lost from the soil), and I wouldn't imagine that you'd get higher than a single digit (in inches) Irrigation Requirement before watering.

 

As far as reset, I am assuming that you might want to reset Irrigation Requirement at boot up.

If Irrigation Requirement is persisted (once a day @ 23:59:59), then I wouldn't reset if I rebooted. In the Irrigation Requirement Balance model of ET use (there may be another model, but I haven't found one in my research), you'd most often have a non-zero Irrigation Requirement. The only reason I could see for wanting to reset would be an extended outage (ISY down for days, so Irrigation Requirement balance is now completely invalid).

 

I have to think about persistent values.

If Irrigation Requirement is persisted as soon as it is calculated, you'd probably never be more than a day's ET off (in the case where the ISY reboots (off for < 24hrs) and comes back to life between say 23:58 and 00:01). More likely just part of a day's ET. I can't see persisting the tally and sample count on every increment (too many flash writes), but I suppose you could choose hourly (or even a back-off algorithm where the more uptime the less frequent the snapshot). It would be good to persist the tally and sample count before an intentional reboot (e.g. firmware upgrade).

 

Soil absorption factor will be a drop down with percentages from 0% to 100% with meaningful names for those that we know. Do you happen to have a list?

Excellent, thanks!!! While I did see an academic paper with over 2000 soil types I think this list is most useful:

 

Sand 100%

Loam sand 83%

Sandy loam 67%

Loam 58%

Clay loam 33%

Silty clay 25%

Clay 17%

 

Hope this helps!

Peter

[Mark Sanctuary]

In the bay area this would be a less then 1% issue but in the California valley where we have 30/40 day heat waives in the summer I think I will need to cover this but don't worry I figured out a work around...

 

MainIrrigationRun

If
       Module 'Climate' Irrigation_Requirement > 0.70
Then
       Set 'Station1 Back Drip1' On
       Wait  84 minutes
       Set 'Station2 Back Drip2' On
       Wait  84 minutes
       Set 'Station2 Back Drip2' Off
       System Command Decrement Irrigation_Requirement
       Program Run HighHeatSecondRun

HighHeatSecondRun

If
       Module 'Climate' Irrigation_Requirement > 0.35
Then
       Set 'Station1 Back Drip1' On
       Wait  42 minutes
       Set 'Station2 Back Drip2' On
       Wait  42 minutes
       Set 'Station2 Back Drip2' Off
       System Command Reset Irrigation_Requirement

[peterd]

In the bay area this would be a less then 1% issue but in the California valley where we have 30/40 day heat waives in the summer I think I will need to cover this [...]

I'm glad we have a couple of climate extremes represented. If we can get IndyMike to weigh in here, all the better...

but don't worry I figured out a work around...

Excellent! (I knew you would.) I think we're in agreement that for maximum flexibility we will need the ability to do arbitrary math with these values (e.g. decrement Irrigation Requirement by different amounts directly in code). But, that's down the road after we get floating point variables. Meantime, you've found a very reasonable solution to the limitation of having only a single Water Applied per Irrigation value with which to decrement Irrigation Requirement.

 

Michel -

 

Mark just proved conclusively the need for the ability to reset Irrigation Requirement from a program.

Peter

[Mark Sanctuary]

3. ISY calculates daily averages ... this will be stored in Yesterday's ETo

4. At 00:00, ISY copies today's average ET to yesterday's average ET and clears today's

5. The same goes for Daily_Water_Deficit

When Michel said this I though he was on to something beyond what we where doing with just the launch irrigation in the 23:59 to 00:00 window.

 

The running total we are collecting for the day is Today data. Yes I think we should see the running total all day long. This is what the 23:59 irrigation run is using.

Today_Evapotranspiration

Today_Water_Deficit

 

The saved value at the end of the day that is kept for the next 24 hours is historical Yesterday data.

Yesterday_Evapotranspiration

Yesterday_Water_Deficit

 

I think having a one minute window to start the irrigation run between 23:59 and 00:00 is a bummer. I want to be able to start my runs 23:00 so we can avoid having the irrigation cause us low pressure on our morning bathing. This is also why I would like the running total instead of a small window of time to launch the irrigation run.

 

Michel could just look back over the last 24 hours from whenever the irrigation run is launched.

[peterd]

Mark -

 

There is no running total as currently written up. What you're proposing is that the ISY perform the entire calculation (everything currently in the "At 23:59 daily" section except Irrigation Requirement) on every WB update. (Irrigation Requirement can't be calculated every time because it would then add the ever increasing (in the absence of rain) Water Deficit multiple times.) Because there may be other things users are looking for (e.g. I care about the light values from WB) which demand responsiveness from the home automation, this may be very high (e.g. 2880 times daily with a :30 update interval). Maybe that matters, maybe not...

I want to be able to start my runs 23:00 so we can avoid having the irrigation cause us low pressure on our morning bathing. This is also why I would like the running total instead of a small window of time to launch the irrigation run.

I understand about the water pressure issue. May I suggest looking for some historical daily ET values for your area (or a similar climate) and plugging them into a spreadsheet (as IndyMike is doing with the ISY's current instantaneous ET values). I'd like to know if watering according to a true Irrigation Requirement Balance model will result in watering more than once a day. If not, there's no reason you couldn't use the value calculated at (moments before) midnight to schedule irrigation 23 hours later. The balance will simply carry over. Unless the actual soil loss limit for your plants is less than one day's ET this would work.

 

I have to be offline for the day. I'm going to ask you to ponder this for a while before responding, and we can continue the conversation this evening. Michel is asking us to stabilize the description. I just want to be sure before changing the calculation strategy and introducing more variables.

 

Peter

[Mark Sanctuary]

[...] I'd simply water again in 3 days instead of 4 [...]

Oh I wish I lived in the bay area... I really don't care for the heatwaves here but that's another story.

 

In my sandy soil my plants would not far well in the the heatwave, my runs are daily and sometimes I have have to trigger a second run if I see plants wilting bit the evening. Spring and fall I might get to 3 days apart.

[Mark Sanctuary]

I have to be offline for the day. I'm going to ask you to ponder this for a while before responding, and we can continue the conversation this evening. Michel is asking us to stabilize the description. I just want to be sure before changing the calculation strategy and introducing more variables.

Will do, you are starting to know me and that I like to discuss out my ideas along the way until it molds into a solid plan.

[peterd]

Mark -

 

Just had a brainstorm. We leave all as is. No mention of Today or Yesterday, Daily means what it says (a 24 hour period).

 

The reason for 23:59 is because WB resets Rain Today at 00:00. So, we ask Michel for a configuration value of what time of day the once daily calculations happen. This plus one more internal variable tracking Rain Today will allow the calculation to be done at the same time every day, whenever you want.

 

What do you think?

 

Peter

OK, Now I'm really offline...

[Mark Sanctuary]

Just had a brainstorm

I call mine brain toots! (I would use the real word but my wife has me trained not to use it so our boys won't use it.)

 

We leave all as is. No mention of Today or Yesterday, Daily means what it says (a 24 hour period).

 

The reason for 23:59 is because WB resets Rain Today at 00:00. So, we ask Michel for a configuration value of what time of day the once daily calculations happen. This plus one more internal variable tracking Rain Today will allow the calculation to be done at the same time every day, whenever you want.

 

What do you think?

Agree! I just realized that (and discussed before, sorry Michel about the looping) Rain Today does not move so we better just stick with the plan.

[peterd]

mark -

Not enough time to continue re ET right now, but a quick story I think you'll like as we have the same vocabulary policy.

 

One day my daughter's Kindergarten teacher tells us that our daughter reported another girl had used "the F word." When the teacher asked (very wisely) "What word was that?"...

 

You guessed it!

[Michel Kohanim]

Mark/Peter,

 

Thank you. I guess I am at a loss because I live in apartment! I am not sure what the 00:00 has to do with anything. If we have yesterday's

 

1. Peter, thanks for the soil absorption factors

2. Renaming variables is OK as long as we stay consistent in the algorithm

 

Let's recap:

 

User configuration

1. Depth: amount of water applied per cycle

2. Region: Interior (1.7), Coastal (2.0)

3. Soil Absorption Factor: A value from 0% to 100%

Sand 100%

Loam sand 83%

Sandy loam 67%

Loam 58%

Clay loam 33%

Silty clay 25%

Clay 17%

 

ISY side

Today

1. Instantaneous ETo: Calculated at each WB polling

2. Today's Average ETo: Addition(Instantaneous ETo)/Number of times WB was polled thus far

3. Today's Average Water Deficit: Today's Average ETo - (Rain_Today * (Soil_Absorption_Factor / 100))

4. Today's Irrigation Requirement: Today's Average Water Deficit - Depth of applied water. This value is applied to Total Irrigation Requirement (see below) and then RESET to 0 at 00:00

 

Yesterday

1. Yesterday's Irrigation Requirement: At 00:00 Today's Irrigation Requirement is copied to this value. This value DOES NOT change. It can only be reset to 0

 

Total

1. Total Irrigation Requirement: At 00:00:

Total Irrigation Requirement = Total Irrigation Requirement + Today's Irrigation Requirement

Since Irrigation Requirement can be negative, thus, if enough water is applied, this value can potentially reach 0 or a negative number.

This value can be reset to 0

 

So, in essence, the users have three different variables to choose from when it comes to replenishing the water loss:

1. Today's Irrigation Requirement ... an average instantaneous value

2. Yesterday's Irrigation Requirement ... whatever happened yesterday (I do not think this is useful)

3. Total Irrigation Requirement

 

The only invariable element is Yesterday's Irrigation requirement which seems to be completely redundant (as both Peter/Mark suggested).

 

Thought?

 

With kind regards,

Michel

[Mark Sanctuary]

I am pondering this Michel and waiting for Peter to ponder and respond before I jump in and comment. Then I can also have his take on it to add to my understanding... I think this will help me from starting any more loops.

[peterd]

Mark/Peter,

 

Thank you. I guess I am at a loss because I live in apartment! I am not sure what the 00:00 has to do with anything. If we have yesterday's

 

1. Peter, thanks for the soil absorption factors

2. Renaming variables is OK as long as we stay consistent in the algorithm

 

Let's recap:

 

User configuration

1. Depth: amount of water applied per cycle

Yes, if this is what we've been calling "Water Applied per Irrigation" (a more descriptive name since most of the variables involve depths).

2. Region: Interior (1.7), Coastal (2.0)

3. Soil Absorption Factor: A value from 0% to 100%

Sand 100%

Loam sand 83%

Sandy loam 67%

Loam 58%

Clay loam 33%

Silty clay 25%

Clay 17%

Yes.

 

ISY side

[...]

Thought?

Michel -

I think we can simplify this greatly.

 

There are some mistaken assumptions about Irrigation Requirement which cascade into way more complexity in today vs. yesterday, etc. But rather than try to go point by point from your post I'd like to try another forward pass through it.

 

I won't be able to complete this (needs some thought to make the writing as straightforward as possible) for 6 - 8 more hours.

 

In the meantime, let me ask:

Do you have any problem adding one more config variable (a time of day) and making the time of calculation based off of this?

 

Thanks,

Peter

[peterd]

I am pondering this Michel and waiting for Peter to ponder and respond before I jump in and comment. Then I can also have his take on it to add to my understanding... I think this will help me from starting any more loops.

Mark -

 

When I sit down to write up more this evening I hope we'll wind up simplified yet more powerful...

 

Thanks for hanging in 'til then.

[Mark Sanctuary]

The Depth notation has me confused too. Is this part of the ET calculations and now your exposing it or is it water applied as Peter just mentioned?

[peterd]

Michel -

 

I've stepped back to try to see how we can simplify things, and how this can be explained by a former apartment dweller (boy I miss those days!) to a current one. Please bear with me if some of this is stating the obvious, because I think there are points here which are getting overlooked...

 

Let's start conceptually.

1. ET is just an approximation of the amount of water leaving the soil via a combination of evaporation and transpiration (a fancy word for plants drinking it up).

2. The goal of an ET-aware irrigation system is to approximately (despite all the appearance of precision, we have to remember this) replace this water.

3. It does this by tracking the water used/lost from the soil until a threshold is reached (where the plants would starve for water if much more left without replacement).

4. In most climates, this will result in watering every few days.

5. Rain may offset some of the water use/loss, resulting in less frequent watering.

6. Calculations performed once every 24 hours are sufficient for this tracking.

 

I'm again incorporating the diagram & table from earlier in the thread so we have them right here for reference. I would ask that you take just 5 minutes to absorb them before moving on. First the diagram:

The 3 key concepts here are:

1. There's some amount of allowed depletion (based on the plant types, root lengths, etc.).

2. This depletion will not typically happen in a single day.

3. What is varied is when to water, not how much.

 

Just thinking about this we can see why all of this is an attempt to approximate. As soon as I have more than one type of plant in my landscaping, I have different water depletion tolerances. We could envision a very sophisticated system with differing calculations for every plant in our garden, but the reality is that we'll come up with a compromise depletion depth which allows the majority of plants to thrive (and doesn't kill any).

 

Now for the table:

This shows how:

1. A running balance is used to decide when to irrigate.

2. It's not necessary to exactly replace all the water which has left the soil (i.e. zero-out the balance).

 

OK, at this point I have to take a break and eat some dinner. When I return I'll answer any questions up to this point, then go over what I hope can be a final cut at naming, describing & calculating values for the necessary variables.

 

Peter

[peterd]

[...] OK, at this point I have to take a break and eat some dinner. When I return [...]

Sorry, something's come up. Looks like I'll have to pick this up tomorrow.

 

Peter