FATES Albedo Bias

[rosiealice]

So, I have been focusing a little bit on the albedo bias in FATES, as it is upstream of all the other processes...

The bias shows up in all the SP mode simulations. e.g.
https://compy-dtn.pnl.gov/need138/rcmodes_default_JH_params/RadiationandEnergyCycle/Albedo/CERES/CERES.html

where it appears to be uniformly quite large. From analysis comparing to CLM5 I did previously, this is pretty sensitive to the layering structure.

2D ensemble (leaf layers)

While getting the ensemble script jupyter tool up and running, I ran a 2D ensemble looking at the layer thinkness and increase factor. The outcome, for reflected solar flux (FSR) is here (other outputs in same directory).

https://github.com/adrifoster/fates-global-cal/blob/main/jupyter_ppe_scripts/figs_RTM_ens3/RTM_ens3FSR.png

Bearing in mind that this is Wm-2 and not albedo (unitless/fraction), the impact is still quite large, and in the order 7W/m2. It seems by eyeballing this that we can get most of the improvement from changing the layer thickness to 0.1 and the increase factor to 1.1. Oddly, raising the increase factor any further winds up reducing the albedo.

There are some interesting interactions with GPP which might merit further investigation.
Putting this here mostly to flag, (particularly to @JessicaNeedham ) that we should perhaps test and switch asap to a setup where the big radiation bias is removed using those parameters, before we go much further.

We are going to try and run these through ILAMB once we figure out the scripts, but it might be a few days as there are a bunch of meetings this next week...

One at a time ensemble

There is some OAAT output also in e.g.
https://github.com/adrifoster/fates-global-cal/blob/main/jupyter_ppe_scripts/figs_RTM_ens1/RTM_ens1FSR.png

