How to manage crop areas in FATES-SP mode. #760
Comments
|
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? |
|
I guess you could have the CLM5 crop model running in native CLM5-SP mode in parallel? Right? |
|
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? |
That is what I was thinking |
|
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
<#760 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB5IWJAJUMFZLU7EMKFZK33TVRZFVANCNFSM47UT6E5Q>
.
|
|
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
> <#760 (comment)>, 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
<#760 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC3OJOIK4YMTFCFH53X2HITTVRZ2XANCNFSM47UT6E5Q>
.
|
|
Righto. So the generic SP crop sits on its own land unit doing SP things and potentially being irrigated? Right? |
|
seems like your option (1) is the best plan, as it would be a first step towards a full FATES w/ crops implementation. |
|
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
<#760 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC3OJOIF2KZ4Z5VEHV6DYMDTVR653ANCNFSM47UT6E5Q>
.
|
|
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
> <#760 (comment)>, 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
<#760 (comment)>, 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
|
|
Thanks all. That's interesting @lawrencepj1 that the crop land unit doesn't occur at all without irrigation. Which means either we Doing only this would make FATES-SP incompatible with irrigation. To remedy that I suppose we could do either 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... |
|
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
<#760 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFABYVFLZO4N7MFP4RLKFL3TWGVVPANCNFSM47UT6E5Q>
.
|
|
Note, the CTSM issue about using the CTSM crop landunit is here. This issue is different but related to this one here. This would use the CTSM big-leaf code to runs crops, which could also be done for FATES-SP mode. |
|
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. |
|
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 :) |
|
@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. |
|
Here is where we decide whether a column is handled by FATES, as I see it 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... |
|
@rosiealice , I believe that gets us half way there 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. |
|
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
<#760 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFABYVEEP7YR554JNJTAKVTTZ3AM5ANCNFSM47UT6E5Q>
.
|
|
@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 #760 (comment) 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.) |
|
see #817 |
|
@rosiealice @ckoven for my SP calibration I am treating the crops as c3 grasses. Is this a sufficient solution? |
|
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 |
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
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 ?
The text was updated successfully, but these errors were encountered: