At least for me, I just logically thought that the efficiency percentage would be applied against 100% of the base precipitation rate. What is interesting is that it’s only applied against 60% of the precipitation rate (the .6 part of the scheduling multiplier). Obviously, someone is way smarter than me when it comes to this!!!
@theflexdude, thanks for posting these calculations! This answered some of my questions from previous years!
I want to get this straight…using this formula above, if I lower my flex schedule to 5 minutes, that gives me a runtime adjustment of:
= 300 / 4217
So we plug that into the next equation
0.65993740219092331773 = 5 *(0.64 / 60) / (0.07114062129475930756 * 1.136)
And now we are getting to the crux of my issue…the screen shot below shows a 5 minute run for a flex zone (every zone attribute is equal). I think you will see 2 things. First, moisture from the manual run is recorded in 2 different ways. The sum total which is .05, I agree with this number. The second total is attributed to a manual run, at .08, I disagree with this number, but let’s ignore that, you’re telling me that it is appropriate to adjust the moisture balance in 2 different ways with all things being equal except for the triggering event?
This used to not work that way, sad panda.
@plainsane Applying 5 minutes to the formula with runtime coefficient gives
5 *(0.64 / 60) / (0.622935346861727 * 1.136) = 0.075 inches
without coefficient
5 *(0.64 / 60) / 1.136 = 0.0469 inches
In your case the moisture applied should have been 0.08. So looks like we have a defect where we incorrectly compute the total but the breakdown shows correct value. We will have that fixed today. Thanks for showing this to us!
The fix for irrigation totals has been released.
Thanx for the fix.
I meant if I adjusted my flex to run for five minutes. Like on this zone. A zone with all of the same attributes, just a 5 minute schedule.
So really, what I have learned is the pr and efficiency are superfluous to flex. You could actually do away with those without any impact to the system.
Why not just just compute water needed, which is .66 (notice no efficiency or pr there, just awc, root Depth and awd)
Divide that by my schedule run time which is 43 minutes to get a pr rate by the minute of 0.0153488372093023 The multiply it by 5 minutes, same answer, boom 0.075 inches, as you report.
Multiply it by 43 minutes, boom .66 inches.
So thanx for taking the time to humor me, the flex algorithm, I thought it to be something else.
We need a runtime as a base. A sane value corresponding to the settings. Without it we cannot determine the moisture/minute irrigation rate. Once you have the base duration, then it is trivial as it should be. That is what we use the PR for, which is essential to give an estimated duration.
Yea sorry if I wasn’t clear, that is what I finally understand, runtime is the base not pr, nor efficiency.
Yes, but in order to compute runtime you need PR and efficiency.
Well, your just computing an informed suggestion, you can’t even call it a base line. I can change the duration of the zone and the graph doesn’t change ever, at all, just the amount of water that actually goes on the yard.
I mean I kind of get it. You don’t expect ppl to change those settings, but it’s ultra confusing…
Edit:
Sorry, it’s not a suggestion, I understand that the runtime computed at schedule creation., I misspoke
Runtime is computed each time schedule is built so if you change your PR or RZD you will water for different amount of time next irrigation event. But the point is to have a computed value that is best for the settings based on zone data and then give user the power to modify duration specifically if needed. Because all systems are different. Duration can be modified without having to touch the actual duration at all, by properly configuring the zone. That’s the best way of doing it.
Yea, it’s like you want efficiency and pr to not exist at all and be prompted for it when creating the schedule.
If you create the schedule with bad values, you can’t really “adjust” that.
I’m pretty sure back in the day I could tweak those setting and watch the schedule adjust.
It will adjust in current system too. Just the future. Past data is persisted now. So you can not do past simulation as in V2
So if I double the PR of a zone, I will see that reflected on the next run?
The schedule duration should change.
