ESCOMP / CTSM

Community Terrestrial Systems Model (includes the Community Land Model of CESM)
http://www.cesm.ucar.edu/models/cesm2.0/land/
Other
302 stars 307 forks source link

Calculate explicit fluxes in the course of solving the Richards equation #964

Open billsacks opened 4 years ago

billsacks commented 4 years ago

The solution of the Richards equation in SoilWaterMovementMod is problematic for water tracers / isotopes: This calculates a redistribution of water between layers and adjusts the states without ever calculating explicit fluxes.

From a discussion with @davidnoone in June, 2017:

Problem: Richards equation: Ideally, this would produce explicit fluxes between components and then apply those fluxes to update the states. But right now that doesn't happen: The solution of the Richards equation updates the states directly, and it's hard (or impossible) to infer the fluxes from there. So for now [referring to the CLM40 isotope implementation], they re-call the Richards equation solving code on the isotopes, even though they'd really like to apply the existing bulk fluxes to the isotopes.

Ideal solution: Have the solution of the Richards equation compute explicit fluxes. Those fluxes would be used to update the state (and if there are any corrections to the fluxes needed to – e.g., – maintain non-negative states, then those corrections would be applied directly to the fluxes). Those same fluxes could then be used to update the isotopic states.

@djk2120 points out some additional issues with respect to transpiration, which I think are related to this:

Hydraulic redistribution is an emergent behavior of the root water uptake when PHS is on. So there is no special HR code, but rather the PHS code will feature HR under certain conditions (e.g. at night time during a drought).

The specific code that governs this is L313-314 of SoilWaterPlantSinkMod.F90

temp(c) = temp(c) + k_soil_root(p,j) * (smp(c,j) - vegwp(p,4) - grav2)* patch%wtcol(p)

which is accumulating the column root water uptake for a given soil layer ( j ) within a loop over the various PFTs, which will eventually be written to qflx_rootsoi_col(c,j)

When there is HR, the values of qflx_rootsoi_col(c,j) will be positive for certain of the soil layers (and negative in others). This is driven by whether smp(c,j) is greater than or less than vepwp(p,4). (In SMS, this is disallowed and qflx_rootsoi_col values will always be either negative or zero). In the case of HR we are taking water from the places qflx_rootsoi_col is negative and depositing wherever qflx_rootsoi_col is positive, and potentially also sending some of the negative water out through the leaves for transpiration. At this point there is no need to exactly define which water goes where, which I imagine will be an issue with the isotopes. E.g. soil layers 5,6,and 7 are where there is root water uptake and send half the water to layer 2 and half of it out the leaves (non-specific) as compared to layer 5 sends its water to layer 2, and transpiration is supplied from layers 6 and 7 (specific accounting).

We could certainly develop a heuristic for sorting this out (such as mixing the water), but in reality this may venture beyond a software question into being an actual science question.

My very vague understanding of this is that the redistribution within the soil mentioned by @djk2120 is tied in with the general Richards equation issue, but @djk2120 is pointing out some additional potential issues with respect to transpiration: we'll also need to know the explicit source(s) for that flux.

billsacks commented 4 years ago

I just found this note from our software meeting June 23, 2017:

Having explicit fluxes computed as part of solving Richards equation would help with isotopes – i.e., separating flux calculation from state update here. Is this part of the plan? If not, how hard would this be?

  • It sounds like there is already something like this, but maybe not exactly what he needs???

That last line makes it sound like there may already have been some work to calculate explicit fluxes since CLM4.0, but I'll need to find out more details.

billsacks commented 2 years ago

See also some discussion in #518 that may be relevant to this issue. e.g., see https://github.com/ESCOMP/CTSM/issues/518#issuecomment-938991932

billsacks commented 2 years ago

This issue also came up today, connected with a possible desire to improve conservation across CESM through a more rigorous treatment of enthalpy fluxes. In particular, it was pointed out that a transfer of water from one soil layer to another is not currently associated with a transfer of the corresponding heat. It sounds like doing that heat transfer correctly / rigorously is also made harder because we don't have explicit fluxes. So having explicit water fluxes in the solution of the Richards equation would help with energy conservation as well as isotopes and other water tracers.

(@dlawrenncar and @swensosc please correct me if I'm saying something wrong here.)

billsacks commented 1 year ago

@nusbaume mentioned to me that there are similar issues in the atmosphere, related to water transport between atmospheric levels, e.g., in the convection scheme. You either need to run the transport equations again (which maybe is not too bad if you have an array of water states that you loop through) or output a bunch of additional information so that you can apply fluxes to the isotopes. Part of the challenge in the atmosphere is that many of the relevant schemes are developed and maintained by external groups. In any case, the atmosphere and land groups could maybe learn from each other here.

wwieder commented 1 year ago

Should this issue be closed, as we don't have resources to accomplish this and aren't supporting water isotopes in CESM3 (or am I'm mistaken)?

billsacks commented 1 year ago

I'd say keep this open at low priority. My understanding is that there is some effort to pursue getting funding to get water isotopes throughout CESM – with the main work needed in CTSM and CAM – so I'm reluctant to completely close out the remaining water isotope-related issues - but getting this done for CESM3 seems exceedingly unlikely at this point.