101 estimate equilbrium litter stocks

[hrlai]

This PR aims to estimate aboveground, belowground and wood litter stocks for initialisation.

Initially we discussed to estimate stocks for all litter pools using the equilibrium approach in #101. However, as I go I feel that we should simply use direct field measurements of stocks whenever available. From SAFE, we do have aboveground and wood litter stock. So I ended up only using the equilibrium approach for the belowground stock (whereas aboveground and wood stock are estimated from direct field measurements). Another reason to treat the equilibrium approach as plan B is because it is more sensitive to data quality and model specification (simply because it takes litter input and litter decay data and parameters from all over the place). Do you agree @jacobcook1995 ?

@jacobcook1995 you could simply jump to the output file and scrutinise the values? It is in the file data/derived/litter/stock/litter_stock.csv I am not 100% comfortable at the belowground metabolic pool being so low, and the belowground structural pool being quite high.

[hrlai]

@annarallings quick note on folders:

• the main script folder for this PR is in analysis/litter/stock
• but because I merged the litter decay branch 102 rethinking litter decay models #104 to this branch, this PR also included the other folder analysis/litter/chemistry_and_turnover

In retrospect I should've branched this off #104, instead of main? (@jacobcook1995 and @davidorme also please feel free to chip in, I'm still learning how to branch correctly).

[jacobcook1995]

Approach looks sensible to me. Agree that the below-ground results are a bit odd, but I wouldn't say that they are totally implausible either

[jacobcook1995]

In retrospect I should've branched this off #104, instead of main? (@jacobcook1995 and @davidorme also please feel free to chip in, I'm still learning how to branch correctly).

This really depends on how much complexity you want to deal with. You can definitely have structures where you merge smaller PRs into a feature branch (e.g. called something like feature/litter_model_improvements) and then once you've got everything you want into that branch merge it into main.

I personally find that kind of complexity hard to keep track of (particularly when you come back to branches after working on other things). So just pretty much always make new branches off the main branch, and then accept that I have to resolve merge conflicts as they arise, and that some PRs have to wait on other PRs being merged. (I tend to use git cherry-pick when it's imperative to have specific bits of code shared between branches)

[davidorme]

In retrospect I should've branched this off #104, instead of main? (@jacobcook1995 and @davidorme also please feel free to chip in, I'm still learning how to branch correctly).

I tend to use nested branches a bit more but it's really of most use when building up a big picture. I also use them if I'm suggesting a bigger change to someone else's PR - then you can say "hey - I think this nested PR would work better" without just replacing someone else's code.

[hrlai]

@annarallings this is ready for merging if it looks good to you :)