Proposed Evapotranspiration Algorithm in 3.1.4 Beta

[peterd]

[...] we are at 0 no matter what, because the glass can't hold 110% [...]

Doh!

Sometimes we get so deep into things that the obvious escapes us (especially late at night)!

 

So while Daily_Water_Deficit can go negative, Irrigation_Requirement cannot go below zero. Makes sense. So we keep everything in one place, I'll update my earlier post to indicate this.

 

Peter

[Mark Sanctuary]

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

I just was thinking Peter shouldn't a Soil Absorption Factor be applied to any way water gets added to the soil?

 

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

[Mark Sanctuary]

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

I just was thinking Peter shouldn't a Soil Absorption Factor be applied to any way water gets added to the soil?

 

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

I have to think on this one more because Daily_Evapotranspiration is not adding water but Rain_Today is...

[peterd]

I have to think on this one more because Daily_Evapotranspiration is not adding water but Rain_Today is...

I think you just answered your own question. ET is water loss. Your original question:

[...] shouldn't a Soil Absorption Factor be applied to any way water gets added to the soil?

is valid, though. ISY applies it to rain because it's doing that calculation. We apply it (offline) to irrigation when we determine how long we water to achieve a certain replenishment amount.

 

So in your case, with 2 different soil types, you can determine different runtimes for the zones to take this into account. Then, what I'd do if I were you is split the difference between soil types when inputting my Soil Absorption Factor. That way, in the absence of any rain you'll be watering just the right amount for each soil. If there is some rain you'll have a reasonable approximation of what it has replenished, and your own program will still be applying irrigation to the different zones in proportion to their soil type.

 

Peter

[peterd]

Private guinea pig reporting for duty...

Welcome aboard, Mike! Based on what I saw of your analysis of the scope traces with the CFLs & Insteon dimmers I'd say you deserve a higher rank than Private. Since this is all water related, I guess we should be looking at naval ranks. What's equivalent - Ensign?

 

Peter

[Mark Sanctuary]

So in your case, with 2 different soil types, you can determine different runtimes for the zones to take this into account. Then, what I'd do if I were you is split the difference between soil types when inputting my Soil Absorption Factor. That way, in the absence of any rain you'll be watering just the right amount for each soil. If there is some rain you'll have a reasonable approximation of what it has replenished, and your own program will still be applying irrigation to the different zones in proportion to their soil type.

I am also hoping that since I am changing all my drips in the backyard to 1 GPH from 1/2 GPH I may be able to have the same run time in the front and back. Testing will help me understand if this works or not. I started the replacement of the dippers this week and each night I would say I have done about 1/16 of that project completed. This morning after the system ran I noticed were the drippers that I have been replaced, there was a larger water pattern than the lower rate drippers water pattern so I am excited this change is going to help my issues.

[Mark Sanctuary]

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.)

What about instead of zeroing it out... expose the WeatherBug variable to us in the variables tab?

 

We could do this below if we applied 0.5 of irrigation.

 

Then
       $Irrigation_Requirement -= 0.5

Or a callback to update it.

 

Then
       Module 'Climate' Irrigation_Requirement -= 0.50

[peterd]

What about [...] expose the [irrigation_Requirement] variable to us in the variables tab?

