ESCOMP / ESCOMP/CTSM

Make logic in CropIncrementYear more robust

Open
#208 5 comments 0 reactions 1 assignee Assigned to @samsrabin View on GitHub
enhancement
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.