Subtract dynbal baselines from begwb and endwb #659
Comments
billsacks
added
enhancement
Ideally, we would keep begwb and endwb consistent with liq1, liq2, ice1 and ice2 in this respect - i.e., subtracting the dynbal baselines in all cases. However, this changes answers for methane in a way we want to avoid right now. See ESCOMP#659 for details.
|
See 366ddd6 for the commit that should eventually be backed out. |
Ideally, we would keep begwb and endwb consistent with liq1, liq2, ice1 and ice2 in this respect - i.e., subtracting the dynbal baselines in all cases. However, this changes answers for methane in a way we want to avoid right now. See ESCOMP#659 for details.
Ideally, we would keep begwb and endwb consistent with liq1, liq2, ice1 and ice2 in this respect - i.e., subtracting the dynbal baselines in all cases. However, this changes answers for methane in a way we want to avoid right now. See ESCOMP#659 for details.
ekluzek
added
the
next
billsacks
added
blocked: dependency
billsacks
removed
the
next
|
With #1109 there is another (large) change in TotalWaterAndHeatMod that would impact begwb, endwb and TWS: lake water is now counted in these. For similar reasons to above, this leads to problematic changes in TWS until #658 is resolved. In general, I think that the addition of lake water would be balanced by the subtraction of baselines (as long as the baselines are established correctly), since the baselines should have the same amount of lake water as the current conditions for each lake column. However, as noted above, we currently are not subtracting baselines when computing begwb and endwb. In addition, I believe there is another issue with adding the lake water without subtracting baselines: this makes the begwb and endwb terms larger by at least a few orders of magnitude; this, in turn, leads to less precision when calculating (endwb - begwb) in this code: CTSM/src/biogeophys/LakeHydrologyMod.F90 Lines 676 to 678 in 3ae614b For both of these reasons, I think we want to avoid adding the lake water/ice content to begwb/endwb until we also switch to subtracting baselines from those terms. My plan is to change the name of the relevant subroutine argument from |
Dynlakes: fix some subtle issues ### Description of changes Fix a variety of subtle issues with dynamic lakes - particularly the accounting of total water and energy. ### Specific notes This branch contains the following commits: - a9fa875: This is needed to avoid counting lake water in the begwb and endwb terms, which is needed because these are used to calculate gridcell total water store (TWS), which in turn influences the methane code. Because the methane code was tuned around old values of TWS, changing TWS would lead to unintentional – and potentially large – changes in methane terms. Eventually we'd like to remove methane's dependence on TWS, but for now this workaround is needed to avoid changing behavior too much. See ESCOMP#659 (comment) for more details. - 52105c4: This minor fix is needed for the sake of water tracers / water isotopes. It shouldn't have any impact outside of that (because the tracer_ratio of bulk water is 1) - de3e12c and acf0984: This one is especially subtle; it is needed for backwards compatibility with old restart files. The main changes are in de3e12c; acf0984 is just a minor tweak on top of that. The problem is that, on existing initial conditions files, there can be already-existing DYNBAL_BASELINE variables (for LIQUID, ICE & HEAT). But these pre-existing variables will have baseline values of 0 for lake. Before this commit, when you started up from an old initial conditions file, the code would use these 0 values for lake baselines (because baselines are only reset if the user explicitly asks them to be reset with a namelist flag). This commit adds some code to detect if the initial conditions file is old, and if so, recomputes dynbal baselines for lake using the new definition. Note that some even older initial conditions files didn't have the DYNBAL_BASELINE variables at all; those would have been okay before this change: the problem is with initial conditions files that are somewhat but not very old - so have DYNBAL_BASELINE variables on them that use the old definition (where lake baseline values were 0). - 8088c3c: Minor fix for a pre-existing issue - a31875d: I'm not sure if this is actually needed, but I thought it would be good to group together the lake water content and the roughly equal-but-opposite baselines, so that these can cancel to near zero before adding the smaller terms. In principle, this should help maintain precision in these smaller terms. I thought this might help resolve some of the larger-than-expected answer changes I was seeing in testing, but I don't think it actually does... but I still thought this would be good to keep in place. **I have double and triple checked these changes, but it would be good to have an extra set of eyes on them to make sure I did this reordering correctly. In particular, I think there were some subtleties about when a term should accumulate on top of an existing value vs. setting the initial value of a variable.**
In a branch that I'll soon bring to master, I'm subtracting baselines from the calculation of total column water and heat when computing budgets before and after dynamic landunit adjustments. However, I am currently NOT subtracting these baselines when computing begwb and endwb for the sake of water balance checks - and also for the sake of TWS, since TWS is computed based on endwb.
It would be better if these different calculations of column-level water were consistent, always subtracting these dynbal baselines (
dynbal_baseline_liq_colanddynbal_baseline_ice_col). However, this changes answers by more than we'd like right now, presumably due to methane's dependence on gridcell TWS (see #658 - this subtraction of baselines should only change answers for glacier columns, but this can affect non-glacier columns due to the dependence on gridcell average TWS). We want to avoid these answer changes on the release branch, and if possible also on master (partly to keep master consistent with the release branch in this respect for now, and partly because master still may be used in some runs that extend cmip6 runs, adding water isotopes).Once it's okay to change answers on master - and/or once #658 is resolved so that methane no longer depends on gridcell TWS - we should clean this up, always subtracting these dynbal baselines in the calculations of total column water.
The text was updated successfully, but these errors were encountered: