LUH2 integration

[marcadella]

LUH2 is the de facto source of LULUC data. One cell of LUH2 could be mapped to one BiomeE grid cell (== ensemble of vegetation tiles, each corresponding to LU state) in a global simulation. If we consider only one cell (which is the scope of BiomeE), a time series of LUC can be extracted from one location from LUH2 h, f and e (historic, future and extended) datasets.

Questions:

1. How deeply do we want to integrate LUH2 into BiomeE?
   1. Shallow integration: we implement LULUC into BiomeE without thinking too much about LUH2, then we implement an R wrapper which helps mapping LUH2 data into the BiomeE concepts.
   2. Deep integration: LUH2 is first-class citizen and LUH2 conventions are used down the the Fortran layer.

Whatever the answer to the first question, it is a good idea to already have an idea of how LUH2 concepts map with BiomeE concepts. LUH2 has 5 LU states (each with its own set of subtypes):

• primary
• secondary
• cropland
• grassland
• urban

2. For LUH2, primary --> secondary is a one way road, that is a secondary area can never go back to a primary state. Does it make sense in BiomeE to have the concept of primary vs secondary, given that for BiomeE the only difference is the initial condition of the tile: primary -> post spinup ; secondary: biomass removed.
3. Should BiomeE have a concept of forest vs cropland vs grassland tiles? The PFT obviously differs (i.e. configuration of the tile), but should there be separate tile types for each kind? Or one type will do but with specific tile configurations embeddeing the difference in behavior?
4. What about urban tiles? Should we ignore for now and deal with it when the time for global simulation comes?
5. When to merge forested tiles? There are different strategies:

• Could merge tiles under a minimum size.
• Could merge tiles to not go beyond a max number of tiles.
• Could merge tile older than a certain age back into the "primary" tile.

6. How to merge forested tiles?

• Could merge tiles with similar C and/or N pools.
• Could merge smallest tiles together.

7. LUH2 includes harvest information. Should these be included in our model (as $\Delta A_{harvest} $)?
8. Should the section '2.2 Generated transitions' from Stocker 2014 be ignored (since the transitions come from LUH). In other words, do we want to use the GNT method in BiomeE?

[marcadella]

@fabern @stineb any answers/ideas?

[fabern]

1. How deeply do we want to integrate LUH2 into BiomeE? [...]

1. Not sure I understood. But I believe in issue LULUC design document #272 you have by now already drafted a concept, right?

2. For LUH2, primary --> secondary is a one way road [...]

2. Yes, I'm not sure either if we need to distinguish. Eventually it could be used to read out which part of a landscape has never undergone a transition. (Unless we enable transitions outline in your 5th question.) There might be areas where the modelled primary forest just disappears and others where it remains. But I am skeptical how we could translate this model-based result to reality.

3. Should BiomeE have a concept of forest vs cropland vs grassland tiles? [...]

3. Not sure I understand what you mean with configurations. So one aspect is the naming of a tile type, the other is the PFTs admissible on each tile type. All land that is agriculturally used (cropland, grassland) should be different and only tracked by single tiles per grid cell. Separate from that are the (unexploited) grassland and forest tiles. Is it separate in LUH2? I see the driving question as whether the transitions from grassland to forest (and from forest to grassland) are prescribed as forcing or are emergent from the model parameters.

4. What about urban tiles? [...]

4. Ignoring is okay. Maybe make already some thoughts on what would be different. (However, given that urban tiles have almost no interaction. Maybe implementation would even be simpler than separately documenting the differences.)

5. When to merge forested tiles? [...]

5. Max number as well as minimum size would make sense. For modelling minimum size might be a better criteria. But computationally the max number strategy is probably better behaved. I would thus go for the max number.
   Regarding transitioning old tiles to primary: See answer to 6. regarding the merging of tiles with distinct properties.

6. How to merge forested tiles? [...]

6. Good question. I'd argue against merging smallest tiles. We should group together trees/landscape patches that in reality show similar behavior of what we want to simulate (i.e. fluxes and vegetation dynamics). Merging together two very different tiles and predicting an average behavior might be a bad prediction because the behavior is non-linear (so the average behavior of the two separate tiles is not the same as the behavior of one average tile). The error on the dynamics of the whole gridcell remains limited if this concerns only the smallest tiles. Nevertheless, I think we should merge the most similar tiles - not the smallest.

7. harvest [...]

7. From what I understand of your implementation plan wood harvest is a transition, right? Either primary-->secondary or secondary-->secondary. I think it would be good if there is an interface to handle this. However, there are many ways to specify harvest, some might be clearcut others might be conditional (e.g. 100% removal above a lower DBH limit, 50% of each DBH class, or different fractions from different classes. Maybe also species-specific.). What are the harvest information available in LUH2?

8. 'Generated transitions' [...]

8. I am not yet familiar with the GNT method.

[marcadella]

1 - I was too excited to wait so I already started a design draft yes ;)
3 - All transitions a prescribed, so grassland to forest happens only if there is a transition telling so in the forcing data. My question was actually referring to whether something needed to be added to Biomee to represent a grassland other than prescribing the PFT (some kind of grass). But I think I have the answer: there is nothing in Biomee implementing grassland being grazed... In other words, LU are not implemented at all, and that obviously needs to be implemented (and parametrized).
6 - Makes sense, but defining a similarity criteria is not trivial: C density? N density? Both? C/N ratio? Vegetation dynamic cannot be used in most cases. For instance, we'd merge a clear-cut forest patch into a grown up forest.
7 - Exactly, when Iwrote the question I wasn't sure about how harvest was represented in LUH2, but it is implemented as the transitions you describe (clear-cut). They also give the amount of carbon harvested and this information could be used to implement more complex harvesting techniques (such as cutting down the largest trees until reaching the prescribed amount of C).

[stineb]

2. Primary is to be understood as never affected by land use change during the simulation. It should be distinguished from secondary land. LUC2 is specified such that primary actually does remain untouched.
3. Beware: there are intersecting concepts for distinguishing land: potential natural vegetation cover (which could be forest, savannah, grassland, desert, ...); land use (which specifies how the land is used: as a cropland, pasture, urban, or unmanaged). Unmanaged is further distinguished into primary (never managed before), and secondary (managed before either as cropland, pasture, urban, or harvested, but currently dynamics of potential natural vegetation simulated). The initial reduced distinction into managed, unmanaged, and urban land makes sense. Eventually, we will definitely have to distinguish managed between croplands and pastures.
4. urban tiles should not be ignored eventually. Ignoring for an initial simplified setup is ok.
5. max number makes sense, I agree. Just never merge anything with primary.
6. number of tiles should have an upper limit. Merge to not exceed a max number and merge the oldest two secondary.
7. start with harvest as clear-cut with affected areas taken from LUH2.

All these questions also have an answer in how it is done in LPX. This should be the guide (and as far as possible the blueprint) for our adoption. I don't currently see any reason to change anything from how it was done there. If the answer is not clear from LPX, let me know and I can try to figure it out or point you to where you'll find the answer.

[marcadella]

Thanks, I updated #272 with your comments. I don't think I'll manage to go very far with LPX without your help indeed. But there is plenty I can already do to establish the main data structures independently of the nitty-gritty in LPX.
I'll close this issue as it is easier to keep all the discussion in #272 .