Make logic in CropIncrementYear more robust
- Dominant language
- Fortran
- Stars
- 352
- Forks
- 361
- Avg merge
- 2d 21h
- Merged PRs (30d)
- 7
Description
_From @billsacks on November 3, 2017 19:58_
CropType.F90: CropIncrementYear currently looks like this:
```fortran
call get_curr_date ( kyr, kmo, kda, mcsec)
! Update nyrs when it's the end of the year (unless it's the very start of the
! run). This assumes that, if this patch is active at the end of the year, then it was
! active for the whole year.
if ((kmo == 1 .and. kda == 1 .and. mcsec == 0) .and. .not. is_first_step()) then
do fp = 1, num_pcropp
p = filter_pcropp(fp)
this%nyrs_crop_active_patch(p) = this%nyrs_crop_active_patch(p) + 1
end do
end if
```
With some changes I'm planning to make to accumulator fields (so that they only get updated over active points), I think it becomes very important that nyrs_crop_active_patch only be incremented if the crop was active for the entire year. If a crop column was active for just part of a year (i.e., first became active mid-year), then the first year's GDD value would be misleading; this is particularly problematic because the first year's GDD value has a disproportionate contribution.
Currently, crop columns only become active at the start of the year, so this isn't a problem. But it would be good to make this logic more robust in case someone ever tries to make a crop column become active mid-year.
e.g., maybe we should track the number of time steps the given column has been active this year, and only increment the counter if it has been active for the complete number of time steps.
_Copied from original issue: NCAR/CLM#11_
Contributor guide
Assessment
This issue has not been assessed yet.