Hey, I'd love to go for that implementation right away, but we'll need floating point math on it. If UDI can enable math on a single floating point variable w/o having their entire floating point variable support ready to go, then YES, YES, YES! On the other hand, if this would mean skipping one or more betas (and assuming that a zero-ing out implementation wouldn't) then I, personally, would vote for the "close enough" re-init approach.

 

I specifically haven't mentioned this before because I wanted to help get in place something that would be as useful to as many people as soon as possible, but... Due to major home renovations I've had to re-do my entire irrigation system. I've had 2 temporary setups up till now. I have nothing running right now. I'd really rather get an ET-based setup going than have to yet again do something temporary. But, hey, that's just me...

 

Peter

[Mark Sanctuary]

The function of the design is the function of the design. I think we should just design it as it should work and let Michel and team figure out the way to implement it. A callback would easily get around the variable floating point not being created in the variable part of the programs module.

 

Here is an example the climate module already is using variables that are float.

If
       Module 'Climate' Evapotranspiration > 0.20

So in a callback it could be defined to be float without messing with the variable programs module that is not float.

Then
       Module 'Climate' Irrigation_Requirement -= 0.50

[peterd]

Mark -

 

First, let me see if I understand what you mean by "callback" (because I didn't think the ISY supported them). As I understand the term, support for callbacks would allow me to write a piece of code completely external to the ISY programming environment (for instance a 'C' function or a Java method). Then, I could specify this piece of code to be executed at some point within an ISY program. The ISY program would call my code, which presumably would be passed pointers or references to ISY variable(s) on which it could act. After this code completed the ISY program would continue executing at the next statement, unaware that something "external" to it had changed anything.

 

In that case, yes - I see how we could write that code today, in a way which would support the floating point math, outside the ISY Admin UI environment. If I've overlooked the ISY's support for this extremely powerful capability, then I stand corrected. If that's not what you meant then please help me understand what you have in mind.

 

I do understand your point about purity of design. I think there may be a difference in our perspectives (neither being right/wrong or better/worse) about how far to take the design. Assuming that what we have now is a version 0.1 beta implementation, I'm just trying to design a version 1.0 (ok, maybe 0.9 - it is still beta after all ) which can go to beta soon, be in people's hands to gain experience and does not lock out a future implementation.

 

Maybe I'm anticipating a non-issue, but (even 'though it may initially seem straightforward to implement) my concern is that UDI wouldn't want to "back into" floating point variables by introducing limited support in one specific place. For instance, this implies that floating point values would be available in the program editor pulldown for that variable (and that variable only). What's the precision? (We currently have instantaneous ET to 4 decimal places...) We've been using .5 as an example, but what if I want 0.273; 1.005; 2.8241? Think of how many values that pulldown would have. So, should it be 2 lists (left & right of the decimal point)? More? (I understand why UDI has created the program editor as their IDE for ISY, but for those of us unafraid to open source code in a text editor it would sure make things like this easier...)

 

That said, I'm happy to ask Michel which way he can do this now (as a variable which can be the target of an assignment involving floating point arithmetic or one which can only be read and reset to zero).

 

We do both agree that the ultimate design (whether in the next release or down the road) is to have the Irrigation_Requirement be able to be incremented or decremented (by floating point values) within user programs.

 

Peter

[Michel Kohanim]

Hi Guys,

 

Thanks so very much for excellent discussions.

 

First of all, if we were to introduce Module Variables that are assignable (regardless of floating point vs. decimal), then we would be sitting here waiting for implementation for 6 months or more as this feature is not currently part of our code base.

 

The best approach is this:

A. User side

1. User soil type

2. User defines land location

3. User defines offset values that have to be incremented/decremented from Irrigation_Requirement

 

B. ISY side

1. ISY calculates instantaneous ET ... this we already have

2. ISY calculates today's average ET thus far ... this will be stored in Today's ETo

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

6. I am not sure what Irrigation_Requirement should be but it can be decremented automatically based on User input A3

 

With kind regards,

Michel

[peterd]

Michel -

 

Thanks!

 

A. User side

1. User soil type

2. User defines land location

3. User defines offset values that have to be incremented/decremented from Irrigation_Requirement

 

By user side, I think you mean that these are Climate Module configuration values input by the user - correct?

 

1. For soil type I think we envision just a soil absorption % the user can enter so that situations such as multiple soil types can be approximated by the user. The other reason to have this be a value rather than a pick-list is that there's a technique for measuring the rate at which soil absorbs water which will give a more precise idea than the approximation of soil type.

2. ok.

3. Defining the decrement for Irrigation_Requirement as a config value is fine, but recognize that there still would need to be a way to trigger this programmatically. The decrement only happens after you've successfully irrigated.

 

Ideally:

- This value would appear in the configuration as Water Applied per Irrigation and is in depth (mm/in) units (as are all the values we're discussing - except the soil absorption %).

- In the user's program the IF condition would be able to be written as Irrigation Requirement >= Water Applied per Irrigation

- The final THEN action (after the irrigation zones all run) would trigger ISY to decrement Irrigation Requirement by Water Applied per Irrigation

 

B. ISY side

1. ISY calculates instantaneous ET ... this we already have

2. ISY calculates today's average ET thus far ... this will be stored in Today's ETo

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

6. I am not sure what Irrigation_Requirement should be but it can be decremented automatically based on User input A3

1 - 5 look fine, although I'm not sure what value there is to Today's ET being a constantly changing average (couldn't it just be calculated once @ end of day). Personally, i think that the instantaeous ET and Today's ET should only be used internally (not visible to the user), as these don't have any direct utility and will probably be a source of confusion.

6. after step 5, then set Irrigation_Requirement = Irrigation_Requirement + Daily_Water_Deficit

This is the depth of water the irrigation system needs to supply to replenish loss. It is a running total of Daily_Water_Deficit. Once the user irrigates, their program says "it's time to decrement Irrigation_Requirement by Water_Applied_per_Irrigation." Note that Daily_Water_Deficit could be negative (a surplus of water today), but there can never be a negative Irrigation_Requirement (which would mean literally "the irrigation system must remove water from the soil"). So the most decrementing by Water_Applied_per_Irrigation can do is take this value to zero.

 

Hope this helps.

 

Peter

 

edited 06/09 07:45 to further explain the benefits of "Soil Absorption Factor" entry vs "Soil Type" choice selection

[Mark Sanctuary]

We do both agree that the ultimate design (whether in the next release or down the road) is to have the Irrigation_Requirement be able to be incremented or decremented (by floating point values) within user programs.

Same target, we will get there!

 

Sorry I am using the wrong term, I took the C structured programming class in collage back in the late 1990s, its been a while, and may have my terms confused because of all the other programmers I work with. At work we refer to a "simple command that gives a var back to other modules" and a "whole procedure that does something and is launched by other modules" both a callback. I think this may be just a module command I am talking about below that can be accessed from ISY programs.

 

Then
       Module 'Climate' Irrigation_Requirement -= 0.50

First of all, if we were to introduce Module Variables that are assignable (regardless of floating point vs. decimal), then we would be sitting here waiting for implementation for 6 months or more as this feature is not currently part of our code base.

Yeah Michel I started to realize that exposing the variable was not the way to go so I started offering what I though was doable like this ISY programs command above.

[Mark Sanctuary]

A. User side

1. User soil type

2. User defines land location

3. User defines offset values that have to be incremented/decremented from Irrigation_Requirement

1. yes, don't forget to add concrete.

2. yes, were you already calculating this by geo location? If so the geo location might be accurate enough.

3. yes, are you saying a gui widget is easier for you than a ISY program command? If so what is the plan to allow us to trigger it from ISY programs, a ISY program command?

 

B. ISY side

1. ISY calculates instantaneous ET ... this we already have

2. ISY calculates today's average ET thus far ... this will be stored in Today's ETo

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

6. I am not sure what Irrigation_Requirement should be but it can be decremented automatically based on User input A3

1. yes, love this and all the hard work you did on it already, Thank you!

2. yes, today's ETo can be used at the end of the day 11:59pm

3. yes, perfect this will enable running after 12:00:01am giving another start time option.

4. yes

5. yes

6. yes, Irrigation_Requirement = Irrigation_Requirement + Daily_Water_Deficit -- this is what we will trigger watering runs from, and needs decrementing by A3 var when the run is complete.

[Mark Sanctuary]

2. Not sure what you mean by land location - GPS coordinates? If it's slope, etc. then I think this has to be handled completely outside of ISY for now since it likely wouldn't be a single global value (could vary by irrigation zone). Remember that the user still has to do some one-time calculations & make some decisions to decide how long each irrigation zone runs based on plant type, soil, slope, etc.

This is part of the ET calculations and Michel is talking about exposing it to the user in a GUI widget instead of doing it internally as it is currently being done. I think its Coastal, In land, Mountain, etc.

 

    * 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);

[peterd]

Mark -

 

Re land location. Got it. Thanks. Post edited.

 

Peter

[Michel Kohanim]

Hi Mark/Peter,

Thanks!

 

Mark, what is A3 variable. I understand that the Irrigation requirement gets decremented after each run by some floating number that the user defines, correct?

 

1. Is this value always constant?

2. So, we need to be able to let the module know that a run has been performed

3. Do we allow for negative numbers?

 

With kind regards,

Michel

[Mark Sanctuary]

Mark, what is A3 variable. I understand that the Irrigation requirement gets decremented after each run by some floating number that the user defines, correct?

 

1. Is this value always constant?

2. So, we need to be able to let the module know that a run has been performed

3. Do we allow for negative numbers?

1. No it should be adjustable based on how much the user sets the station run time in the wait command in their irrigation program. On a drip station that has 1 GPH drippers the user might set the runtime for 66 minutes which would subtract about 0.7 to the water Irrigation_Requirement. But this variable may need adjustment in areas that are dryer desert like places with more heat which might need run for 83 minutes to subtract 1.0 of water to the Irrigation_Requirement. I used this calculator for these examples.

 

2. Correct, this triggers the subtraction on the Irrigation_Requirement.

 

3. No negative number. Its the glass can't hold 110% thing I mentioned several posts back.

[peterd]

[...] what is A3 variable. I understand that the Irrigation requirement gets decremented after each run by some floating number that the user defines, correct?

Correct. That user-defined value is what Mark was referring to. I suggest it be called Water Applied per Irrigation.

 

1. Is this value always constant?

Yes - in the sense that to change it the user has to go into configuration and update it.

2. So, we need to be able to let the module know that a run has been performed

Yes

3. Do we allow for negative numbers?

No. That would amount to the irrigation system removing water from the soil.

 

It would also be great if the user's program could use Water Applied per Irrigation to compare against ("IF Irrigation Requirement >= Water Applied per Irrigation THEN ..."). That would prevent having the same value have to be specified in configuration and also hard-coded in the irrigation program (and potentially get out of sync).

 

Peter

[Mark Sanctuary]

1. Is this value always constant?

Yes - in the sense that to change it the user has to go into configuration and update it.

Why would you say yes?

 

A constant is something that is defined and never changed... "hardcoded". This is not constant because the user may want to adjust it based on runtime length.

[TJF1960]

On a drip station that has 1 GPH drippers the user might set the runtime for 66 minutes which would subtract about 0.7 to the water Irrigation_Requirement.

 

Not to interupt the "flow" ( ) and it may not matter right at the moment but as I recall the ezflora's max runtime is 30 minutes per zone then it shuts off.

 

By the way you two are doing an excellent job. Thank You!

 

Tim

[Mark Sanctuary]

Not to interupt the "flow" ( ) and it may not matter right at the moment but as I recall the ezflora's max runtime is 30 minutes per zone then it shuts off.

The timeout is adjustable, discussed here, I think (hope) my runs have been going for 90 minutes. I have to look when I get home.

[LeeG]

Factory default max Zone run time is 30 minutes. The ISY Admin Console supports setting the max Zone run time to the device limit of 255 minutes per Zone. Each Zone has its own max value.

 

Lee

[TJF1960]

That’s right, it has been so long I had completely forgotten about that option!

Forgive the intrusion.

 

Thanks,

Tim

[peterd]

1. Is this value always constant?

Yes - in the sense that to change it the user has to go into configuration and update it.

Why would you say yes?

 

A constant is something that is defined and never changed... "hardcoded". This is not constant because the user may want to adjust it based on runtime length.

Mark -

 

He didn't ask if the implementation was as a constant (e.g. that it's permanently compiled into code), he asked if the value is constant.

 

When Michel said

I understand that the Irrigation requirement gets decremented after each run by some floating number that the user defines[...]

 

1. Is this value always constant?

he clearly understood that if the user defines it (in the config page, which can be revisited...) it's not a constant in the literal sense. I believe he meant "Does anything change this at runtime?" Perhaps if he'd asked "Other than the user setting a value in the Climate Module configuration, is this value read-only?"

 

Cheers,

Peter