peterd

Tim -Don't feel bad - so much has evolved. Your original view of things was correct... halfway back in the thread. I had to stop & think a moment before my reply. Peter

Tim - What you're seeing is correct behavior. You should set Allowable Depletion to a value representing how much water your plants can tolerate leaving the soil. Then set up your program to run whenever Irrigation Requirement >= Allowable Depletion (you can't actually write the program this way - you have to copy the Allowable Depletion value into your program). Finally, using the Water Applied per cycle value which ISY calculated for you, you have to calculate how long to run your valves so that depth of water is applied (and put the appropriate WAIT statements in your program). One way of doing this (for sprinklers - not drip) is using a "catch can" test. Another is using a PC program which helps you do these calculations. (See my post early in the thread for a link to a website with info on both of these.) Cheers, Peter

I think for most people, this is going to be a last resort. If, for example, you had en extended outage (ISY down, broadband down, etc.) which meant that you could no longer count on the Irrigation Requirement value to accurately reflect the balance of water depletion from the soil then you might want to reset everything and make a clean start. That said, Mark did come up with at least one creative way to use this if for some reason you wanted to irrigate for 2 different durations (rather than my trying to explain it you could look back through the thread if interested in the specifics of his approach). Cheers, Peter

Hi all - As I've already told Michel, I've had an initial look at the irrigation module and am pleased with what I see. At the moment, we're in the midst of a major home renovation project - which as a side effect had our entire irrigation system apart until this week. As a matter of fact I was testing the irrigation valves just today. Things are very busy for me over the next week, but I hope to be able to sit down soon (may not be until week after next) and do my flow rate & runtime calculations for all 20 zones. Once that happens I'll be configuring the irrigation module and will report back via the forum. When I do, I'll try to walk through what I've done and learned which hopefully can be used to enhance the Wiki entry. Cheers, Peter

Michel - Cool! Peter

Michel - I agree that Allowable Depletion is not as intuitive as Water Applied per Irrigation. But I'm not suggesting we eliminate Water Applied per Irrigation, only "Actual Water Applied per Irrigation". I think "Actual Water Applied..." will confuse matters more (because it isn't describing the water applied - it's describing the effect of the water applied). Allowable Depletion (explained as "How much water will I allow to leave (be depleted from) the soil before I irrigate?") and Water Applied per Irrigation ("How much water must I apply - given my soil absorption - to make up for the Allowable Depletion?") complement each other conceptually. I think it's easier to understand the irrigation strategy if you're able to think of (even if we can't today actually write) the program condition as: IF Irrigation Requirement >= Allowable Depletion (because that is logically what the user will be writing when they select a constant equal to Allowable Depletion for this comparison). Unfortunately, ET is not simple. But I am certainly willing to try to come up with simple explanations like those above to help people start to use and learn about ET-based irrigation. And, if that simple explanation isn't enough to understand Allowable Depletion, at least by our using a standard term for it they should be able to read that PDF (or others) to help learn more. So to sum up, I propose that: 1. The user should enter "Allowable Depletion", and be shown "Water Applied per Irrigation Cycle" ((100/Soil_Absorption_Factor)*Allowable_Depletion). 2, When the "Irrigation Cycle Complete" action occurs, the ISY decrements the "Irrigation Requirement" balance by "Allowable Depletion". Example: - Target H2O in soil is 30mm. (Not entered/shown in ISY, this is a decision the user must make based on the types of plants they have.) - Soil type is Sandy Loam (83%). - Allowable Depletion entered as 15mm. - Water Applied per Irrigation Cycle calculates to (and displays) 18.0725mm - IF Irrigation Requirement >= 15mm THEN irrigate (apply 18.0725mm so 15mm will be absorbed) - Irrigation Cycle Complete: Irrigation Requirement = Irrigation Requirement - Allowable Depletion (15mm is the loss we made up for when we added 18.0725mm). Thanks, Peter

Mark - Sorry. My frustrations with many things got the better of me there. I know everyone's been making their best efforts (myself included) to learn about this stuff. Back to the point of the discussion, I think a 1st release would have been better with the ISY performing the absolute minimum of calculations, but it looks like we'll have soil absorption factored into our irrigation for us. I think that complicates matters, but if we're headed down that path I hope we'll at least have the appropriate configuration variables to work with... Cheers, Peter

