Odd (blocky) spatial patterns in generic crop leafc for BGC simulation when initialized from BGC-Crop

[olyson]

Brief summary of bug

A user reports odd (blocky) spatial patterns in leafc for generic crop pft for an I2000CLM50BGC case.
This is a BGC case initialized from a BGC-Crop initial file.

General bug information

**Model version: cesm2.0.0 (release-clm5.0.01)

**Does this bug cause significantly incorrect results in the model's science? Yes

**Configurations affected: I2000CLM50BGC with out-of-the-box spunup initial conditions and accelerated spinup on

Details of bug

Here is the initial report from the user:
"So when I start a simulations from an finidat file from the inputdata repository there appear some strange lines in the leaf carbon for rain-fed crop at the first time step. Most of these lines disappear after a couple of years. However, some persist east of Europe and in Central Africa. I found out so far, that the lines are different, when I use a different finidat file, but there always seems to be some of them."

I've reproduced the user's case and gotten the same behavior. Some of the blocky patterns go away after several simulation years, but there are large areas of dead generic crop.

If I do a cold start I don't see this. I think this is happening because there are actually some valid values for C3 generic crop in the initial file (even though it is an initial file from a prognostic crop simulation), about 47 gridcells. It looks like these are being interpolated to the C3 crop pft based on the closest valid values, which is why things look blocky. One value is being interpolated to a bunch of gridcells. I can see this pattern in the interpolated initial file as well ("finidat_interp_dest"). I've tried setting all of the leafc for C3 crop in the initial file to zero and the pattern in the interpolated initial file goes away. I'm sure there are other variables that will look blocky though and that may cause a blocky pattern in leafc to reappear.

I've noticed that generic crops are not included in the code logic for reseeding (CNVegCarbonStateType.F90). When I change this to include reseeding the generic crops and run for several years, most of the crops are now alive. However, there are a few remaining areas of dead crop (China and South Africa). Presumably this is because the generic crop gridcells that are being interpolated from have no carbon/nitrogen and reseeding is not sufficient to allow growth. I will try to determine if that is actually the case. I'm also going to create a branch with the change to reseeding and issue a pull request for that change because I don't see why we wouldn't try to reseed generic crops.

The presence of generic crops in the BGC-CROP initial file is incorrect. However, if the initial file had no generic crop to interpolate from what would happen to a BGC simulation with only generic crops when interpolating from this file?

Important details of your setup / configuration so we can reproduce the bug

I've reproduced the bug with:

/glade/work/oleson/release-cesm2.0.0/cime/scripts/clm5.0_SeSCs_spinup_test_181121

The initial file in question is:

clmi.IGM2000GSWP3CLM50BGCCROPIRR.2011-01-01.1.9x2.5_gx1v6_gl5_simyr2000_c170419.nc

[billsacks]

There are a few important points in this issue, and I'll try to address each of them with some follow-up comments / questions:

(1) You mention the existence of generic crop in this run with prognostic crops enabled. I checked an out-of-the-box surface dataset (surfdata_1.9x2.5_78pfts_CMIP6_simyr1850_c170824.nc), and see that it, too, has a significant fraction of generic crop in many grid cells. Are you sure this is unexpected? If so, that deserves its own issue.

(2) Given that there is generic crop on the input finidat file, it sounds to me like the interpolation is operating as expected. Do you agree, or would you suggest a change in the logic of init_interp to treat this case differently?

(3) Connected with (2): Do you feel that reseeding fixes this case sufficiently, or do you feel other changes are needed at this point to address this issue? (It seems reasonable to me that a few years of spinup may be needed to remove these spatial artifacts, but the concerning point would be if there is a long-term issue that extends beyond that period.)