which shows how the remainder of the variables impact the RTM. The clumping factor is probably of greatest interest. Making it smaller hugely reduces the albedo, as well as the radiation absorbed by vegetation (more radiation gets to the ground). Compared to the CLM5 big leaf model (insert caveat about why that isn't -truth-, etc.) FATES has a low bias for absorbtion, so this lever is somewhat orthogonal to fixing that, and at it's current setting (0.85) may be making things worse.

I did some analysis of 'xl' as well. I'll post that tomorrow. Apologies for the slight 'train of consciousness' of this post. Trying to leave the office in a rush :)

[JessicaNeedham]

I did a similar analysis in May looking at leaf layer thickness. Happily I came to the same conclusion as @rosiealice that leaf layer width should be 0.1 with an increase factor of 1.1. I also changed the number of leaf layers to 36 so that the cumulative sum of vai bins was approximately equal to 30 (what it would be in the default case with bin width and increase factor both = 1 and nlevleaf = 30) but I'm not sure how important that is.
Results from that analysis are here (ILAMB) and here(brief slides summarising results).

When I tried those parameters in full fates I got a radiation error and the run crashed but I got busy with other things and never followed up. I'm re-running now in full fates with the leaf layer parameters at 0.1 and 1.1. to see if I get the same error. I'll report back shortly.

(Also including @jenniferholm's changes to freeze mortality for pft 6).

[ckoven]

ok, I guess that's better reason for a crash than a radiation balance error!

[JessicaNeedham]

I wonder if nlevleaf needs to be a function of the two leaf layer parameters? Otherwise users changing these parameters might frequently run into this issue.

[rosiealice]

How did it go? Did the change in the max layers solve the issue?

[JessicaNeedham]

I think so, it has run for 143 years now without any errors. Increasing nlevleaf slows down the run, but I haven't quantified that properly or how few layers we can get away with for vai params 0.1 and 1.1.

[rosiealice]

I recall that the creation of the leaf layered outputs might be one of the big drains on computing time for this type of thing....

[rosiealice]

Just linking to the slides I shared in the CLM meeting last week.
https://docs.google.com/presentation/d/1UbafNvg6Gp-ftjRl1FY73c1hvufULCh18NoMKcyLlYs/edit#slide=id.g190dd62b427_0_0

Sorry about the teeny tiny plots. Will try to reduce the dimensionality of the output!

[ckoven]

Thanks @rosiealice! Is it ok if I show a plot or two from this on today's NGEE-Tropics RFA3 call as an update on the global FATES calibration effort as it pertains to NGEE-Tropics pantropical runs?

[rosiealice]

Thinking about this some more after our discussion earlier, I think what might be the quickest solution is to implement the basic rtm from fates inside MAAT. I will try and strip it back to a simplest case R script and talk to Anthony...

[rosiealice]

... to which end I have overcome my fear of the RTM code and written this stripped down version in R
https://posit.cloud/content/5051674

[rosiealice]

Copying to do list for albedo bias from presentation.

Short Term

Compare with CLM5.1 DONE
Switch to using Jennifer's parameter set. DONE
Make albedo specific ilamb config file DONE
Run entire ILAMB comparison for radiation
Push ILAMB results on to some sort of website (in script)
Write code to multiply FATES-SP LAI by 1/clumping.
Acquire new ILAMB scoring system
Debug scoring w/ Nate
Make priors from LHC from M&B and leaf angle papers.

Medium Term

Make different rtm grid
Modify the soil reflectance and or snow properties
Generate sparse grid capability
Data assimilation? (Tristan Quaife, Kris Aalstad)
Quick and coarse vs. cutting edge and slower (r.e. CLM6/CESM2.

[rosiealice]

OK, a new update.

1. The R code that I have on the simplified Norman scheme give the same answers, for a given set of boundary conditions, as the online FATES RTm scheme. So, the bug is not caused by all the additional ugly complexity in the RTM code.
2. Both the R code and the FATES code give different answers for albedo than the two-stream CLM5 code for a given set of boundary conditions.
3. The bias for the NIR is much greater than for the VIS stream.
   VIS albedo is about 2% high biased for diffuse and 1% for direct
   NIR albedo is about 6% high biased for diffuse and 3% for direct.

So it might be possible that for visible light, FATES is giving similar biases (this is with a dLAI=0.2) as Anthony sees in his MAAT analyses, but that the solution is even more high biased for NIR rho/tau values.

FWIW, these boundary conditions are:
LAI=5, SAI=0. dLAI (constant layer thickness) = 0.2 (25 layers).
Leaf properties per FATES BET, for the '1x1_brazil' site
rho_layer_vis = 0.11
tau_layer_vis = 0.06
rho_layer_nir = 0.46
tau_layer_nir = 0.33
xl = 0.32
clumping_index = 1.0
gnd_alb_vis = 0.09
gnd_aøb_nir=0.18

With a coszen of 0.817996272620767, (weird value from real model timstep) this gives
CLM5:
albi VIS,NIR = 3.653248604663803E-002 0.315069215418133
albd VIS,NIR =5.192488519201940E-002 0.381910826687915

FATES
albi VIS,NIR = 5.571791941271746E-002 0.374676106207336
albd VIS,NIR = 6.357991669035215E-002 0.411262889248216

So, I think the next logical step is to look at the biases in MAAT (or other offline two-stream code) with the NIR optical properties (unless you did that already Anthony?) and see if this is an 'expected' bias.

If it is, then we might well need to think hard about replacing the existing scheme with an alternative. I'm feeling a bit less frightened by it now, so this doens't seem as onerous as it did at the beginning of the week (but still....)

[ckoven]

Thanks @rosiealice and @walkeranthonyp. Just trying to think this through and understand the implications. Does a larger NIR albedo overestimate than VIS albedo overestimate logically lead to the behavior that we've tended to find, where FATES tends to underestimate the transpiration flux for a given GPP, since a larger fraction of the light that is absorbed is photosynthetically active than it should be? Or are those two things orthogonal to each other?

[walkeranthonyp]

Oh good question. I don't think enough about ET but that does seem to make sense.

I don't have a good feel off the top of my head for how much that might affect ET though and what that would lead us to expect for the ET bias relative to GPP.

[rosiealice]

Yes, @ckoven, that is what I had thought as well r.e. Not getting enough NIR energy into the canopy.

[rosiealice]

Bookmarking Gordon's two stream multilayer code, for obvious reasons...

https://github.com/gbonan/CLM-ml_v1/blob/main/multilayer_canopy/MLSolarRadiationMod.F90

[rosiealice]

Digging into literature to think about plausible ranges for NIR optical properties, if we are to tune these and or look into their impacts on physiology.

Pretty high NIR reflectance for high latitude trees in Mjasalmi and Bright paper:
https://gmd.copernicus.org/articles/12/3923/2019/gmd-12-3923-2019-f03-high-res.png

Much lower values for tropical trees? https://www.sciencedirect.com/science/article/pii/S0034425720302352

I don't if these methodologies are compatible? Will do more digging

Lots of tropical forest info here from this recent paper on lianas in Panama from Hans Verbeeck's project. Clumping factor for trees is much lower than our default (~0.5).
https://onlinelibrary.wiley.com/doi/pdfdirect/10.1111/gcb.15928

Similarly, this paper from Ali Shenkin has much lower visible reflectance numbers(0.05) than we use for tropical forests. They have some CLM4 simulations on the impact of changing albedo. As I recall, clm4 had a bug in its treat,ent of radiation that was pretty critical?
https://benjaminblonder.org/papers/2018_NEE_albedo.pdf

[jkshuman]

adding this old issue on leaf layer resolution to the discussion NGEET/fates#747