Forest age data-model comparison

[rosiealice]

So, one of the things we need to do for NextGenCarbon is to compare the FATES forest age with the Besnard et al. (2021) forest age data product, GAMI (Global Age Mapping Integration), described in this paper
https://essd.copernicus.org/articles/13/4881/2021/

The data are hosted here:
https://dataservices.gfz-potsdam.de/panmetaworks/showshort.php?id=8f5974e7-3ece-11ef-967a-4ffbfe06208e

And the data download site is here:
https://datapub.gfz-potsdam.de/download/10.5880.GFZ.1.4.2023.006-VEnuo/

The original data are at 1km resolution. I have downloaded the 0.25 product for now, but we could potentially go for a higher resolution one, depending on whether there are time penalties in doing so? The data are in here:
/datalake/NS9560K/diagnostics/ILAMB-Data/DATA/forest_age/GAMI2.1/GAMIv2-1_2010-2020_class_fraction_0deg25.nc

The main variable, forest_age is dimensioned as (members, age_class, latitude, longitude, time)
Where 'members' are ensemble members spanning a spread of uncertainty in the generation process.

The data have two time slices, for 2010 and 2020. 2020 looks like this:

and the difference 2020-2010 looks like this:

---

The FATES output variable that I think best corresponds to this is FATES_PATCHAREA_AP. Which, a random non-spun up example of which is plotted here:

and here is a gif just for entertainment value:

(This is not supposed to be a direct comparison of the outputs, as this is not the right run. It is more of an exploration of the data)

There are several issues to resolve with this comparison:

1. The diagnostics are not set up to handle more than lat/lon/time dimensioned variables, so either we need to implement that, or reduc the dimensionality of the data product and the model output, to use, say, mean forest age instead of the age classes
2. the data product age classes are quite a lot different from ours. This is resolvable using the fates_history_ageclass_bin_edges parameter in the FATES param file.
3. How do we deal with the ensemble members? It might be best to take the mean and then have that as the primary file we store in the diagnostics directory?

If we wish to make a mean age class, we might want to create that output in FATES itself, or we can rig up the diagnostics to create mean values (the logic of which is perhaps subtlely different for different types of output). This we probably need to discuss.

In the interim, I will try and locate a spun up run to allow an actual comparison with what we have in FATES vs GAMI.

[maritsandstad]

To question 3, I do think some aggregated statistic would be the better option inside the diagnostic. It can be a discussion point whether the original non-aggregated data live in the same folder or not. It's probably more appropriate to have it be elsewhere, but it won't do any harm hanging out there either...

1. Can also be discussed, one option could be either to split in separate files, but I think it might be cleaner to think of how to implement extra dimensionality in diagnostic variables. I can try to think about how to do that...

[rosiealice]

I agree @maritsandstad (with the q-3 response above).