(4) In terms of what would happen if there were no generic crop on the input finidat file, but there is generic crop in the current simulation: This should be handled in the same way as the interpolation from a non-crop case to a crop case: Patch-level variables would be taken from the closest bare soil PFT (I realize this is non-ideal, but hopefully it would not have a long-term impact, since my understanding is that patch-level crop values go to 0 annually anyway; see #54 for some more discussion of this), and column-level values would be taken from the closest natural veg column.

[billsacks]

From @dlawrenncar - answers to the points above:

(1) Generic crop should be 0 on 78-pft datasets. @olyson is looking into why this isn't the case.

(2) We'd like to put in place a workaround for this issue, since these buggy initial conditions / surface datasets (with generic crop when there shouldn't be any) will be around for a while. One possible fix would be: If we can detect that we're interpolating from a case with prognostic crops to a case with generic crops, then ignore any pft15 on the input file (treating any pft15 values as if they were inactive - and similarly for the column-level values for generic crop). Then init_interp would fall back on finding the closest bare ground point for pft15 and its column. We could have a namelist flag to disable this, but we'd like this workaround to be enabled by default. (Another possibility is that we could put some global metadata on initial files moving forward, saying something like "allow input from pft15", so if that was on the initial file we'd use pft15.)

(3) We definitely want the reseeding fix. However, that alone doesn't solve the dead crop issue everywhere. Some further development of reseeding may be needed.

[olyson]

The raw dataset that is used in the creation of, for example, surfdata_1.9x2.5_78pfts_CMIP6_simyr1850_c170824.nc

has non-zero generic crop (PCT_CFT = 15) in a lot of areas. These generally correspond to areas with very small (but non-zero) PCT_CROP:

mksrf_landuse_histclm50_LUH2_1850.c170629.nc

So maybe these are "unassigned crops" or maybe there is something in the surface dataset code that is supposed to prevent generic crop that's not working. @lawrencepj1 do you have any ideas?

[lawrencepj1]

Hi Keith

I think the C3 Generic crops on the surface dataset are from the way mksrfdata_map interpolates each variable independently so the PCT_CFT 15 is regridded from 0.25 degrees to fv 1.9 using bilinear interpolation. The standard for the raw files was to put C3 Generic crops = 100.0 wherever PCT_CROP = 0.0. In this case there is a bleed in from the gridcells with PCT_CROP = 0 to the surrounding crops. I have talked to @ekluzek about this issue but don't have a solution for it. There may as you said also be an issue with small amounts of C3 Generic crops being where PCT_CROP is very small from the clm5 land use data tool. In those cases I thought the very small values should be removed by mksrfdata_map but we can look in to it further.

[ekluzek]

Dave, and Peter and I went over this a bit. It appears to NOT be in the rawdata, but in the surface datasets. So it will require changing the mask that's used for crop fields to be PCT_CROP instead of the land-mask. I think this should be fine to do. It might require generating a new mapping files. However, it was pointed out previously that we should be able to disconnect the mapping files from the masks. If that is the case, then I can do this without having to create new mapping files (currently there is a mapping file for each rawdata grid and land mask combination). If new mapping files are required it would require a new mapping file for each year we have PCT_CROP. So that would require a new way to go about handling the mapping files.

[olyson]

It seems to be in the raw data I'm looking at:

mksrf_landuse_histclm50_LUH2_1850.c170629.nc

I found 867 gridcells where generic pft is non-zero and pct_crop is non-zero. Unless there is another factor I'm not considering.

For the year 2000:

mksrf_landuse_histclm50_LUH2_2000.c170629.nc

I found 1233 gridcells.

In other news, success with growing generic crops by reseeding and changing the totvegc reseeding threshold to 10 (instead of zero). After talking with Dave, I'm going to see how a lower threshold works and we'll tentatively prepare this for the release branch.

[olyson]

A threshold of 1 works as well, so I'm going with that. I've created a branch and will issue a pull request:

https://github.com/olyson/ctsm/tree/reseed_generic_crop

[billsacks]

Update from today's CLM-science meeting: the reseeding fix is sufficient to fix this problem. So no changes in init_interp will be needed to work around this problem.

[ekluzek]

OK, I think this is fixed on the release branch and just needs to come to master.