- This topic has 57 replies, 15 voices, and was last updated 4 years, 11 months ago by
.
-
Posts
-
The Zimmerman method is severely flawed, I believe, from the perspective of someone living in Canada’s only desert (yes, we do have one).
But really anywhere that sees cold nights and hot days is going to have a problem. So is anyone living near (but not on) a lake.
I noticed my plants drying out. It was clear that they aren’t getting enough water. So I look at OS and see 3% as the watering amount. It was a bloody hot day today and my plants need water! 3%? Why? So I look up the algorithm and it becomes clear why.
Firstly, it vastly over-emphasises humidity. Reducing my water requirement by over 50% because of humidity is silly. Maybe in GA or the rainforest it makes sense… but the fact is, where I live anyway, weather stations are set up near the lake because they want to boast how awesome it is for tourism. Near the lake is going to have a lot higher than real humidity figures and that greatly skews things. But even still, humidity at a weather station isn’t water at my plants’ roots! It just isn’t the same thing. Yet the equation hammers my watering schedule due to humidity.
Next up… the use of “mean temperature”. That’s just silly when it comes to overnight lows. It registers that the average temperate is just 11.7 degrees Celsius (that’s only 53 in your funny scale) and that drops my watering another 40 some odd percent. But that implies it is cold here, and therefore I don’t need watering. Yeah right! It hit 33 degrees today (91.4F) and I’ll be damned if 3% is going to cut it!
My point? We need to be able to tweak beyond Zimmerman and manual. Manual, unless I’m missing something, is useless because it requires me to adjust the value myself every day.
I’d like to be able to go in and lower how much weight humidity has. I’d also like to restrict mean temperature to daylight hours (to me that just makes sense). Actually, taking the high makes more sense than mean. Being colder may limit the need for watering, but it doesn’t put water on the plants. Being hot takes water away. So far more weight needs to go with how hot it got vs. how cold it was, especially at night when it really doesn’t count worth beans.
So how about it? Can we expect to be able to tweak the formula as required? Maybe Mr. Zimmerman can enlighten us on why nighttime temperatures affect daytime watering needs 🙂
I understand your frustration but let me explain. Richard Zimmerman wrote this for his own firmware which did the calculation on the controller. This allowed the users to modify the code and upload the new code, which he encouraged tweaking.
Our weather adjustments run in the cloud and this is why it’s not user editable right now. This is being worked on and we do have plans to remedy this. We will take your suggestion regarding temp high though as a general fix.
Thank you
Ahh… so work in progress. Got it!
I think I might be able to contribute with a more comprehensive algorithm (do I get it named after myself? I’d be FAMOUS!). There’s merit, I believe, in looking forward as well as backwards. No point in watering right before (or during) rainfall just because it was hot and dry yesterday.
Curious: Is it done au-cloud because of computational limitations on-board? Can the MCU not handle, for example, Zimmerman’s calculations? Or is it for convenience and/or other reasons? Doesn’t really matter, I was just wondering if it would be easy enough for users to choose cloud vs. home-grown.
It’s done to allow customization without having to reflash the controller. That is the major reason we chose to continue with the cloud method. Furthermore, the firmware just knows the method you are selecting which is an integer and that gets sent to the weather service.
We are always trying to find the best way to add more features with the limited resources and by offloading some of the weather tasks we are able to continue adding other new features.
If you have a method/formula you would like us to incorporate we could gladly do that. In fact, as I said earlier, the setup was designed to allow exactly this, a quick addition. I would just update our weather service and the app making the method available to everyone.
Thank you
Right on. I’m going on a mini-vacation but I’ll get to work on something soon.
+1 from Belgium.
Humidity doesn’t look relevant to me. Only max temperature and amount of rainfall in previous days (maybe more than 1 day in the past because a couple of days ago it rained 30l and there is currently no need to water 100% even if it did not rain yesterday) + expected rainfall in near future are relevant for me.
in Belgium is a hot day around 20 to 25 degree Celcius. If no rain was fallen in previous days, I schould have 100%, if temp is even more, 150% would be nice.
Currently the controller tells me 18% what is to low.
thanks.
I will help testing or so if needed. Developping would be possible, but I don’t know how to start with this because I have no experience in open source projects.
I don’t mind working on an algorithm when I get back, but feedback from different climate (such as yours) is going to be helpful/necessary for making it somewhat universal.
I think the Zimmerman method would be a good start if you could modify parameters for the influzence of humidity, temp and rainfall.
Then you could modify the humidity influence by setting the parameter to 0% if you don’t want to use it.an extra parameter would be to use max or average temp per day.
having a possibility to take rainfall into account for more than 1 day in the past can be usefull.
+1 from Romania,
In the first week when I installed OS it didn’t water at all (based on logs) because high humidity (normal in that region) and few drops of rain (under 1mm 🙁 ) I had to disable Zimmerman in order to provide watering to my flowers or they were started to show effects of low watering. Since than I do the watering manual every day.
I just turned off the weather control now for now. and just going to let it go on a fixed schedule too.
Right now where i live (Silicon valley) its cold in the night but very hot in the day, and the zimmerman method basically turns off the water.
I am thinking that a simple modification might be to just use MAX temperature instead of mean temperature, and lower the effect of humidity.
Err… I think that’s what I said 🙂
OK, I’m back in town and I’ll have some time this week to put some thought into this. It would be nice to have some idea from the developers on what kind of computational possibilities we have. IE, can I interact with the WU api fully and use whatever data it can provide? Can there be any per-account adustments by the user? For example, let’s say I come up with the “Morehouse Method” (you know, to keep with the naming scheme) and provide you with the algorithm and the methods used in the WU api and what form data is required form the end user, can that get implemented? Or does it have to be a no-user-input equation and/or limited WU api data? I just want to know the parameters I can work with. Thanks.
Hi Steven, in regard to the Zimmerman method, I am going to expose the humidity weight, temp weight and precipition weight. This will allow users to use a different percentage modifier for each value.
These options will extend to other methods and be unique to each method. We plan on having this released for 2.1.5. It will work by detecting the selected method and showing the available options. The options will get stored as JSON and will be sent to the weather service when requesting the weather adjustment. This way things work as they do now with the benefit of adding per-user customization to the adjustments. Right now, we only have Zimmerman and I only plan on exposing three configuration options (temp, humidity and preciption). If you make your own method, just tell me which user configurable options you would like and we can go from there.
In regard to the Weather Underground data, you can get all data you would ever need to compute a scale. Just look thru the current variables that are parsed in the weather adjustment and if any additional ones are needed, we could grab them. Code available here: https://github.com/OpenSprinkler/Weather-Adjustment
I’ve been reading a lot on the theories regarding weather related to irrigation requirements. I’ve come to this conclusion: It is complicated 🙂
So complicated, in fact, that I’m not sure a meaningful equation can really be determined that will work for everyone, particularly since available data isn’t relevant or universal enough (ie. not everyone has rainfall data and those that do aren’t necessarily applicable to their actual property). Temperature is going to be the best indicator because even if a sensor at your local airport isn’t absolutely accurate to your property, it is likely to be relatively accurate to your property (ie. weather station reports X degrees while yours is really Y degrees but when theirs drops by 10% so does yours, etc). Rainfall, however, is highly localized so unless you’re collecting info at your property it isn’t likely to be relevant info. In fact, I feel the best two indicators are the temperature and amount of daylight, both of which are available without on-site sensors. Actual rainfall should be subtracted from actual irrigation (though not necessarily linearly) but only using on-site data.
I previously stated forecast data should be incorporated, but I’ve changed my mind on that – again due to quality of data. I did some observations locally over the past 7 days and 100% of the time Weather Underground predicted > 0mm precipitation there was none, and 100% of the time I actually had rainfall, it was not predicted in the previous day’s forecast. That makes for pretty useless irrigation adjustment. This is also why I suggest only using on-site data for actual rainfall because during the times it actually rained, the WU data said it didn’t and every time WU said it did… it didn’t. Zero % accuracy. Granted, that’s over a statistically insignificant data size of 7 days but it was enough for me to lose confidence in anything but actual on-site rain data.
Even with actual onsite rain data… to make a meaningful adjustment, we need to know not only how much hit the ground, but also how much our irrigation puts onto the ground! We can know that, but it takes a) measurement by the user and b) ability to input data into OS. I can, for example, know by my meter that my Zone 1 is putting out 10L/min to 100 square meters of lawn for 10 minutes (@ 100%) which means each square meter received 1L (assuming even distribution). If our rain sensor says we got 1mm of rain, then 1 square meter received 1L. In that perfect case, we know we need to run our irrigation for 0% since 100% was satisfied by rain. Was that enough water for our plants? Who knows, but it was the same amount it would have received via irrigation so if it is wrong, it would have been wrong anyway. If the rain gauge says 0.5mm then our irrigation should be reduced to 50%. But we can only know that by being able to input actual irrigation flow, time and land size irrigated.
Therefore, for rain data to mean anything, it should be locally gathered and we must be able to input our per-zone irrigation flow and area (time is known by the controller). Also per-zone enabling (to account for zones within a greenhouse) and/or weighting (for sub-surface drip) of rain adjustment should be available.
I said I would try to come up with something concrete, but at the same time I’ve learned this is going to be more difficult than I thought… a different project also fell into my lap. So I’m not going to come up with the “Morehouse Method” in the immediate future.
Earlier I suggested Humidity was over-emphasized. An obvious reason (that I didn’t think of initially) is that rain and humidity are related, so adjusting based on both double-hits the equation. Since rain = 100% humidity (by definition) one might suggest there’s only reason to account for one or the other but not both. It isn’t really that simple though. Humidity is important, because it directly influences evapotranspiration which, arguably, is the most complete analysis we can use to estimate watering adjustments… but it depends on where you are and what types of plants you’re irrigating. Ultimately, if you’re sticking with plants natural to your environment, then you don’t need irrigation at all (since those plants had millions of years to adapt to the level of natural moisture in the area). Since lawns don’t belong anywhere, and people like exotic plants, the affect of humidity on those plants is going to depend on how far out of “normal” they are. Like I said… complicated.
But maybe I’m over-thinking it. Consider how we use “dumb” controllers. We pick some amount of time to water – based on experience or just a guess – and we increase or decrease that depending on how the plants are doing. Once we have that more or less dialed in we know, by common sense and observation, that we have to increase that in the summer (or is that not universal?). Generally speaking, temperature increases in the summer so perhaps temperature is the primary factor we should consider, along with a linear adjustment for actual rainfall. But what temperature? Does nighttime temperature even matter? Maybe it does, I’m not sure (I kind of think it doesn’t). The amount of daylight also increases in the summer – the extent of which depends on how far you are from the equator. So maybe something like mean hourly daytime temperature times number of daylight hours to give some kind of “power” indication? Do solar radiation figures give us this? Unfortunately, solar data isn’t commonly available.
Further complicating things is type of irrigation. I’m fully sub-surface, for example, so I don’t believe wind has any effect on my watering needs while those with sprinklers shouldn’t be watering during windy times (unless they want to water the roads and neighbor’s houses). Drip irrigation for a garden in a greenhouse has vastly different adjustment requirements vs. sprinklers over turfgrass. Turfgrass heavily shaded by trees has considerable differences vs. full sun.
A lot of different consideration are in play. I’m not sure, at this point, that I can follow through with my hope to provide a new method that is meaningful to others. I’m going to try to work on one specific to my needs and, perhaps, it might be useful for others to adjust. I personally feel I want to focus on daytime hours, daytime temperatures, and actual rainfall past 24 hours… the latter requiring I buy more equipment.
Soil moisture sensors might be a way to go too. However, in reality you don’t want the root soil to be wet all the time so that’ll need some thought.
Sorry for adding more questions than answers.
Evapotranspiration(ET) is just about the only method of universally calculating watering needs. Penman-Monteith and Hargreaves are the 2 most widely accepted methods of calculating ET. There is a lot of math to calculate water lost by a plant, and it requires localized data, for the vast majority of the equation. In my experience using a site 30miles from me and my local (on my house) station yielded less than a 20% difference for the entire watering season last year. I live in CO along the front range of the Rockies (east side), and the weather here is crazy it can literally snow on one end of town and the other is 65F and sunny, so 20% seems as though it would be a good reference and a solid “universal method.” I have written the python part for the adjustment, now I need to work on how to increase the resolution of watering times on the sprinkler system, because you would essentially store a program with the number of seconds required to achieve 1mm of water coverage on your plant. Then you have to store a data set keeping the plant type (ie grass, shrubs/trees). These would then be multiplied by the calculated value, resulting in decent watering without much over/under-watering.
Forecast and actual precipitation was the hardest part to figure out, the way I did it was to assume the further out a prediction was the more incorrect it was by a factor of 2 (it is right or wrong, and each day has a greater chance to be wrong than right). It looks like this: predictedRainTotal * (1/day^2) * probabilityOfPrecipitation. Any rain forecast for the rest of the day is simply multiplied by it’s chance of rain. The Daily ET is then calculated and the 2 totals from above are subtracted. The program spit out will not water if it is currently raining, too windy, or too cold. It favors watering in the morning, to avoid mold and fungus growth in inherently damp localities, simply put it avoids putting the grass to sleep wet. The moisture in the morning cools the ground and reduces watering needs throughout the day. It will water in the afternoon on hot dry days if needed. For areas with watering restrictions you can set the time it starts the program and it will follow that.
All watering is calculated using yesterdays weather data, to allow for the greatest accuracy, and then adjusted using forecast data with less weight.
All watering methods are affected by wind, because high winds will pull moisture from the plant, watering during this time will cause the plant to literally “learn” not to conserve water. It will not close up and tighten cells near the surface of the leaf thereby releasing more water into the air. A tree that is overwatered during dry times will have a shallow root system under the same behavior. What subsurface watering does for you is conserve water through reduction of evaporation before it can be absorbed by the desired plant. While yes you don’t have to worry about the wind carrying the water away from the plant, you don’t want the plant to learn to sweat in the wind.
If you want to come up with an equation of your own the important factors to pay attention to are: Temperature(now and average daily), wind(now and average), Humidity(average), Sun Radiation reaching the ground at the site(this can be estimated pretty well), atmospheric pressure, actual and saturated vapor pressure(can be calculated well), and soil heat flux(pretty much needs to be calculated as measurement equipment is prohibitive). This will mean you can see how much water the plant has lost, then determine how much it needs.
Here is a link to the python script if you are better at working out how to get it to work with OS you are more than welcome to use it and call it your own. You will need python running locally to use it right out of the box. All the libraries used are included in the zip file, the file structure directly used by the script is setup though you may need to create a dummy file for the ET data and logs using todays epoch date(unix time/86400). You will need to edit the file to provide your own WU api key. Of course all these would exist on the OS and be transmitted to the remotely stored script during the getweather function, which would then return the info to the OS for use.
I have been fine tuning for almost 2 years in vastly different locations (AK, FL, CO, and South Korea), so hopefully it’s a good jump start to something useful. Currently I just run the script and use a cron job to edit the associated program on the OS.
An extra nice feature would be to define the minimum time a station should be active.
If a station has a runtime of 30 minutes and the weather adjusted % is 5%, then it is useless to water for 1,5 minutes.So if the weather adjusted time is less than the minimum time for a station, the station wont open.
The changes forseen by Samer in version 2.1.5 are a good start. Being able to choose between average or maximum temp/humidity would also be nice.
@Samer: any idea about a release date for 2.1.5?@Steven, you are realizing the same thing I am: sounds simple but a lot more complicated once you get into it. I think with many of us thinking about it and willing to try different solutions we should be able to solve this one.
@Shawn, I have actually already incorporated the majority of your algorithm into the weather service however it isn’t active yet as it doesn’t do any actual adjustments. The code got incorporated here: https://github.com/OpenSprinkler/Weather-Adjustments/blob/master/application.py#L59-129. Again, although the ET is being calculated, it is not being used for anything.@Wokkeltje no ETA is established yet for 2.1.5 however we did add the feature you mentioned about miniumum time into 2.1.4. The relevant code is available here: https://github.com/OpenSprinkler/OpenSprinklerGen2/commit/6e2d68a655295246aadbd984db34e66524c99e66.
I agree about your minimum, so long as it is (as you suggest) definable because I disagree that it is “useless to water for 1,5 minutes”. Some of my zones are set to about that under 100% conditions! Still, those then get cut down to something like 3 seconds and that really is useless (that hardly fills the lines).
Drip has vastly different requirements and weather adjustments than sprinklers. Indoor has vastly different requirements vs outdoor. The more fine-tuning we can do on an individual basis, the better.
I’m also going to suggest we be able to modify on a per-zone basis, again to differentiate between types of irrigation.
And I’ll reiterate that I believe for precipitation adjustment to make any sense whatsoever, the system needs to know how much water it is putting through the zone before it can adjust the effect of rainfall on that zone. 1mm rainfall completely negates irrigation in one scenario and barely scratches the surface of another. The same rainfall literally could make 100% difference for one (small water requirement drip zone) and 0% for another (indoor). ALthough, this is partially accounted for with weights (if, and only if, they are adjustable on a per-zone basis). But weights are going to be applied linearly while a true comparison requires a calculation that rectifies volume (x cubed) with area (x squared) since rainfall data is 2 dimensional (or assumed so because the presumption is the area covered envelopes the land in question) but we irrigate in 3 dimensions.
Re-reading what I just wrote, I’m not sure I’d understand the above paragraph if I weren’t in my own head. Sorry, I don’t really know how to explain it better. Maybe weights accounts for it better than I think… I’ll have to run some numbers. I’ll stop talking now 🙂
I did see that ET calculation added, I might have to talk to you about a couple of things needed to make it a useful weather adjustment, as i don’t think converting to scale is going to work in the long run. It really needs to be a multiplier, otherwise it will be capped in effectiveness. Minimums and maximums that are hard set will cause issue somewhere as well so this would need some user input given a good average baseline. I’m off topic a bit here so I created a topic in suggestions with what I think could help it become an effective method.
Rainfall and irrigation are both volume measurements, so the calculation can be flattened to depth as the area would be the same for both. If you get 1mm of rain it is 1mm deep regardless of the area measurement since your irrigation measurement will be effecting the same area presumably. If you have an indoor watering setup, simply multiplying the rainfall by zero would negate its effect and your irrigation system would be happy. So some sort of Boolean variable for indoor(0)/ outdoor(1) would suffice. Using the weighted averages equation seems the best suited as new data is much more important than old data, or current is more important than forecast. You would end up with something like the following as your final equation:
todayIrrigation – ((yesterdayRain*inOrOut)+yesterdayIrrigation+(todayFallenRain*inOrOut))*.9 + (todayForecastRain*inOrOut)*.1
Using this type of setup uses historical watering cycles to adjust the overall weight of the rainfall. If you have an outdoor zone that needs 1 inch of water based on yesterdays information, and it was watered .5 (50% yesterday) inches yesterday with no rain today, and .25 inches yesterday. The irrigation time would be adjusted by approximately 75%. Another zone using the same data but requiring 2 inches having been watered 1 (50% yesterday) inch, will adjust by about 37.5%. Meaning the same rainfall had half the effect which is correct as the zone is set to water twice as much. At this point all you have to figure out is how much water is needed so you would have the todayIrrigation value to start with.
Weighting and adjusting the data is pretty simple with little to no user input once you have a solid way to figure out your starting point.
Math in a single dimension is sufficient for most of the calculations, since all we are concerned with in the sprinkler world is water depth at a location.
When a sprinkler says it waters 1 inch per hour you can measure this with a pickle jar or a kid pool. Assuming fairly even distribution of the spray pattern, and total coverage of the areas in question, you would have 1 inch of water in both containers after 1 hour.
Using manufacturer and design information or simply measuring output in each zone means you can set all zone to apply the same amount of water then use a weighting method to adjust how much each zone actually gets.
If you know it takes 1 hour to get 1 inch of water, and a zone needs 2 inches, you set the time to 2 hours, or vice versa you know if it is set to 1 hour it will apply 1 inch. I guess what I’m getting at here is by including datalogs in your calculation you can easily adjust for rainfall, or oddball watering times (scheduled 3min ran for 30). As these would negate themselves in the next calculation.
Well no, rainfall is not reported (nor can it be) as a measure of volume. It is a depth – which is 2 dimensional. IF you’re presuming we’re talking about sprinklers, then yes you can measure how much simulated rainfall depth you receive and compare apples to apples… but that presumption is not valid. A more universal approach is measuring volume for the irrigation side and then comparing that to rainfall. It is also a lot easier and more accurate than putting a cup on the lawn (which isn’t possible if you’re sub-surface irrigating said lawn). That volume is given by your water meter – assuming one exists. THAT is volume… ie. 3 dimensions. Actually 4 (time) And it isn’t directly relate-able to rainfall in any meaningful manner without knowing the irrigated area, which is simple enough to estimate/measure, and time (controller knows this).
Simple weighting is linear, and I don’t think it is sufficient without a relationship between measure A (rainfall) and measure B (irrigation). Or tell me I’m wrong. Here’s an example: I run my lawn irrigation for 12 minutes. It rains for 3mm. How in the world do we make an adjustment based on that information?
We make the same point about indoor vs. outdoor… it is necessary to have a per-zone adjustment, which isn’t how it is currently (unless I’m missing something).
The indoor outdoor issue would require a per zone indication, which is not done now as far as I can tell, so on that we agree.
What I was getting at is the ability to flatten the math out to 1 common dimension, depth. Rainfall is most commonly measured by filling a cup of a known size(volume) and dumping it out when it fills, then counting the tips. This volume is then extrapolated as a depth covering an undefined area, though for their calculation they will know the area the rain is hitting. If we assume the area for the sprinkler and the area for the rain are the same, depth is our only concern for both and now we can compare them. I make this assumption knowing that rain will not hit every plant with exactly the same amount of water, and that a sprinkler will vary if the pressure goes up or down, but at the same time knowing I’m not building the next lunar lander and some error is acceptable.
Sprinkler manufacturers will typically provide you with how many gallons per minute or liters per minute a single nozzle or head will distribute. They will also give a coverage area in square feet or meters. Using those 2 things and assuming the head is provided sufficient water volume to operate at design specification, you can calculate coverage depth. This would only have to be done once. Now that you have calculated coverage depth, you can use the rain depth over the same coverage area as an apple to apple comparison. This is simply Volume divided by Area, leaving you with depth. Converting known volume and known area to inches per hour can be done using: Precipitation Rate = (96.26 x Total GPM)/Total Area. 96.26 = (60/7.48)*12. 60 = minutes per hour, 7.48 = gallons per cubic foot, and 12 is inches per foot. So my sprinkler head and rain measurement are now the same, a precipitation rate. We will know the time for our sprinkler and can get depth. We will know depth for our rain and can then subtract it directly as time from the irrigation time when they both hit the same area.
Next up is time to some unknown depth, we’ll pick 1mm over the coverage area. I can run and measure the water, or calculate it if I know or can measure the volume of water provided to that single head in a certain amount of time. So let’s pick 5minutes, I run the sprinkler for 5min or calculate the output for 5 min, and now I have mm/5min. Divide the mm by 5 and I have mm per min. Let’s say I got 0.5mm per min. Watering for 12 mins means I applied 6mm of water to my coverage area. It rains for 3mm, these 2 measurements are now simply depth over my coverage area (yes there will be error if the measurement for the rain comes from a different area, but typically these errors are low enough to negate or work with), I can simply subtract or add them to get differences or totals. So to answer your question using my sprinkler it would be 12min*(6mmPR/3mmPR) = 6min Needed with 3mm rain accounted for…
If you don’t want to make a few assumptions, measuring actual rain and actual irrigation rates to each plant becomes a cumbersome process that typically won’t vary data enough to make a difference in the long run, but for some math is fun so hey, to each their own I suppose.
So to wrap up that mess I think we are actually on the same page most of the way down:
1) We need comparable measurements for rain and irrigation, which is easy enough to do without adding special equipment or measuring every single time we water. Once we have a good and acceptable measurement we can use that, this will allow for some error that we will have to accept or calculate out.2) Using Depth over time, or Volume over time for both measurements is a must. The time will be assumed the same for both measurements when they need to be directly compared. This will have to be accounted for regarding saturation…min/max boundaries for rainfall should handle this well enough for sprinklers.
3) Linear adjustments will have error…When using a single dimension linear adjustment and some form of averaging will reduce error to an acceptable level for sprinklers. While yes I am a physicist, no I do not have the desire for, nor do I need a perfect calculation, just a really close approximation of perfect.
I might be skipping over some of the important parts here, so if you are still having trouble seeing how irrigation time and rain depth relate linearly or if none of this makes sense let me know.
EDIT: That last statement isn’t meant to be rude, just throwing out the idea that discussion brings better results…and re-reading your previous post I think we are saying the same thing, just I’m calculating volume (more time, less equipment), and you are measuring (with greater overall accuracy, faster startup, added equipment).
I think you’re just missing my point that not all irrigation is done via sprinkler and “depth” isn’t really relevant. I’m not concerned about error really… there is simply ALWAYS going to be variables that can’t be accurately accounted for (save for perhaps hydroponics labs). Sprinklers are both simpler (if you don’t care about error) and more difficult (if you do) but at least the relationship, whatever it is, is mono-dimensional and there’s a direct relationship between rain and irrigation since they both are applied the same way.
Drip isn’t.
Subsurface drip really isn’t.
And I maintain that for a relevant (not necessarily accurate) correlation, that dimensional divide must be addressed. Now, that can be done by the user and the math is just on them. But, I think it can (and should) be in the software to make changes in the math easier to deal with.
Let me try to construct an example (that is, unfortunately, going to mix metric and imperial because I’m Canadian and that’s what we have to deal with):
My backyard is roughly 1000 S.F. I have ROUGHLY 1000 emitters in a more-or-less grid at root depth below the lawn. Each emitter… assuming it is functioning correctly… puts out 0.4GPH. So… with no help from OS, I *could* calculate how many gallons per minute gets put onto (into) my yard (or read my meter that tells me it is 25L/min actual), divide that by the square footage and multiply that by the time the zone runs and come up with a depth. Now I’ve manually calculated a figure to directly compare to rainfall and we’re all roses, right? Sure… but now I decide that my lawn is over watered and I want to change that to 8 minutes. Hmm… now I have to recalculate the weight rainfall has because same rainfall is now a larger percentage of my irrigation. And I have to do that manually. Manually = yuck. Computers are particularly good at math, so if instead I could input the 1000 s.f. area and the 25 L/Min flow then the software – which already knows how much time the zone runs for – can dynamically calculate depth and compare that to rainfall. Less work for me = yum!
Even with sprinklers I think my method is better because it doesn’t require you to go out with a tuna tin and a ruler to figure anything out. Provided you have a meter to check (and if you don’t, you still have your tuna can and ruler) you *KNOW* the volume applied. Enter size of coverage for that zone (not head) and you’re back at my yummy world above.
If you don’t have a meter to know the flow, then it isn’t as convenient and – I concede – it would be better to tuna-can-measure depth and compare that directly to rainfall data.
- You must be logged in to reply to this topic.