Add some interfaces to get the list of FATES PFT's and their areas in each site

[ekluzek]

In order to get MEGAN and dry-deposition to work in CTSM with FATES in the current form, I need an interface in FATES that returns a list of all of the FATES PFT's and their areas. This can then be used in CTSM to figure out dry-deposition/MEGAN based on vegetation type. The current algorithms are primarily based on PFT type, along with with a few other things like LAI and photosynthesis.

The HLM doesn't have a way to go through the cohorts and add area's up for PFT's, so I think we need an interface in FATES to do this for us.

See the CTSM issue on DryDeposition here...

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

Definition of done: Add an interface to FATES that will get the list of PFT's in each patch, so that the HLM can operate over PFT's within patches and know how much area goes with each PFT within the patch.

[jkshuman]

@ekluzek thank you for opening this. We will need to discuss a method to tackle this as FATES PFTs are mixed on patches, so there is not a direct connection to a single PFT.

[rosiealice]

Hi all,

If we follow the previous methodology for doing this sort of thing, which places all the 'vegetation function' in FATES, then we should ideally assign MEGAN parameters per veg type in the FATES PFT file, and have FATES calculate the relevant weighted patch scale quantities.

Not sure if MEGAN code break apart easily into veg & non veg portions. I'll take a look...

[rosiealice]

Ok, looking at this, what CTSM uses is a map of the emission factors for six basic PFTs, which are themselves mapped on to the HLM PFTS.

So we could either do that weighting in FATES or stick with how it works now and pass an array of PFT fraction to CLM, -as well as- some sort of index which maps from the FATES to the MEGAN PFTs, which are crops, grass, shrubs, broadleaf, evergreen needleleaf deciduous needleleaf

If we did that there could be a weighting function in CLM as Erik suggests, that would calculate the isoprene emission factors.

Otherwise we will have to feed the emission factors into FATES (per column) which I think (retracting my previous comment) would be too messy.

We already have a bunch of variables that contain this information that are currently diagnostic. I.e, https://github.com/NGEET/fates/blob/cb379c5d6375bf7d198acb1d4b569c84f079082c/main/FatesHistoryInterfaceMod.F90#L510

I guess they'd need to be passed through the interface instead?

[ekluzek]

@rosiealice yes I think we'd need it passed through the regular interface and not just part of history files. I like your table above as it's more direct to what's needed. But, we also need to have work with dry-deposition. The table that's used for dry-deposition is like this:

This is from: components/cmeps/cesm/nuopc_cap_share/seq_drydep_mod.F90

 ! index #2 : landuse type
  !           1 -> urban land
  !           2 -> agricultural land
  !           3 -> range land
  !           4 -> deciduous forest
  !           5 -> coniferous forest
  !           6 -> mixed forest including wetland
  !           7 -> water, both salt and fresh
  !           8 -> barren land, mostly desert
  !           9 -> nonforested wetland
  !           10 -> mixed agricultural and range land
  !           11 -> rocky open areas with low growing shrubs

So the list that comes into play for FATES

  ! index #2 : landuse type
  !           2 -> agricultural land (crops)
  !           3 -> range land (grass)
  !           4 -> deciduous forest (broadleaf)
  !           5 -> coniferous forest (evergreen needleleaf and deciduous needleleaf)
  !           6 -> mixed forest including wetland (this is currently unused in CTSM)
  !           8 -> barren land, mostly desert (bare-soil)
  !           11 -> rocky open areas with low growing shrubs (shrubs)

Please make sure my mapping is correct.

But, overall your table of seven types seems sufficient (adding one more to your table for bare-soil). So I agree rather than sending back a table of all CTSM PFT types you send back the table of the seven more general types. And then CTSM can take the table and do the mapping needed for MEGAN and Dry-deposition. So the seven types would be:

bare-soil crops, grass, shrubs, broadleaf, evergreen needleleaf deciduous needleleaf

[ekluzek]

Looking at the code I edited my comment above to get a final table of seven that I think covers everything. It looks like the mixed forest is just not used in CTSM, so we can leave it off.

[rosiealice]

Hi @ekluzek @danicalombardozzi

