NGEET / fates

repository for the Functionally Assembled Terrestrial Ecosystem Simulator (FATES)
Other
99 stars 91 forks source link

FATES-SP mode #167

Closed ckoven closed 3 years ago

ckoven commented 7 years ago

At the bottom of a FATES complexity hierarchy (with the normal model at the top and St3 mode, #166, in the middle) would be a FATES-SP (where SP stand for satellite phenology) mode. the idea here is to completely separate all the feedbacks between growth and physiology by making leaf area a completely forced variable. This is currently possible in big-leaf CLM/ALM and is incredibly useful for testing the model in the absence of feedbacks. the way it works in the normal SP mode is that the model reads in a stream of LAI based on MODIS and sets the model LAI accordingly. for FATES-SP to work, we'd need to start with this basic machinery and make some changes:

(0) I think this would only work / make sense with St3 mode also turned on.

(1) we'd need to disaggregate the canopy-level LAI to the cohort level. One way to do this would be to calculate what the "on-allometry" LAI is for a given cohort, aggregate the cohort LAI up to the canopy level, and then use that cohort-canopy relationship as a lookup table to calculate cohort-level LAI given a stream of canopy-level LAI.

(2) we'd need to pass the LAI streams info through the interface. note that CLM and ALM have diverged a bit on how they handle the SP streams (CLM now uses a multi-year LAI record, which I don't think ALM does).

(3) the LAI stream data is broken down currently by "canonical" (i.e. old-school) PFTs, which won't necessarily correspond to FATES PFTs, so we'd need to do some mapping there.

mdietze commented 7 years ago

ED2 has a similar mode, but it only controls the phenology, not the target LAI, and thus doesn't require disaggregation of the LAI and is quite useful in both fully dynamic and St3 modes. This is the mode I use for all of my modern temperate ED2 runs because the default deciduous phenology calculations are so far off, and using a driven phenology easily reduces one source of uncertainty.

This mode is also the one we use when dynamically assimilating satellite LAI and tower data, rather than taking that data as a deterministic driver [Viskari et al 2015 Ecological Applications 25(2): 546-558]

ckoven commented 4 years ago

Was about to start a new issue but then I remembered that this now-ancient one already existed, so adding to it instead...

Based on discussions at CESM LMWG last week, a critical goal in getting FATES used across a wider set of future CLM applications is to identify how simple in the model complexity hierarchy we can actually get with FATES -- i.e. what is the simplest possible biophysics-enabled configuration that still uses FATES rather than big-leaf-CLM code? (Note for simplicity I am saying CLM/CESM above because I was just at the CESM LMWG meeting, but I think all of this discussion applies equally to ELM/E3SM as well, and so invite discussion from interested parties of both groups). I think some discussion may help to lay out a foundation of what this could look like, and how we can best design a framework to accommodate both the FATES-SP and the current full-FATES, as well as other possibly useful modes between them in complexity space.

A possible design of FATES-SP could look like this. We allow the host model to read in the current set of big-leaf PFT maps, as well as the satellite-derived and PFT-resolved LAI maps, and pass both of them to FATES. At initiation, FATES assigns a single patch to each big-leaf PFT in a given gridcell, whose area is proportional to the big-leaf-pft coverage. Upon each of these patches, FATES assigns a single cohort, whose crown area is the same as the patch area that it sits upon. For that single cohort, growth, tissue turnover, and mortality dynamics are all disabled; instead the leaf biomass is assigned based on a daily calculation using the specified LAI and PFT-level leaf traits, the height, DBH, per-plant-crown area (and thus number density), etc. for any needed biophysics calculations would be set based on mean-individual traits for a given PFT. All carbon and other biogeochemical calculations downstream of GPP are turned off, and we don't worry about carbon conservation due to updates of leaf biomass. To speed up the code, we could try simplifying the canopy photosynthesis code as well; e.g. reducing the number of leaf layers, etc., to see whether we could approach CTSM(NWP) in speed...

The key advantage of this over the current setup is that all the biophysics routines could use the FATES code and thus any calibration/testing/improvements would apply to that code rather than the current big-leaf code, and thus move towards a single biophysics codebase that works in all complexity modes of the model.

For intermediate complexity versions, I think we could possibly use some but not all aspects of this approach. E.g., for a "prescribed biogeography" (but active demography and biogeochemistry) version of FATES, we could leverage the information that the host model has about PFT areal fractions, and again initialize one patch per PFT at startup with only cohorts and seeds of the corresponding PFT allowed to grow on that patch, but then allow the rest of the model patch/cohort dynamics to play out, and using a variant of the patch-labeling scheme—which we currently have in place to separate primary and secondary patches but could generalize a bit—to keep track of the resulting sets of PFT-specific but disturbance-resolved patches as they evolve in time. Such a scheme would thus allow certain aspects of demography to play out, while not being subject to the complexities of a full DGVM, and may thus be a really useful intermediate-complexity analog to the current BGC mode of the model.

Anyway, mainly hoping to start a discussion on on this topic as I think it is really important to envision and discuss details of how this might best be designed. Tagging some of the people that I've been discussing this with over the past days: @rgknox @rosiealice @dlawrenncar @billsacks @wwieder @swensosc @danicalombardozzi @aswann @glemieux