Mark - I understand. My point is that if we're going to enter one value & see another derived value, the value we need to be able to enter directly is Allowed Deficit ("Actual Water Applied per Irrigation Cycle"). Working backwards from how much water the soil can hold and how much we need to replace, we wind up with the number representing Allowed Deficit (i.e. 50% loss of 30mm total = 15mm). We were thinking of that number as "Water Applied per Irrigation Cycle" which is no longer correct if ISY is doing the Soil Absorption math on our irrigation. The user now needs to calculate out that ISY calculation in order to determine when they've applied enough water. In that example it's not helpful that ISY shows 12.45mm when they enter 15mm, because they need to figure out what to enter so that that "Actual" field displays the Water Deficit of 15mm (18.0725mm Water Applied per Irrigation Cycle = 15mm Water Deficit). I tried to explain that there were implications to changing the algorithms I proposed, but wasn't successful. This is one of those implications. I also really wish everyone involved had invested an hour to read over and understand at least the first couple of chapters of that PDF I linked to early in the thread because I feel we've spent far more time than that trying to explain/understand concepts, terminology and techniques which are well established among irrigation professionals who use ET. This is not to say that I'm not very grateful to Michel & co. for soliciting our input (and to you for your participation) and for implementing ET at all, just that I don't think we're quite there yet on this one point. Cheers, Peter

Michel - Thanks for the preview. It's exciting! One clarification (maybe for beta 3.1.5 ): - If you're going to apply the Soil Absorption Factor to irrigation water, then the label "Actual Water Applied per Irrigation Cycle" should be changed to "Allowable Depletion." - The user should enter "Allowable Depletion", and be shown "Water Applied per Irrigation Cycle" (So in the UI, the calculation (100/Soil_Absorption_Factor)*Allowable_Depletion would be performed). Here's why: "Allowable Depletion" is the proper term for the amount of water loss from the soil before irrigating. (We've been referring to "Water Applied per Irrigation Cycle" as though it is synonymous with "Allowable Depletion" (which it was until the Soil Absorption Factor started being applied).) Using the industry standard soil moisture balance method of irrigation management, the depth of plant roots is used to determine the ideal water depth. Some percentage of depletion (usually 50%) is allowed before watering to make up the difference. So, the Irrigation Requirement is tracked, and once the irrigation requirement reaches the allowed moisture depletion level it is time to irrigate. So, as a concrete example, if our ideal water depth is 30mm and we want to water when half of that has been depleted by evapotranspiration, our Allowable Depletion is 15mm. That is also the amount of water we want absorbed by the soil. So if our Soil Absorption Factor were 83%, we'd need to apply 18.0725mm to result in 15mm absorbed. But, our ISY program will read: IF Module 'Climate' Irrigation Requirement >= 15mm As you've shown it, the user will either have to calculate the inverse of 83% and apply that to 15mm to determine that (s)he must enter 18.0725mm or sit there trying values until they get 15mm for the Actual Water Applied per Irrigation Cycle (Allowable Depletion). And, when the "Irrigation Cycle Complete" action occurs, the ISY must decrement Irrigation Balance by Allowable Depletion (in this case 15mm) since that's what we've replaced with our irrigation cycle. Cheers, Peter

Works for me. Michel - Have you been following this part of the discussion? The proposal on the table is to rename "Soil Absorption Factor" as "Effective Rain Factor" and use it only in the rainfall side of the calculation. That way we make it clearer what we are calculating, and leave as many options as possible for enhancement going forward... Peter

Mark - The issue is not that irrigation water is absorbed differently. It's what we're measuring. I simplified out some of the explanation to help move things along, but there is a concept called "Effective Rain." That's what we're calculating when we factor soil absorption into rainfall. On the other hand, we haven't been dealing with "Effective" irrigation. Water Applied per Irrigation is not Water Absorbed per Irrigation. Hindsight being 20/20, if this variable had been named something like "Decrement from Irrigation Requirement Balance per Irrigation Run," perhaps it would have made the intent clearer. As for soil type being entered differently - because we're trying for a basic initial implementation we're specifying a single value to approximate Effective Rain. You yourself indicated that you have multiple soil types. When you must compromise (ISY's internal calculations), that's one thing. But why would you want this being calculated for you when you can do this yourself (as part of the initial calculation of run-times which you must do anyway) exactly as needed for your situation? Then there's the lack of clarity introduced by incorporating it into the behind the scenes calculations. If it were possible, the most logical, intuitive and understandable way to write the irrigation program would be: IF Irrigation Requirement >= Water Applied per Irrigation but that isn't possible. Therefore, we take one step away from the intuitive by having to specify the value of Water Applied per Irrigation in the program. Having this constant be different than the value of Water Applied per Irrigation just makes it even harder to understand... Peter

