ESCOMP / ESCOMP/CTSM

Add logic to reset flags for a crop column that just became inactive

Open
#209 6 comments 0 reactions 1 assignee Claimed by @samsrabin View on GitHub
bug
Dominant language
Fortran
Stars
352
Forks
361
Avg merge
2d 21h
Merged PRs (30d)
7

Description

_From @billsacks on November 3, 2017 20:37_

Currently, `croplive` is only updated for active crop columns (and this is probably true for other similar flags as well). I can envision how this might cause problems for crop columns that start out active, become inactive (due to their gridcell area going to 0), and then later become active again (due to their gridcell area becoming greater than 0). In this situation, `croplive` will start out as true when the column re-activates. I imagine that all sorts of oddities may result in this first year after re-activation.

There probably aren't many places where this happens in practice, so this may not be a big issue, but it's probably still worth fixing.

Some ways I can think of to fix this:

(1) Have some special logic in subgridWeightsMod: is_active_c (and/or is_active_p) that keeps a crop column/patch active for one time step after the time at which it first becomes inactive (i.e., if its weight was > 0 in the _last_ timestep). Crop columns / patches that are about to become inactive (i.e., would be inactive if it weren't for this special logic) would get a flag set (e.g., `crop_newly_inactive`). Then, in the crop phenology routine, any crop patch with `crop_newly_inactive` True (and `croplive` currently True) would go through the harvest logic, in order to set `croplive` to False, etc.

Notes about this:

- We need to keep the column active for this extra time step so that some other cleanup steps can happen. One example that I'm aware of is that we need the logic to reset GDDPLANT to accumResetValue to be triggered; with some changes I'm planning to make very soon, that would only happen properly if the patch were active.

- I'd like to have this new flag (`crop_newly_inactive`) rather than, e.g., checking (active and weight = 0). This is because I want to keep the capability to maintain crop columns as always-active, in which case they shouldn't go through this instant-harvest logic. Keeping the `crop_newly_inactive` logic in subgridWeightsMod makes it easier to change this to keep crop columns always active, if desired.

(2) Alternatively, we could do this via resetting the appropriate flags when a column/patch newly becomes active. For columns, we could potentially do this in dynInitColumnsMod, although (a) This isn't currently set up to reset flags for a newly-active column - though in principle it could be, and (b) We currently don't have analogous infrastructure for new patches.

In addition to setting `croplive` (and possibly other similar flags), we may want to have this reset anything – like the GDDPLANT accumulator – that would normally get reset when croplive is .false., etc. On the other hand, resetting all this extra stuff could be a maintenance problem, and it may be okay to just rely on the existing code to do this. (e.g., for GDDPLANT, it will get reset as long as croplive stays .false. for at least one time step... it may not be completely fool-proof to rely on this, but it may be good enough.)

_Copied from original issue: NCAR/CLM#12_

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.