Yes, that table looks good in terms of covering both sets of PFT needs.

Noting that we'd have to do this FATES->MEGAN PFT mapping in FATES-SP mode as well as the other modes.

So, I guess we'll need to make a 'Megan mapping index' PFT parameter in FATES, and pass back it back as a patch variable to CLM (noting that there will presumably be a parallel set of problems for ELM?)

I -think- the remaining question is - do we:

1. Report the dominant MEGAN PFT in each FATES patch to CLM
2. Report a vector of MEGAN PFTs and their associated fractions, and then use that in CLM to make a weighted average emission factor.
3. Not sure here is. 3...

For SP mode, (and NOCOMP) there is only one PFT per patch and this is easy.

For full-fates mode, I guess the question is whether '2' is scientifically valid or not? (If I've interpreted you right, Erik?). It might just be straightforward. I could maybe drop someone (Alex?) a line and ask? Otherwise we could stick with '1', which would be mildly unsatisfying but probably not disastrous?

[ekluzek]

@rosiealice I think the problem with "1" above is that the dominant PFT might be the same for every patch. In this case it would appear that you only have trees for example, and it'll ignore the fact that there is some shrub and grass.

But, we also have the problem that each patch is going to use the averaged LAI and other characteristics needed for the calculation that is based on the average of all PFT's in the patch. So you either also have to bin these other fields that are needed, or put up with the fact that they aren't binned consistently. Maybe what you do for "2" is to report the vector of the veg-types and also a vector of weights that allows you to reconstruct the average LAI that's sent back to the HLM. The other thing I realized about FATES is that the vegetation area's can overlap for different PFT's, so the weights for this need to be non-overlapping.

So it might make sense to first try dominant PFT (Ii.e. "1") and then get a feel for how bad of an assumption that is. Then you might try "2", and see how different it is. Then "3" could be to bin the needed fields (like LAI) the same way and see how different that is.

Although that still requires someone to do some scientific evaluation of all this, and I'm not sure who it is that would do that.

Is VOC and dry-deposition something that's going to be needed for ELM and E3SM?

So I suggest we have three different interfaces:

• One for NOCOMP that returns the one PFT index for each patch
• One that returns the dominant PFT for each patch
• One that returns the vector of veg-type indices and the weights that allow you to reconstruct average LAI.

[rosiealice]

Ah yes, you're right that '1' might underweight the shrubs and grasses...

I'm not sure I fully understand the LAI weighting issue. If you have a canopy with an LAI,of say, 5, and you then figure out an LAI weighted emission factor for the PFTs it contains, do you then still need to know that the canopy has, say, LAI of 4 for PFT1 and 1 for PFT2? Given we should already have accounted for that by weighting their respective emission factors 4:1?

Maybe I'm not understanding how the code works here (again!)?

[ekluzek]

The LAI weighting issue is something that I am proposing as a constraint to make sure the PFT weight classes provide something that makes it similar to how the LAI averaging was done.

We may be better off in having a discussion about all of this. But, let me try to illustrate by showing a few examples. Let's assume a PFT vector of three (tree, shrub, grass). And let's say we have three patches all of which are 80% tree, 10% shrub, and 15% grass (it adds up to more than 100% because the PFT's overlap). LAI for tree is 7, LAI for shrub is 4 and 1 for grass. And as you have said the averaged LAI is 5 (I'm not sure how FATES does it's weighting).

As we've discussed the simplest way to weight the PFT's is to use the dominant PFT. Note, though that the LAI for tree in FATES is 7, but it will use 5 as the average. So the value you use with this method has an average LAI that doesn't match what is being used.

The next way to do the weighting would be use the area weights and renormalize by 105 (to account for the sum of 80+10+15=105). That means the weights would be 0.761 for tree, 0.095 for shrub, and 0.142 for grass. So here the average LAI by that weighting would be 5.85, so it doesn't quite match the weighting that is being done for LAI, but it's a lot closer.

In order to match the average LAI I want to renormalize those weights so that I match the average LAI of 5, that just adds another constraint on their values.

Now, I say all this not knowing where or how the average of LAI is computed for a patch in FATES. I imagine those values are stored somewhere and they could just be returned here. Or it can be used to renormalize the weights just to make sure that the weighting is done in a consistent manner.

[rosiealice]

Ah right. So the issue is basically that we need to make sure the FATES weighting ps reflect how MEGAN actually perceives the system, in light of the fact that FATES PFTs can overlap.

We’ve a lot of different potential variables we could use in FATES to do this. The simplest might be to just use the total leaf area for each pft and make that (Leaf area PFT/total leaf area of all PFTs) the weighting?

I am not sure how to translate that into your analogy. I think the issue is between crown areas (as per the 80,10,15 example you have) and leaf area.

The crown areas can overlap, and add up to >100% of the patch because some are in the understory. The total leaf area includes the plants in the understory, and so the weighting would work out as ([7 4 1]/12) = [0.58 0.33 0.053] Which is another way of saying the leaf area index of a given pft in a patch is independent of its canopy or fractional area.

Another option than weighting by leaf area is to weight by the canopy (the top layer of plants, wherein the total area does add up to 100%) occupied by each PFT, and ignore both the area in the understory and the leaf area thickness of the canopy trees. Given the VOC emissions effectively operate at a leaf level , I suspect that is less correct. The leaf area weighting would probably retain the current behaviour of MEGAN better too.

I had a conversation with Alex about this a million years ago. He could probably point us in the right direction.

---

Dr Rosie A. Fisher

Senior Researcher CICERO Center for International Climate Research Oslo, Norway n.b. I am on partial medical leave at present. Thanks for your patience!

https://cicero.oslo.nohttps://cicero.oslo.no/

---

From: Erik Kluzek @.> Sent: Saturday, June 18, 2022 12:29:42 AM To: NGEET/fates @.> Cc: Rosie Fisher @.>; Mention @.> Subject: Re: [NGEET/fates] Add some interfaces to get the list of FATES PFT's and their areas in each site (Issue #879)

The LAI weighting issue is something that I am proposing as a constraint to make sure the PFT weight classes provide something that makes it similar to how the LAI averaging was done.

We may be better off in having a discussion about all of this. But, let me try to illustrate by showing a few examples. Let's assume a PFT vector of three (tree, shrub, grass). And let's say we have three patches all of which are 80% tree, 10% shrub, and 15% grass (it adds up to more than 100% because the PFT's overlap). LAI for tree is 7, LAI for shrub is 4 and 1 for grass. And as you have said the averaged LAI is 5 (I'm not sure how FATES does it's weighting).

As we've discussed the simplest way to weight the PFT's is to use the dominant PFT. Note, though that the LAI for tree in FATES is 7, but it will use 5 as the average. So the value you use with this method has an average LAI that doesn't match what is being used.

The next way to do the weighting would be use the area weights and renormalize by 105 (to account for the sum of 80+10+15=105). That means the weights would be 0.761 for tree, 0.095 for shrub, and 0.142 for grass. So here the average LAI by that weighting would be 5.85, so it doesn't quite match the weighting that is being done for LAI, but it's a lot closer.

In order to match the average LAI I want to renormalize those weights so that I match the average LAI of 5, that just adds another constraint on their values.

Now, I say all this not knowing where or how the average of LAI is computed for a patch in FATES. I imagine those values are stored somewhere and they could just be returned here. Or it can be used to renormalize the weights just to make sure that the weighting is done in a consistent manner.

— Reply to this email directly, view it on GitHubhttps://github.com/NGEET/fates/issues/879#issuecomment-1159279509, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADC2YQ6FPN676SH7HCKYTRLVPT35NANCNFSM5ZAJWVMA. You are receiving this because you were mentioned.Message ID: @.***>

[ekluzek]

I'm closing this as a wontfix, because we will get back to this when we want MEGAN to work with FATES in general. How this is done will be informed by scientific research in how MEGAN and dry-deposition should work with FATES.

[ekluzek]

Reopening so we can track this long term project.

[jkshuman]

Thanks for reopening this @ekluzek we will retain this and classify it as a "long term goal", as it needs more resources, as noted above in the discussion.

[glemieux]

Added to the FATES issue board and categorized as "long-term"