Enthalpy fluxes from CAM

[wwieder]

CAM will be passing enthalpy fluxes associated with precipitation. I'm pasting notes from the 2022 discussion that @dlawrenncar and @olyson had with Peter Lauritzen on this topic. For CESM3, I suggest use a fixer to balance energy fluxes in CESM, but additional options are below. Regardless this seems to need attention from CTSM for CESM3 development.

---

Option 1: An energy flux term, calculated in the coupler based on TBOT and the mass of precipitation, is sent to the land model.

We were thinking about accounting for this energy flux by adding it to the ground heat flux in the land model. But, unless we are missing something, this flux would always be positive, at least for rain - whether it is warm or cold rain. So, this would always warm the top soil layer, which I don't think is what would happen in the real world. Seems like at the very least, you would need to consider the temperature of the top soil layer vs the temperature of TBOT to calculate whether or not the energy flux into the soil should be positive or negative. Not really sure how or whether it makes sense to do that, but even if you did do that we started to realize that regardless, you probably need to account for the enthalpy flux from soil layer 1 to soil layer 2. And, you would need to account for the enthalpy flux associated with plant transpiration. Presuming you could calculate the mean temperature of the water lost through transpiration, where would that flux be accounted for.

Option 2: Pass the temperature of the precipitating water to the land

In this option (ignoring challenges associated with canopy interception and surface runoff), we would update the soil temperature of layer 1 by calculating the mass-weighted average temperature of the soil/soil-water with that of the precipitating water that infiltrates into the soil. That would at least give the intuitive result that precipitation that is colder than the soil temperature would cool the soil and precipitation that is warmer than the soil would warm the soil. But, I think there is the same question about what happens with the transpiration (or soil evaporation) water. And, the fact that we aren't tracking the transfer of heat as water filters down into the soil is also likely a problem (though maybe (???) one we can live with).

If we could resolve this overarching question about how to deal with the enthalpy flux associated with evaporation, then there are a host of other challenges related to runoff (surface and subsurface), canopy interception, land surface type heterogeneity, etc, that we might be able to sort out ... but might not.

We are not really sure how to proceed. We were talking ourselves into pretzels trying to figure this out. One thing that might be a little bit helpful (not sure if it WILL be helpful or not) would be a more detailed explanation of what is or will be happening over the ocean. How exactly with the precipitation enthalpy flux and the evaporation enthalpy flux be handled for the ocean. Maybe with that information, we will have better understanding.

So, we intend to keep talking about this, maybe with a slightly larger group of land people. We are concerned that our pretzel conversation (only partially captured with the above) might have gone off the rails and that we are missing something simple. But, the outcome of our conversation is that without moving to an enthalpy-centered formulation of the model, it may be quite difficult to implement even a kludgy fix, though we are still open to more ideas coming in.

[ekluzek]

@wwieder I'm thinking if CAM is properly dealing with enthalpy fluxes it by definition means that they are modeling the Temperature of precipitation. Option 1 is an approximation that we could put in place now to start to work this out. But, I don't think it's what you really want. Precipitation is likely to be a different Temperature than TBOT so I'm not sure you get much out of it other than a starting point to start bringing this into the model.

[ekluzek]

Inherently accounting for ALL the effects of this will be complex. So we should start deciding what things we are going to ignore as we start this. I'd propose that we ignore heat transfer into vegetation, and only consider soil. I think we also don't consider temperature of runoff or water in soil. If we explicitly decide what effects we are going to model and which to ignore to start with, we can implement the simplest most important ones, and then add other effects in time. A question is there research that shows which of these effects are most important? And of course another problem is that this is somewhat of an unfunded mandate but something that will need extensive scientific research resourcing so it's pretty limited what we can actually accomplish.

[wwieder]

Thanks for these thoughts @ekluzek . You're right, we don't have anyone funded to address this. It's also not your issue to solve. At this point I suggest we work with CAM developers to come up with the simplest 'fixer' to address this issue but not spend much time / energy on this in the short term (if possible).

[billsacks]

@wwieder - How sure are you that this is actually something that's needed for CESM3? I have a vague recollection that, when this came up a few months ago, the ocean & atmosphere groups were satisfied with the current state for now, where this is dealt with more rigorously for atmosphere-ocean fluxes, but where we don't try to do anything on the land side for now. My vague recollection is that the errors from the land piece of this are relatively small and there is already a fixer in place to account for these errors. I could very well be remembering wrong, but I want to make sure this is truly an important issue to solve for CESM3.

[wwieder]

I thought the same thing until co-chairs yesterday when our friends from the OMWG inquired about this and asked about our plans for balancing the model's energy budget? Gokhan seemed fine with a quick 'fixer', but I don't honestly know what that means. I am also advocating for this quick fix for CESM3, but raised this issue because I don't know what that quick fix even looks like or how to implement it?
This last line from the notes I pasted above makes me concerned But, the outcome of our conversation is that without moving to an enthalpy-centered formulation of the model, it may be quite difficult to implement even a kludgy fix, though we are still open to more ideas coming in.

[billsacks]

Yeah, I think we need to have a more in-depth conversation with members of the OMWG before spending more time on this.

[wwieder]

@gustavo-marques and @cecilehannay is the land-enthalpy fixer you currently have implemented adequate for CESM3?

[gustavo-marques]

We do not have a "land-enthalpy fixer" implemented -- the enthalpy associated with the mass sent to the land model is not accounted for at this time. We only account for the enthalpy to/from the ocean model. cc'ing @PeterHjortLauritzen

[gustavo-marques]

The current out-of-the-box implementation will be modified in the coming days - we need to use the temperature of the lowest ATM level, instead if SST, in the calculation of the enthalpy due to rain and snow.

[wwieder]

OK, maybe I'll try asking this a different way. Are enthalpy fluxes being passed to the ocean (e.g. implicitly from runoff) adequate for the OWMG's needs in CESM3?

[gustavo-marques]

Sorry, I misinterpreted your previous question. Yes, the coupler computes the enthalpy fluxes due to liquid and frozen runoff and sends them to the ocean -- and that's what OMWG needs for CESM3. Ideally, the coupler would receive the temperature associated with each of these terms, but we know this is not going to happen in the near future. Therefore, we are currently "guessing" these temperatures. For liquid runoff, we assume the temperature of the water to be max(SST, 0.0 C). For frozen runoff, the assumed temperature is min(SST, 0.0 C).

[wwieder]

OK, I'm taking from this thread that it would be better to pass river water and ice temperatures to the ocean. This is not something we can support with MOSART. It's also a feature we'd like to build into MizuRoute, but that's not ready to go yet either. For now, I suggest we close this issue with a won't fix (for the CESM3 development timeline)?