Count energy of water in lakes in total gridcell heat content

[billsacks]

From @billsacks on March 11, 2017 22:48

We should eventually count the energy of water in lakes in the total gridcell heat content - but probably shouldn't do this until we're counting the lake water in the total gridcell water content. More details below:

Lake water has an explicit temperature, so it can be counted in the total gridcell heat content like this (code excerpted from dyn_heat_content in dynConsBiogeophys.F90):

       !--- heat content, below ground in lake water, for lakes ---
       do k = 1,nlevlak
          if (lun%itype(l) == istdlak) then
             cv = denh2o*col%dz_lake(c,k)*( lakestate_inst%lake_icefrac_col(c,k)*cpice + &
                  (1 - lakestate_inst%lake_icefrac_col(c,k))*cpliq )
             heat = heat + cv*(temperature_inst%t_lake_col(c,k) - tfrz) + &
                  hfus*denh2o*col%dz_lake(c,k)*(1._r8-lakestate_inst%lake_icefrac(c,k))
          end if
       end do

However, the water content is fixed, and so in some senses is virtual. Thus, we are not including this lake water state in the counting of total water content, if lakes shrink with dynamic landunits. Therefore, it is problematic to include the energy content: If a glacier rolls over a lake, then the model will see a huge loss of energy (the energy content of the lake water), which it needs to compensate with a huge sensible heat flux. (For other water losses, the energy from the lost water will be accounted for via a new scheme we're putting in place - associating an energy with the dynbal water flux. But there is no dynbal water flux for the virtual lake water.)

Since we currently can't have lake creation, I think it's okay to just assume that energy gets buried forever - i.e., not counting it in the dynbal heat content. Once we have dynamic lakes, presumably the water will become real water rather than virtual water, and so we can include both the water and the heat of that water in the dynbal checks.

Copied from original issue: NCAR/CLM#2

[billsacks]

cc @olyson

[billsacks]

cc @dlawren

[billsacks]

Speaking with @Ivanderkelen , who is implementing dynamic lakes: We have decided that she's going to try including the lake water content to both the total gridcell water/ice content and the total gridcell heat content. However, because this water content is in some sense virtual, she's going to take the same approach that we currently take for glaciers: Namely, setting baseline values in initialization, and then subtracting these baseline values from the current values. Once these baselines are subtracted, the dynbal liq/ice terms for dynamic lakes shouldn't differ much from current values (because we're adding the current lake liq/ice, but then subtracting the same amount via the baseline correction). The dynbal heat term should still be small, but now will account for any heat gained / lost by/from the lake since initialization.

In terms of calculating the baseline values: we think it's best to just include the lake water itself - NOT the soil under the lake, and NOT subtract the vegetated column's initial state as is done for glaciers. (This is because lakes already have explicit soil under them, unlike glaciers in the model, so the reasoning for subtracting the vegetated column's initial state doesn't apply here.) To avoid code duplication, it may be best to have new routines in TotalWaterAndHeatMod that just count the water/ice or heat in the lake water itself (somewhat analogous to AccumulateSoilLiqIceMassNonLake and AccumulateSoilHeatNonLake, but now for lake water rather than soil water); these new routines would be called from both ComputeLiqIceMassLake/ComputeHeatLake, and from dyn_water_content_set_baselines/dyn_heat_content_set_baselines. But given the relative simplicity of these routines, it may be okay to just have a bit of duplicated code inline in both ComputeLiqIceMassLake/ComputeHeatLake and dyn_water_content_set_baselines/dyn_heat_content_set_baselines

One other point: I think we want to remove the subtract_dynbal_baselines argument from ComputeLiqIceMassLake, ALWAYS subtracting these baselines. I'm pretty sure that it doesn't make a difference right now, but that that would be needed in order to maintain the current behavior of TWS for methane (see #659). (For non-lakes, the old behavior involved not subtracting the baselines. For lakes, in contrast, the old behavior involves not adding the lake state in the first place - which is equivalent to adding the lake state but then subtracting the baseline state.)