How to manage crop areas in FATES-SP mode.

[rosiealice]

In FATES-SP mode, we currently do not consider crop areas in the assertion of LAI/SAI/HTOP etc. This means that in comparison with CLM5-SP runs, we under-predict the LAI where there are/should be crops.

My workaround for this so far has been to simply modify the surface dataset to add the crop area to the NAT_VEG area. I did this to facilitate direct comparison and identify biases between CLM5-SP and FATES-SP, but it's obviously the wrong approach in the long run.

I'm not sure how we should handle this as in general, though. FATES currently runs only on the NAT_VEG landunit/column. Solutions to this include

1. Run FATES (SP) on both the NAT_VEG and CROP land units.
2. Introduce some FATES-SP specific logic that expands the NATVEG area to include the crop area and PFTs and then just run FATES once.

I'm not really sure how exactly to implement the first, but it seems like potentially the more elegant thing to do. Does anyone have any thoughts/potential other solutions/pointer on how to active FATES on a crop column?

@dlawrenncar @danicalombardozzi @lawrencepj1 @wwieder @glemieux @ckoven @rgknox @aldivi @ekluzek @olyson ?

[rgknox]

In the long run, don't we also want the existing crop model to run simultaneously with fates, each on their own columns? Would this facilitate direct comparisons?

[rosiealice]

I guess you could have the CLM5 crop model running in native CLM5-SP mode in parallel? Right?

[rosiealice]

I also just realized that irrigation pertains to SP mode (whereas most of the crop model does not), so if we had SP-crops-in-FATES, they would need irrigating?

[rgknox]

I guess you could have the CLM5 crop model running in native CLM5-SP mode in parallel? Right?

That is what I was thinking

[wwieder]

I don't think the crop model runs in SP mode, because it needs N management and active BGC. For CLM5-SP I'm assuming we're using the generic crop, which I guess could still be irrigated? I'm fuzzy on the details here...

On Thu, Jul 1, 2021 at 8:08 AM Ryan Knox @.***> wrote:

I guess you could have the CLM5 crop model running in native CLM5-SP mode in parallel? Right?

That is what I was thinking

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/NGEET/fates/issues/760#issuecomment-872278851, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB5IWJAJUMFZLU7EMKFZK33TVRZFVANCNFSM47UT6E5Q .

[lawrencepj1]

Hi Rosie, Ryan and Will

Yes Will the SP crops can still be irrigated so they are on their own crop land unit / soil column.

best Peter -- Dr Peter Lawrence Terrestrial Science Section National Center for Atmospheric Research 1850 Table Mesa Drive Boulder Colorado 80305

Work: 1-303-497-1727 Cell: 1-303-956-6932

On Thu, Jul 1, 2021 at 8:14 AM will wieder @.***> wrote:

I don't think the crop model runs in SP mode, because it needs N management and active BGC. For CLM5-SP I'm assuming we're using the generic crop, which I guess could still be irrigated? I'm fuzzy on the details here...

On Thu, Jul 1, 2021 at 8:08 AM Ryan Knox @.***> wrote:

I guess you could have the CLM5 crop model running in native CLM5-SP mode in parallel? Right?

That is what I was thinking

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/NGEET/fates/issues/760#issuecomment-872278851, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AB5IWJAJUMFZLU7EMKFZK33TVRZFVANCNFSM47UT6E5Q

.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/NGEET/fates/issues/760#issuecomment-872283694, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC3OJOIK4YMTFCFH53X2HITTVRZ2XANCNFSM47UT6E5Q .

[rosiealice]

Righto. So the generic SP crop sits on its own land unit doing SP things and potentially being irrigated? Right?

[ckoven]

seems like your option (1) is the best plan, as it would be a first step towards a full FATES w/ crops implementation.

[lawrencepj1]

But in standard SP without irrigation the crop land unit is not generated.

! Crop settings and consistency checks

if (use_crop) then
   numpft      = mxpft   ! actual # of patches (without bare)
   numcft      =  64     ! actual # of crops
else
   numpft      = numveg  ! actual # of patches (without bare)
   numcft      =   2     ! actual # of crops
end if

! For arrays containing all Patches (natural veg & crop), determine

lower and upper bounds ! for (1) Patches on the natural vegetation landunit (includes bare ground, and includes ! crops if create_crop_landunit=false), and (2) CFTs on the crop landunit (no elements ! if create_crop_landunit=false)

if (create_crop_landunit) then
   natpft_size = (numpft + 1) - numcft    ! note that numpft doesn't

include bare ground -- thus we add 1 cft_size = numcft else natpft_size = numpft + 1 ! note that numpft doesn't include bare ground -- thus we add 1 cft_size = 0 end if

-- Dr Peter Lawrence Terrestrial Science Section National Center for Atmospheric Research 1850 Table Mesa Drive Boulder Colorado 80305

Work: 1-303-497-1727 Cell: 1-303-956-6932

On Thu, Jul 1, 2021 at 8:57 AM Charlie Koven @.***> wrote:

seems like your option (1) is the best plan, as it would be a first step towards a full FATES w/ crops implementation.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/NGEET/fates/issues/760#issuecomment-872316896, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC3OJOIF2KZ4Z5VEHV6DYMDTVR653ANCNFSM47UT6E5Q .

[danicalombardozzi]

Hi Everyone,

Happy to think about this more after the holiday. The crop model should probably be separate from the FATES model as the new code will have more sophisticated, crop-specific phenology and allocation. They should be run simultaneously though.

As Peter mentioned, there is an irrigated land fraction in both SP and BGC modes in CLM. To run without irrigation, the irrigation flag must be turned off.

Danica

On Thu, Jul 1, 2021 at 9:23 AM Peter Lawrence @.***> wrote:

But in standard SP without irrigation the crop land unit is not generated.

! Crop settings and consistency checks

if (use_crop) then numpft = mxpft ! actual # of patches (without bare) numcft = 64 ! actual # of crops else numpft = numveg ! actual # of patches (without bare) numcft = 2 ! actual # of crops end if

! For arrays containing all Patches (natural veg & crop), determine lower and upper bounds ! for (1) Patches on the natural vegetation landunit (includes bare ground, and includes ! crops if create_crop_landunit=false), and (2) CFTs on the crop landunit (no elements ! if create_crop_landunit=false)

if (create_crop_landunit) then natpft_size = (numpft + 1) - numcft ! note that numpft doesn't include bare ground -- thus we add 1 cft_size = numcft else natpft_size = numpft + 1 ! note that numpft doesn't include bare ground -- thus we add 1 cft_size = 0 end if

-- Dr Peter Lawrence Terrestrial Science Section National Center for Atmospheric Research 1850 Table Mesa Drive https://www.google.com/maps/search/1850+Table+Mesa+Drive+%0D%0D%0ABoulder+Colorado+80305?entry=gmail&source=g Boulder Colorado 80305 https://www.google.com/maps/search/1850+Table+Mesa+Drive+%0D%0D%0ABoulder+Colorado+80305?entry=gmail&source=g

Work: 1-303-497-1727 Cell: 1-303-956-6932

On Thu, Jul 1, 2021 at 8:57 AM Charlie Koven @.***> wrote:

seems like your option (1) is the best plan, as it would be a first step towards a full FATES w/ crops implementation.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/NGEET/fates/issues/760#issuecomment-872316896, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AC3OJOIF2KZ4Z5VEHV6DYMDTVR653ANCNFSM47UT6E5Q

.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/NGEET/fates/issues/760#issuecomment-872337951, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGHW2QOBTN2G2RGURURV3FLTVSB7TANCNFSM47UT6E5Q .

-- Dr. Danica Lombardozzi she/her/hers Terrestrial Sciences Section Climate and Global Dynamics National Center for Atmospheric Research Boulder, CO 80305

email: @.*** office: (303) 497-1777

[rosiealice]

Thanks all. That's interesting @lawrencepj1 that the crop land unit doesn't occur at all without irrigation. Which means either we a) keep make the NATVEG single instance of FATED to account of generic crops PFTs.

Doing only this would make FATES-SP incompatible with irrigation. To remedy that I suppose we could do either b) Run another instance of FATES-SP on the irrigated landunit Or c) Run the CLM5-SP crop model on the irrigated landunit.

I'm not sure which is harder out of b and c. I suspect b) might be more straightforward and give cleaner answers. (Noting that this is just for SP mode, wherein I don't think the crop-model specific terms have an impact, right?

