recall_read: end_yr written through wrong index (recall(i), i=0) — recall data silently never applied

[tobiassiegfried]

Summary

In recall_read.f90, the recall object's end year is written through the wrong index variable, so end_yr is never set on the actual object. The year-window gates in command.f90 then never pass, and all recall hydrograph data is read but silently never applied — no crash, no warning.

Observed on release 62.0.0; still present on main at cb442f7:

swatplus/src/recall_read.f90

Line 224 in cb442f7

recall(i)%end_yr = iyr

The defect

        !! save end year of recall data
        recall(i)%end_yr = iyr        ! <-- i is a local counter, = 0 here

i is declared integer :: i = 0 and is not reassigned before this line in recall_read (irec); the subroutine's object index is irec. The end year is therefore written to recall(0) and every real object keeps end_yr = 0.

Effect

The daily application gates, e.g. command.f90:342:

if (time%yrc >= recall(irec)%start_yr .and. time%yrc <= recall(irec)%end_yr) then

are always false (end_yr = 0), so prescribed recall additions/abstractions have no effect on any object.

Reproduction

From our engine-qualification runs (production-scale project, 861 channels, daily recall tstep = 3):

• One recall object prescribing a constant flo = -1 m³/s on a channel → all channel outputs byte-identical to the no-recall baseline.
• With the one-line fix below, the source channel and all downstream channels drop by ~1.000 m³/s and the annual mass removed matches the prescription (31.54 vs 31.536 Mm³ over the test year), no negative flows, deterministic across repeated runs.
• Baseline safety: with no recall objects present, the fixed binary's channel outputs remain byte-identical to stock 62.0.0.

Fix

        recall(irec)%end_yr = iyr

Notes

• PR Fix end year assignment in recall data and add new header types #216 mentions an end-year fix in recall data in its title, but it was closed unmerged and its final diff no longer contained this change — main still carries the defect.
• There is a second, independent defect in the same routine (org-mineral dedup self-comparison at line 132) that additionally limits recall to a single active object once this one is fixed; filed separately.
• Context: found July 2026 during engine qualification for a SWAT+ application in the Chu River basin (Kyrgyzstan). We run 62.0.0 with the two one-line fixes applied in production. Happy to open a PR for both.

[tugraskan]

Thanks for the detailed write-ups on both #247 and #248! Yes, we're aware of these. Our dev branch has already moved back to the previous recall structure, which has neither the end_yr index bug nor the dedup self-comparison, so both are resolved there and won't carry into the next release.