Addition of irr_day decision table variable

[gisrichards]

Added the decision table variable "irr_day", which when used along with auto-irrigation will not allow irrigation events to occur within a user-specified number of days. The purpose of the addition of this variable is to help simulate limitations of certain irrigation types (center pivot, wheel line, furrow) which are often set to apply greater water depths at lower frequencies.

[tugraskan]

I think the use case here is valid, but this new irr_day condition looks very close to an existing mechanism: days_irr.

days_irr is the existing counter-based approach. It stores a single integer per HRU, increments it by 1 each day, and resets it to 1 when an irrigation event occurs. That condition is already exposed in the decision-table logic, so if you check something like days_irr > 5, the model should irrigate once the counter has climbed past 5, then reset it and start counting again.

• Field: pcom(j)%days_irr, declared in [plant_module.f90:113]
• Incremented daily at [hru_control.f90:222]
• Reset to 1 on irrigation events in [actions.f90:293][wallo_control.f90:102] and [mgt_sched.f90:356, 528, 569] (scheduled irrm + paddy)
• Exposed as the dtbl condition at [conditions.f90:244]

irr_day is the timestamp-based approach added in this PR. Instead of storing the number of days since irrigation, it stores the Julian day on which the last irrigation happened. Then when the condition is evaluated, it computes the elapsed time as time%day - last_irr_day, with a wraparound adjustment for year boundaries and a special sentinel rule for the never-irrigated case.

• Field: hru(j)%last_irr_day, declared in [hru_module.f90:270] this pr
• Written at [actions.f90:148, 277] (this PR's two add sites)
• Read by the dtbl condition irr_day at [conditions.f90:251-267] which evaluates time%day - last_irr_day with a year-wrap fix and a sentinel rule for the never-irrigated initial stat

So functionally, both approaches are representing the same concept:

days_irr asks: “what is the current counter value?”
irr_day asks: “what day was the last irrigation, and how far back was that?”
There may be some small edge-case differences between the two implementations, but it seems like they are solving the same problem. Because of that, I wonder if the simpler fix would be to extend the existing days_irr behavior here rather than introduce a parallel last_irr_day / irr_day path.

in the "unlim" block in actions.f90, could we just reset days_irr when irrigation is actually applied?

[actions.f90:140-165]
pcom(j)%days_irr = 1 ! reset days since last irrigation

That seems like it would address this issue while reusing the existing decision-table condition, instead of adding a second mechanism.

[gisrichards]

I agree that adding additional functionality to days_irr would be the best option. I initially tried to use that variable in a decision table but it wasn't working, which led me to creating the irr_day variable. If days_irr can be modified to work with all auto irrigation decision tables/water sources/irrigation systems then that would be simpler than adding an additional variable.

Also, I had Google's AI help me write the code and create this variable. I generally understand fortran and the file structure of SWAT, and have made small changes to SWAT2012 source code for my research over the past few years. This however was beyond my own coding abilities, however I think that having a decision table variable that controls days between auto-irrigations will be useful to SWAT users in irrigated regions.