Get CROP to function separately from natural vegetation mode

[ekluzek]

Currently the modes for crop and natural vegetation are tied together (SP, BGC, CN, BGC-CROP, FATES etc.). You can ONLY turn CROP on if use_cn is being turned on. So you can't use it with SP or FATES -- at ALL. CROP is already on different land-units, but the switches are setup for the overall vegetation mode and not to separate out crop versus natural vegetation.

I think in order to do this, we'll need to allow the overall switches to be more flexible, but we'll also need something like a patch level filter that says: on_this_patch_you_run_CN, on_this_patch_you_run_FATES, on_this_patch_you_run_SP. I think we'll still want the ability to run the "normal" modes of SP (without crop), BGC-Crop, and FATES (without crop), so these would be new capability that could mix and match how natural vegetation is handled separately from crop.

At the CESM CTSM-FATES discussion we decided that having FATES model natural vegetation and BGC-Crop model crops, is a critical feature of our CTSM-FATES v1 model version.

[ekluzek]

@danicalombardozzi one fallout of doing this is that we could likely setup a SP-Crop mode where natural vegetation uses SP and Crop is modeled with BGC-Crop. Would that be something useful?

[billsacks]

I think in order to do this, we'll need to allow the overall switches to be more flexible, but we'll also need something like a patch level filter that says: on_this_patch_you_run_CN, on_this_patch_you_run_FATES, on_this_patch_you_run_SP. I think we'll still want the ability to run the "normal" modes of SP (without crop), BGC-Crop, and FATES (without crop), so these would be new capability that could mix and match how natural vegetation is handled separately from crop.

I started to try to write an argument against this, feeling like there must be a simpler solution. But then I started to see that something like this really might be needed.

But this leads me to wonder if the most straightforward solution may be to introduce a new landunit type for FATES. Conveniently, landunit 3 is currently unused: it was the old glacier-without-mec landunit, and this actually provides me with motivation for why this makes sense: We used to have separate landunits for glacier-without-mec and glacier-with-mec, because they were structurally so different. Similarly, FATES is structurally so different from the non-FATES soil landunit, and the set of code that operates on the two is so different, that I feel it would make sense to think about it as a different landunit. It could still be that, in a given simulation, we only have the non-fates or fates landunit present. But I think the logic would be more straightforward if we could just have checks of the landunit type rather than needing to check the landunit type and whether fates is operating.

So, @ekluzek , coming back to your original point: We would still need some new filters, but they could be based solely on landunit type. We'd need a filter over landunits 1 & 2 (the non-fates natural veg & crop landunits), and a different filter over landunits 1, 2 & 3 (all of the vegetated landunits).

Regarding mixing crop & SP: it feels like this would get messy in a transient case.

[billsacks]

Blocks #1047

[ekluzek]

@billsacks I like the idea of having FATES have it's own landunit type. I don't know why we didn't think of this sooner! Yes, FATES is so totally different than anything else it should be considered it's own landtype. That would. make it more possible to mix in some FATES landunits with other veg types anywhere. I suspect that kind of thing could be useful, even if we don't make it a standard thing. But, yeah we had two different types of glaciers and two different types of lake, so. there's no reason to NOT have two different types. of natural vegetation landunits.

[wwieder]

This separate land unit for FATES seems like a good one to me. It also seems absurd to try and run a FATES-SP with CROP transient compset, at least on the CTSM side. Maybe there's reasons to have this for FATES analyses, not sure what @rosiealice or @ckoven think about this?
What do we do now in SP runs in transient runs, do agricultural regions just get the generic crop (C3 grass) with SP.

[danicalombardozzi]

Separate land units will be useful for crops and could also help with scenarios like primary and secondary land. In regards to @wwieder's comment, is it absurd to run FATES-SP with CROP? We may find that @ekluzek's suggestion is useful for a scenario where someone is primarily interested in simulating agriculture, if the FATES-SP configuration is less computationally expensive than other configurations.

[rosiealice]

Hi @danicalombardozzi,

On this question, indeed, I do not think FATES-SP and crop would be absurd from a science perspective. As you say, that might well be a use-case people might desire. Aside from the landunit and use_cn switch issues we already identified, I can't see why it wouldn't be as feasible as running any other FATES configuration...

[ekluzek]

We talked about this in a FATES LULC call today. We both want the flexibility of CTSM to handle crop landunits separate from FATES. But, we also want to extend FATES so that it can handle crop landunits and pasture land as well. So the end solution should have the flexibility to allow FATES to handle crop landunits or CTSM to do so. This will need some namelist switches to control this behavior.

See this FATES issue that relates to this...

NGEET/fates#760

[rgknox]

I'm working through updating the interface with fates to accomodate nutrient dynamics between the two. I think it would be helpful if the patch and column soil filters were partitioned more. I see a possible breakdown like this:

https://docs.google.com/spreadsheets/d/1GHu8gEDWAjPJCI1Afyt2IQOaQujh-G9_p2HbMEFiBoU/edit?usp=sharing

Any thoughts on how to parse this more, better names, things I'm missing, (wrong direction?) are appreciated. Let me know if you want editing privileges

[billsacks]

@rgknox I can see how that makes sense. I'm happy with your suggestion if you feel it will make things cleaner.

[rgknox]

I'll hold on making any changes, and will check-in during the Thursday SE meeting to see where we are on it.

[chengyun19]

你好@danicalombardozzi,

在这个问题上，我确实不认为 FATES-SP 和 crop 从科学的角度来看是荒谬的。正如您所说，这很可能是人们可能想要的用例。除了我们已经确定的 landunit 和 use_cn 开关问题之外，我不明白为什么它不像运行任何其他 FATES 配置那样可行......

Hello,
I am a novice at running FATES. I find that the default SP model is false, I want to simulate GPP and NPP form 1970 to 2010. Do I need to turn on SP? And when should we turn on SP? I am not sure, can you help me? And in the I2000CLM50FATES compset, the CO2 is constant. Does this mean that I need to input the historical 1970-2010 CO2 data to get the 1970-2010 GPP and NPP?
Any suggestions will be appreciated! Thanks in advance.

[olyson]

I see that you've posted six times in different areas of the Forums on the same day with the same question, and now here on top of this issue and also on top of a FATES issue. No need for that, it makes it difficult for us to know how and where to respond. The best approach is to do a new post in the CTSM Forum and wait for support from either the CTSM group or the user community. We'll try to get you some help this coming week. If necessary, we'll also consult with the FATES experts. I've moved your new post from Community Projects to CTSM, look for a response there:

https://bb.cgd.ucar.edu/cesm/threads/clm5.7992/

Thanks!

[rosiealice]

On the SP decision, this option turns on the capability to run FATES with LAI from satellite products as an input. This mode doesn't simulate all the vegetation pools and so does not generate NPP. It will simulate GPP. To spin up the biomass pools you will need to do a spin up period.

Perhaps some background on your science question would be helpful to decide which is appropriate. FATES has several other options to reduce complexity depending on what is required.

Please note also that the current paramétrisation of FATES is not considered scientifically supported for global runs, pending calibration....