Maybe, but I think you're actually making my point for me. Until we have either a full-featured module or all the tools (e.g. floating point vars & calcs) to do this all in user code, why not keep things as simple as possible? I only included the soil factor because otherwise there'd be no way to take it into account for rainfall. OTOH, we can adjust the runtime - not to round off the Irrigation_Requirement check numbers, but to directly account for the soil absorption (and do that zone-by-zone). If the user figures out the effect of soil absorption on runtime (e.g. "running this zone for 14 minutes will result in 0.5 inch being absorbed") as part of their one-time setup calculations outside of the ISY, then the comparison on a day-to-day basis remains easy to understand ("When Irrigation Requirement >= Water Applied per Irrigation, then I apply Water Applied per Irrigation"). Peter

Happy to help. Michel - I assume you mean as Mark illustrated: Irrigation_Requirement = Irrigation_Requirement - (Water_Applied_per_Irrigation * (Soil_Absorption_Factor / 100)) That's fine, but the user's irrigation program has to take this into account: // Program 'Irrigate If Needed' // The IF condition decides whether to water by comparing the Irrigation Requirement balance to a constant // The user is responsible for setting this constant equal to Water_Applied_per_Irrigation * (Soil_Absorption_Factor / 100) // (and updating it if they change the value of Water Applied per Irrigation or Soil Absorption Factor in their configuration) So if my previous example, for a Water Applied per Irrigation depth of 1/2 inch had been: IF Time is 01:00:00AM AND Module 'Climate' Irrigation Requirement >= 0.5 THEN ... And I've got Loam sand (83% Absorption Factor), then my code will read: IF Time is 01:00:00AM AND Module 'Climate' Irrigation Requirement >= 0.415 THEN ... To me, that makes the user's code even more brittle (because now we're duplicating in code not just a value directly entered but one which is derived by a non-obvious internal calculation), and the whole concept much more difficult to understand/explain. Peter

Mike - Thanks! Michel, Mark & I have been working on the overall application of ET averages to automate irrigation. But, yours is exactly the kind of analysis to validate & debug the base calculation which we very much need. I'll be eager to see how your next round (with the other WB station) goes. The available stations seem to vary greatly in terms of what data is available and at what interval. I found that my local NOAA station only reported hourly & had no light %. One of my local WB stations reported all rain values as "N/A" (the ISY wasn't too happy with this) while another was down for an extended period. That last one is finally back up and all values seem to be available, and as instantaneous as I care to have (I can set a polling interval under 1 minute & see values changing). Fingers crossed that this station continues to be operational. While I have not done any rigorous observation or analysis, the current instantaneous ET calculations in the ISY appear to be higher than historical averages for my area at this time of year (by about double). Cheers, Peter

Michel - I understand your point, but I'm not sure about implementing it that way. 3 reasons: 1. I believe Water Deficit is a "pure" number not reflecting any human intervention. (That is, it should provide a number representing only the effects of weather and the plants themselves on the water content of the soil.) In other words, the Water Deficit is always the number before any irrigation happens, but the Irrigation Requirement balance reflects the effect of irrigation as soon as the user's program says "ok I've watered." My reasoning has to do with having this data available to programs in the future (once they could perform math on it). 2. I included soil absorption in the Water Deficit calculation as a way to approximate its effect on rainfall, because there would be no other way for users to factor it in. However, in the absence of either a fully-featured irrigation module or enough programming features (including floating point variables & math) to move those calculations into user code, a single number here may be a big compromise. In Mark's case, for example he has 2 different soil types. I am in the process of landscaping a newly constructed hillside which has drainage incorporated underneath to prevent erosion - it may have a very different absorption rate than the rest of my property. (I can measure this empirically once it's complete.) In cases like these, users would adjust zone timings accordingly, effectively incorporating multiple absorption rates into the irrigation schedule (over which - unlike rainfall - they have control). 3. I'm not sure what are all the implications of moving the Water Applied decrement from the programmatic trigger point, and of the completion of irrigation no longer having a direct and immediate effect on the Irrigation Requirement balance? What happens when the user resets the balance to zero? Does Water Deficit change (i.e. does Irrigation Cycles go from 1 to zero even though an Irrigation Cycle in fact happened)? All that having been said, I also understand the desire to simplify things even further for the user. However, at the moment I believe that (just as today) the user will have to figure out how much water to deliver to each zone in order to achieve the appropriate replenishment for different plant types (root depths & water uptake rates) and soil types. For someone with any degree of complexity in their landscaping (i.e. more than just a lawn), I'm not sure how to make this initial programming easier. On the other hand, I'm concerned that trying to eliminate something from the users' one-time zone calculations may help those with vary basic needs (for whom the zone timing may be much simpler to begin with) while hampering those with sophisticated setups (such as my 20 zones) - for whom this whole ET capability may have the most benefit. I know that's a lot to consider at a time when you'd probably prefer a yes/no answer. Let me put it this way: If we don't implement this now, users will factor it into their zone timings directly. Its presence might prevent users from doing what they need to on a zone-by-zone basis, but its absence should not. We could always add it later. Peter