Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create skinny topsoil layer for calculation of temperature and matric potentail at depth of microbial activity #535

Open
vgro opened this issue Aug 1, 2024 · 5 comments

Comments

@vgro
Copy link
Collaborator

vgro commented Aug 1, 2024

Is your feature request related to a problem? Please describe.
The depth of microbial activity does not necessarily align with the depth of the soil layers in the shared LayerStructure, see #348 . The soil and litter model therefore need to get a weighted average between soil layers, see #532 . If the microbial activity falls above the depth of the topsoil layer, there needs to be an interpolation between the surface and the depth of the first deeper layer.

The litter model currently implements a version of that which puts a constant value as the upper boundary condition; this issue asks for the roll out to the whole model. This links to updating the infiltration process #494 but could be done in two steps.

Describe the solution you'd like
Add a skinny soil layer, maybe 2-5 cm below ground, to default layer structure and update all models. For the infiltration process, the intermediate solution is to take the depth of the first two layers.

Describe alternatives you've considered
We also considered an above ground layer as an upper boundary (as this is also used in the litter model), but this became a bit tricky with the matric potential. However, it would be interesting in the future to think about litter moisture content or relative humidity in litter layer when it comes to flammability and simulations or fires.

@jacobcook1995
Copy link
Collaborator

One thing to add, the current setup that I'm working towards for the matric potential averaging will interpolate all of the soil layers apart from the top one. For the top one it just uses the value at the layer depth. This is obviously a bad assumption for a 50cm thick layer buts probably fine for a very thin layer. Main reason to mention this is that I think this means that there won't need to be any changes on the litter/soil model side once this skinny layer is implemented

@davidorme
Copy link
Collaborator

I don't completely get this. At the moment, we can configure any number of layers we want in LayerStructure and they can be of any thickness. So we could just switch the default to [0.05, 0.45, 0.5] and then we have a skinny top soil layer to roll out through the models. But is this a deeper change about the definition of what gets indexed by LayerStructure.topsoil - do we have more than one soil surface layer definition to support?

@vgro
Copy link
Collaborator Author

vgro commented Aug 1, 2024

no you are correct, this is not a difficult thing to add to the default ( it just needs to be done, hence the issue).
The only slightly more challenging thing is the calculation of surface runoff where we want the topsoil to be deeper than a few cm, but could you be set top the depth of the second layer, which needs to be accessed in a clever way.
So nothing fancy, we just thought it would be better treated separately from the litter PR just in case it reveals some unexpected challenges ;-)

@davidorme
Copy link
Collaborator

Sounds good. I'm wondering if there is any mileage in defining the soil layers purely in terms of depths of particular processes:

  • skinny topsoil 5cm deep
  • surface runoff 10cm deep
  • biologically active soil 50cm deep
  • subsoil depth 150cm

That gives us soil layer depths in metres of [0.05, 0.1, 0.5, 1.5]. Is there any need to allow users to subdivide soil layers beyond those process driven depths? We'd generate indices to access the appropriate set of layers for each process. The order of them could in theory swap too.

@vgro
Copy link
Collaborator Author

vgro commented Aug 1, 2024

I'll have a think about this, at the moment it has mostly to do with the soil hydrology. For that I don't see why we should not define the core set by functionality.
For temperature it does not matter at the moment, if we wanted more layers they could be at the same depths

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants