Some various issues around the overlap of land use and land cover (i.e., PFT) data

[ckoven]

Hi All,

I have been working on extending the land use change code to work with nocomp (i.e. prescribed landcover) configurations. There are a few implementation issues that this raises that I want to put out for discussion, so that we can hopefully do this in a way that is as simple but future-proof as possible. They all sort of relate to each other, so I thought it might be useful to put into a single discussion thread.

1. Where to track the data relating to PFT x land-use mapping? For non-crop land-use types, the idea when prescribed landcover is active is that FATES will access mappings for each (non-crop) land use type that have a dimension of latitude x longitude x PFT, which specify what fraction of the surface in that land-use type is covered by which PFT. The source of that data comes from @lawrencepj1's CLM5 land use tool, and for those interested, I have a jupyter notebook which reworks that data to put it in the form that FATES will use. The first question is where to put this data. It is in principle based on satellite-era observations, but (for now at least) the plan will be to use the derived land use x land cover mapping in a time- and scenario-independent way. I.e., the land use itself is scenario-dependent but the mapping between land use and land cover is not. So, we can choose to either (a) copy all the data into each of the scenario- and grid-specific land use files (i.e. that are created by the code in FATES LUH2 data curation tool #1032), or (b) make a new file that is independent of scenario (but still dependent on grid).
2. As part of the above, one slight difference with how we are currently doing things is we'll pass in the bare ground fraction as its own variable that is independent of land use type, and thus only have PFTs 1 through natpft. So this means that bare ground fraction doesn't change with land use change, and also lets us get rid of the whole PFT zero logic, which is good because PFT zero has always been confusing (to me anyway). We can change the corresponding logic for when nocomp when land use change is not enabled as a subsequent PR.
3. The above gets us the PFT fractions for the non-crop land use types. How should we specify the PFT fractions for the crop land use type(s)? In the near-term it is sort of a trivial question because, since there isn't currently much focus on representing crops in FATES, we've decided to just have a single crop type with a single PFT on it for now. But that could change, so we ideally want to do something that is at least somewhat future-proof. The key thing is that this will need to apply in basically all FATES configurations (SP, nocomp, and full-FATES) once we have land use turned on, so we also want something that can be consistently used across configurations. I see a few different options here, ranging from simplest to most complex, with a corresponding tradeoff between least future-proof to most future-proof.
   1. we make a single scalar variable on the PFT parameter file, which is the (FATES-)PFT index of the crop land use type. This assumes that we have only one crop land use type and only one PFT on that type.
   2. we make a vector of land use types, and for each land use type we have the (FATES-)PFT index of the PFT that is allowed on it. We set it to some special value so that it is ignored for non-crop land use types. This lets us expand very easily if we want to have, e.g., separate C3 and C4 crop land use types with the corresponding PFTs on each of them, but it still only lets us have a single PFT on each crop land use type.
   3. we extend the (FATES x HLM) PFT matrix to include beyond the natpft index in the HLM-PFT dimension, as in Facilitate crops in SP mode.  #817. I think we would also still need some sort of mapping as in option (ii) above, so that the code knows which parts of the PFT matrix correspond to which land use types, but maybe the vector would actually be the index of the HLM PFT on each land use type, and then it would use the PFT matrix as a second step in the look-up table process? The advantage of this over the strictly option (ii) above is that it should play better with the actual SP datasets, since those are indexed not by HLM natpft but by HLM (natpft + cft).
   4. we add lat x lon x (FATES-)PFT maps for the crop land use type, which might trivially just be a bunch of ones in the crop PFT index and a bunch of zeros everywhere else. But this would in principle let us have more than one PFT on each crop type if we ever want to go that direction. We may still need some aspects of option (iii) above to get the SP mode logic to work right. We could put this field into the same file as in point (1) above, which if we do that would mean that we always read it regardless of configuration.

OK, that is all for now, I didn't get to actually diagramming any of this yet but may try to if that would be helpful.