Review of wood cascading

[CarrerF]

1. In
   SysVar_WoodWasteFuelWoodSubst_tr = np.minimum(SysVar_Carbon_FuelWood_2_7_tr,SysVar_WoodWasteIncineration[:,:,Woodwaste_loc,Carbon_loc,mS,mR])

the underlying assumption is that the fuel demand from use phase is met with available wood waste. However, fuel wood demand is high in low income/electrified countries, where it is difficult to imagine an efficient collection system of wood waste and redistribution (while I'd rather imagine wood being manually collected from forests).

2. In
   SysVar_Energy_FuelWood_2_7_tr = np.einsum('trp->tr',SysVar_EnergyDemand_UsePhase_ByEnergyCarrier_pav[:,:,:,WoodFuel_loc]) + np.einsum('trB->tr',SysVar_EnergyDemand_UsePhase_ByEnergyCarrier_reb[:,:,:,WoodFuel_loc]) + np.einsum('trN->tr',SysVar_EnergyDemand_UsePhase_ByEnergyCarrier_nrb[:,:,:,WoodFuel_loc])

pav is reported (not wrong, but cannot imagine any relevant scenario) and nrbg is missing.

3. All wood waste goes out of the system in physical form (SysVar_WoodWasteIncineration contributes to F_9_0), but BiogenicCO2WasteCombustion uses part of it to calculate credits. I understand that this preserves mass-balance, as direct emissions are accounted as impact only, and not in the carbon cycle. However, to someone that does not know the code, F_9_0 might seem like all the wood that goes out of the system, while part of it is used to produce energy within the boundaries of the RECC system.

4. In Par_RECC_WoodWaste_Casccading, is the typo intended?

5. (minor suggestion) In the Model parameters section of the config, I would propose to rearrange the order of parameters. For example, wood cascading parameters such as 3_LT_Wood_Cascade, 3_MC_CO2FromWoodCombustion and 4_PY_WoodCascading are sparse in the list (same for other sectors, for which demand, lifetime and material composition are in an unclear order). It would be beneficial to have the parameters clustered by sector (as an "overview" of the sector), or eventually in alphabetical order (to facilitate the comparison with the dataset working folder).

6. (not related to woos cascading) Master_RECC_v2.5 setting uses V1.1 of 4_PE_ProcessExtensions Materials, but only V1.,0 is in the dropbox folder. Is there an updated version?

[stefanpauliuk]

Hi @CarrerF, thanks for the feedback!
Here my point-to-point reply:

@1:
Here, we don't talk about harvest residues but about all waste that comes from processing industrial roundwood only, which, since it's already within the industry and would be a waste otherwise, is fully utilised as material (here, we have the cascading factor) or as energy feedstock (pellets).

@2: yes, the inclusion of pav does not make a difference, and nrbg is no longer maintained and will be removed for v2.6, since we now have nrb at the 20 region level.

@3: Here, we have a material flow that is part of the MFA system variables but an envrionmental extension at the same time. I have not systematically thought about how to handle these cases, that's why it appears twice, in the MFA layer and the emissions layer. The carbon cycle/cascading model is an add-on to the material cycle model, which can be seen at different places. Must be done differently in RECC v.2.6!

@4:
No, fixed and committed.

@5:
Good point! The current list have evolved 'organically'.
Since the order of the parameters does not matter to the model, I re-arranged it in the same order as when sorting them in the folder.
See updated config file!

@6:
Yes, it's now in the Dropbox folder, I had overlooked it.

[chauenstein]

Hi @stefanpauliuk, testing @CarrerF 's new interpolation version, I noticed that for runs with 'pav' some exit flags return 'FALSE' (e.g. 'Positive_Inflow_F8_9_R32_SSP_0_RCP_1: False', 'Positive_Inflow_F6_7_R32_SSP_1_RCP_0: False'). This is also the case when running the model with the version prior to the interpolation version for ODYM_RECC_Main.py (commit 7721b7d) and ODYM_Function.py (commit 07f93696b9e223aad259be2e4f973fec4bdc7da8). The mass balance is ok. Not sure how critical these exit flags are, but wanted to report it here to not forget.

[stefanpauliuk]

Thanks for checking @chauenstein ! Indeed, the spline interpolation routine can return small negative values when a curve starts at 0 and then increases to 100 % or so.

I've seen this problem for the type split, where passive houses are ramped up from 0 to 30% over time, with a few very small negative values in the first years.

Previously, I tried out interpolation routines that yield strictly postive values but found that they are unsuitable to produce the kind of growth curves we want to feed the model with.
So far, the solution therefore was to check for the negative values manually and replace them with 0, and change another building category slightly to re-establish the constraint that all building type shares must add up to 1.

What we should do is to check each interpolation result for its quality, most importanly, negative values. Then, maybe, a manual fix in the code?