rgknox commented 4 years ago

We allow the host model to read in the current set of big-leaf PFT maps, as well as the satellite-derived and PFT-resolved LAI maps, and pass both of them to FATES. At initiation, FATES assigns a single patch to each big-leaf PFT in a given gridcell, whose area is proportional to the big-leaf-pft coverage. Upon each of these patches, FATES assigns a single cohort, whose crown area is the same as the patch area that it sits upon. For that single cohort, growth, tissue turnover, and mortality dynamics are all disabled; instead the leaf biomass is assigned based on a daily calculation using the specified LAI and PFT-level leaf traits, the height, DBH, per-plant-crown area (and thus number density), etc. for any needed biophysics calculations would be set based on mean-individual traits for a given PFT.

I like giving each pft its own patch, this will work well when we have multiple columns of vegetation per grid cell. If I'm reading this correctly, we will give each PFT a prototypical DBH and use allometry calculations to match with leaf area from the datasets. Thus modifying number density to create a match?

ckoven commented 4 years ago

@rgknox yeah that's close to how i see it. except we wouldn't worry about the leaf biomass allometry per se, and would instead let that be set via the satellite-derived LAI timeseries information. we would assert either a height or a dbh, and use the allometries to define the other one of those two as well as a crown area per individual, and thus a number density (calculated as cohort area / individual crown area) at startup, and then let that remain fixed in time. We'd then update the leaf biomass per tree = LAI * crown area per tree / SLA. It'd be slightly more complex than that if we let SLA vary through the canopy, but for now keeping it simple.

rosiealice commented 4 years ago

Thanks @ckoven...

How important in this setup would it be to get the number density, dbh, etc. correct? Are we assigning them as simple placeholders, or wanting to get them ballpark correct so we could, say, estimate NPP?

Also tagging @huitang-earth, with whom I was discussing some similar issues a few weeks back...

ckoven commented 4 years ago

@rosiealice in principle the number density would basically be a placeholder. dbh and height could factor into aerodynamic roughness, and, once implemented, biomass heat storage, turbulent profiles, etc. for this, maybe we could go as far as NPP if we tie autotrophic respiration to the various biomass pools set by allometry, but that's about as far as I'd think would be defensible from a carbon cycle perspective.

wwieder commented 4 years ago

Beyond the FATES-sp configuration, could we also have a simplified FATES-bgc configuration that would use prescribed PFT vegetation maps- more similar to what we have in the big leaf model now? I'm imagining this may be useful for historical simulations, or for simulations when users don't want to worry about he complexity of the full demography model, or is this 2-steps back?

aswann commented 4 years ago

I would love to be able to have both modes (fixed LAI ala SP mode, prescribed biogeography) and also to be able to have the mode vary across gridcells in a single simulation. That way we could do experiments where full dynamics is allowed in some places while it is fixed in others.

I'm a little confused if what @wwieder is asking for is different from what @ckoven suggested with prescribed biogeography?

wwieder commented 4 years ago

You're right, Abby. Charlie's intermediate complexity suggestion that second, prescribed biogeography option. sorry for the confusion.

danicalombardozzi commented 4 years ago

These options all sound exciting and seem like a realistic path forward. If I understand correctly, I also think the proposed design will also allow for simulations with the crop model and changing land use. It will be interesting to see if we can also incorporate the shifting cultivation concept. Will all the FATES patches share the natural vegetation column, or do the columns vary based on primary vs secondary?

On Thu, Mar 19, 2020 at 3:40 PM will wieder notifications@github.com wrote:

You're right, Abby. Charlie's intermediate complexity suggestion that second, prescribed biogeography option. sorry for the confusion.

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

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

email: dll@ucar.edu office: (303) 497-1777

huitang-earth commented 4 years ago

@ckoven @rosiealice @rgknox, with regard to SP mode, do you have any thoughts on how to prescribe SAI? It seems to me that SAI in FATES can be simplied assigned the value from satellite-derived SAI timeseries, as SAI is not as much linked to plant allometry as LAI in FATES. But on the other hand, could the satellite-derived SAI be used to define some parameters of each cohort (e.g., DBH, crown area per individual etc.)?

In addition, in the SP mode in CLM, satellite-derived top canopy height (HTOP) and bottom canopy height (HBOT) are also used. Should these data also be used to set the height of the cohort and the crown depth used in several places in FATES?

rosiealice commented 4 years ago

Critical path to get to SP model

Given that we are still in the business of implementing SP mode in FATES, hopefully pretty soon, I made this list of tasks on the critical path. I put it in a google doc to made it easier to comment & edit. https://docs.google.com/document/d/1n72jKxuxvF4pxTKCpZ1Ot_w1y_aK24LpO37gumnFStA/edit

The doc also contains a link to code for a function (and an excel sheet for checking the logic) that I think should invert the existing calculation of treelai from leafc, to give leafc as a function of the asserted treelai (taking into account the variation in sla through the canopy). In.b. that u's not on a branch etc. for now as I'm waiting on the rebase to start implementing this properly to avoid confusion. https://docs.google.com/document/d/1k_iqWl9YkOaGqU52pcvI17byrCL0L7L2Vnf0VE4It_Y/edit?usp=sharing