Either way, making a) work is on the critical path I think...

[dlawrenncar]

Actually, I think @lawrencepj1 is wrong about the crop landunit. The new default is for the crop landunit to be created in all configurations unless you explicitly set it not to be (not even sure it is easy to not create the crop landunit anymore?). When in SP mode, only the generic crops and their CFT parameters are used. Irrigation is set by the surface dataset (i.e., non-zero weights in the irrigated PFT - I think PFT 17) and irrig = .true. on namelist. I think if irrig = .false., then even the irrigated CFT area is not irrigated.

So, I think there are really two use cases that we need to consider and they probably need to be considered separately. For SP mode, it seems like it is as simple as telling FATES to run for the crop landunit (irrigated and unirrigated), I think this is Rosie's option B and I think this is the one that would be preferred. As long as there are parameters for the crop CFTs, then I think this should be pretty straightforward.

For BGC mode, it's a significantly bigger topic since the crop model has its own phenology and allocation schemes. Maybe for now, in terms of this specific issue of crops in SP mode in FATES, we should defer that conversation.

I suggest that we have a quick discussion, and review of the code, about this at our next CTSM-software meeting. I think that would be the most efficient way forward on the critical path.

On Mon, Jul 5, 2021 at 7:12 AM Rosie Fisher @.***> wrote:

Thanks all. That's interesting @lawrencepj1 https://github.com/lawrencepj1 that the crop land unit doesn't occur at all without irrigation. Which means either we a) keep make the NATVEG single instance of FATED to account of generic crops PFTs.

Doing only this would make FATES-SP incompatible with irrigation. To remedy that I suppose we could do either b) Run another instance of FATES-SP on the irrigated landunit Or c) Run the CLM5-SP crop model on the irrigated landunit.

I'm not sure which is harder out of b and c. I suspect b) might be more straightforward and give cleaner answers. (Noting that this is just for SP mode, wherein I don't think the crop-model specific terms have an impact, right?

Either way, making a) work is on the critical path I think...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/NGEET/fates/issues/760#issuecomment-874103167, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFABYVFLZO4N7MFP4RLKFL3TWGVVPANCNFSM47UT6E5Q .

[ekluzek]

Note, the CTSM issue about using the CTSM crop landunit is here. This issue is different but related to this one here.

https://github.com/ESCOMP/CTSM/issues/1046

This would use the CTSM big-leaf code to runs crops, which could also be done for FATES-SP mode.

[billsacks]

Summary from ctsm-software discussion:

Can we have FATES handle crops in SP mode similarly to what's done in non-FATES – i.e., treating crops as grasses, but with a different subgrid structure – one crop per column? This way crops can use the same physics as natural veg in SP mode.

We may need to use Ryan's new column-level logical flag in more places.

Need to check some other subgrid setup (e.g., initSubgridMod, subgridMod) and set up of filters, as well as any new idiosyncracies that are coming in with the FATES-SP PR.

Need to double check that there are no assumptions in FATES that there is only one column that it's operating on, particularly in terms of subgrid weights.

[rosiealice]

Thanks @billsacks

On your first point, I think it broadly makes most sense to use the FATES physiology for crops in FATES-SP mode. Most of the crop model is downstream of GPP, as far as I remember, but is there anything special about what it does with Vcmax? (that is an input parameter in the default carbon-only FATES).

How does the sub grid structure work in CLM5-SP for crops? Is it -not- one column per crop type?

I agree it would be super useful to check on the sub-grid setup, filters etc. This is the part I am foggiest on wrt making this work. Thanks :)

[danicalombardozzi]

@rosiealice: I can answer part of this. In CLM-SP, crops are treated the same as grasses but with higher Vcmax values and also the option to irrigate for the irrigated fraction.

I believe the subgrid structure is still one column per crop type, but the SP configuration uses only 16 PFTs total, with PFTs 15 & 16 as crops: generic C3 rainfed and generic C3 irrigated. On the land use time series (or surface dataset if running a time slice), the generic crops are on the crop land unit, similar to the structure for BGC, while the rest of the PFTs are on the natural vegetation land unit.

[rosiealice]

Here is where we decide whether a column is handled by FATES, as I see it https://github.com/ESCOMP/CTSM/blob/01d4cf03eeac00b7d8b99c92cdb41064aeaf1a77/src/utils/clmfates_interfaceMod.F90#L539\

So we are choosing the columns with an 'istsoil' label. Do we think that adding the 'istcrop' labeled columns to this would get us to the point where FATES would at least try and run on the crop columns (@rgknox @billsacks?)

Notwithstanding that then I'd also have to sort out how to make the crop instances use the correct PFTs and areal fractions.

I'd test it to find out but Cheyenne is down this week...

[rgknox]

@rosiealice , I believe that gets us half way there The other part of it is to make sure that those crop columns are added to the ctsm-side filters and lists (but I'm guessing they already are added to the correct filters for the non-fates sp case?). There must be more to the ctsm side of things, my sense of the needs on that side are murkier. For instance, are there crop history diagnostics that are important to maintain?

Alternatively, we could push the crop fraction of the grid-cell onto the naturally vegetated portion of the gridcell, thereby increasing the weight of the natveg LU to be the sum of natveg+crop, then set the crop LU weight to 0, and make sure that the crop fates pft gets that fraction of the now shared column. This would seem to be the pretty simple to implement and would seem to just work without having to manipulate anything on the ctsm side, aside from those two weights. But we would lose out on any history diagnostics that we want maintained on the ctsm side.

[dlawrenncar]

For SP mode, I don't think there are any crop specific diagnostics. Pushing the crops onto the naturally vegetated landunit could work, but I think we would lose the crop specific treatment of irrigation, which is one of the main reasons to keep separate in SP mode. Plus, if what Rosie is proposing works, that would be a step towards implementation in full FATES mode. It's worth a test to see what happens.

Unless something different happens in FATES, you shouldn't have to do anything special to get the model to use the right PFTs and areal fractions with CTSM-FATES-SPCROP. But, maybe something different does happen in FATES.

On Tue, Jul 27, 2021 at 8:40 AM Ryan Knox @.***> wrote:

@rosiealice https://github.com/rosiealice , I believe that gets us half way there The other part of it is to make sure that those crop columns are added to the ctsm-side filters and lists (but I'm guessing they already are added to the correct filters for the non-fates sp case?). There must be more to the ctsm side of things, my sense of the needs on that side are murkier. For instance, are there crop history diagnostics that are important to maintain?

Alternatively, we could push the crop fraction of the grid-cell onto the naturally vegetated portion of the gridcell, thereby increasing the weight of the natveg LU to be the sum of natveg+crop, then set the crop LU weight to 0, and make sure that the crop fates pft gets that fraction of the now shared column. This would seem to be the pretty simple to implement and would seem to just work without having to manipulate anything on the ctsm side, aside from those two weights. But we would lose out on any history diagnostics that we want maintained on the ctsm side.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/NGEET/fates/issues/760#issuecomment-887570144, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFABYVEEP7YR554JNJTAKVTTZ3AM5ANCNFSM47UT6E5Q .

[billsacks]

@rosiealice - I agree with @rgknox that, to first order, the line you identified seems to be the key thing here. As we discussed a couple of weeks ago in the ctsm-software meeting, though, this is one of these changes where the hard part is thinking through / identifying where there might be implicit assumptions that are violated by this change. (See https://github.com/NGEET/fates/issues/760#issuecomment-876574239 for some initial thoughts on that.) This could be done via looking through relevant parts of the code (though off-hand I'm not sure I can identify what to check... figuring that out can be the hardest part), and/or through careful examination of many aspects of the model results to verify that things are working as they should. (I would normally be inclined towards the former, but I was impressed by your recent careful analysis of the causes of differences between FATES-SP and Big Leaf CTSM; a similar careful analysis of FATES's handling of crops could give us confidence that things are all working as intended.)

[rosiealice]

see https://github.com/NGEET/fates/pull/817

[adrifoster]

@rosiealice @ckoven for my SP calibration I am treating the crops as c3 grasses. Is this a sufficient solution?

[wwieder]

Suggestion is to run these as generic grasses in FATES-SP. This can be done on the parameter file. Would be resolved with https://github.com/NGEET/fates/pull/817/files