`c_month()` tests the zeros it just created instead of its input, always returning all-zeros (SALCAnitrate_field.py:75-86)

[mklarmann]

Hi team — flagging what looks like a copy/paste slip in the tillage month-correction helper that disables the correction entirely.

In SALCAnitrate/SALCAnitrate_field.py, c_month(in_month):

74      # generate an array with zeros the length of the input
75      m_month = list(np.zeros(len(in_month)))
76      # for each month in the input list
77      for i in range(len(in_month)):
...
82          if m_month[i] == 1:
83              m_month[i] = 2
84          elif (m_month[i] == 12) or (m_month[i] == 13):
85              m_month[i] = 14
86      return m_month

m_month is initialized to all zeros (line 75) and the loop then tests m_month[i] (lines 82, 84) — i.e. the zeros it just created — rather than in_month[i]. The input is never copied into m_month, so m_month[i] is always 0, no branch ever fires, and the function returns the all-zeros array regardless of its argument.

Why it's a bug: the function's purpose is to remap event months (Dec/Jan → February of the current year, etc.) for the tillage N-mineralisation correction. Because it ignores its input, the entire tillage correction effectively receives zeros.

Fix — seed the working array from the input and test the input months:

m_month = list(in_month)
...
if m_month[i] == 1:
    m_month[i] = 2
elif m_month[i] in (12, 13):
    m_month[i] = 14

(or test in_month[i] directly). A small unit test asserting that a non-trivial month vector is transformed (rather than zeroed) would guard against regressions. Thanks!