[gmao-qliu]

Adds exports needed to close the lake's water and energy budgets in post processing.

• PRLAKE, SNOLAKE: total precipitation and snowfall over lake tiles; snowfall needed to calculate extra fusion-heat term in energy balance.
• DHLAKE: rate of change of total lake heat content (similar to DHLAND/ECHANGE in Catchment GC).
• FRLAKEICE: ice fraction(FR(:, ICE)), needed to evaluate the fusion heat sink from exports alone.
• WNETFLUXLAKE: net water flux into lake (=precip-minus-evap). Same as "runoff" from Lake GC, but in Surface this diagnostic is averaged only over lake tiles

Tested with a 1-year GEOSldas offline simulation, and the annual energy and budgets based on lat/lon output are close to zero.
energy_balance: 0 = LWND + SWND - SH - LH - DHLAKE - MAPL_ALHF * (1. - FRLAKEICE) * SNOLAKE
water_balance: 0 = PRLAKE - EVAP - WNETFLUXLAKE

---

Balance computed from hourly averages:

---

Balance computed from daily averages (approximates fusion-heat term, where average of product is different from product of averages ):

[gmao-rreichle]

Thanks, @gmao-qliu, for putting this together! I made a few changes, consisting primarily of slightly changing/renaming the budget terms. I also added the exports into Surface, so they become available for GCM runs.
PRLAKE and SNOLAKE are meant to mirror PRLAND and SNOLAND from Catch.
Rather than use RUNOFF for the lake water budget, I added the same diagnostic with a different name that is (i) less confusing and (ii) does not interfere with the "runoff" diagnostic in Surface GC (which is averaged across land, landice, and lake).
Please take a look and let me know if you find anything wrong with my commits.

[gmao-qliu]

Rolf, I see you renamed runoff, precip and sno as WNETFLUXLAKE, PRLAKE and SNOLAKE. Other export variables don't have 'LAKE' in the name. I'd like to confirm that you prefer to keep 'LAKE' there?

…

-Qing

________________________________ From: Rolf Reichle ***@***.***> Sent: Friday, October 23, 2026 4:31 PM To: GEOS-ESM/GEOSgcm_GridComp ***@***.***> Cc: Liu, Qing (GSFC-610.1)[SCIENCE SYSTEMS AND APPLICATIONS INC] ***@***.***>; Mention ***@***.***> Subject: [EXTERNAL] [BULK] Re: [GEOS-ESM/GEOSgcm_GridComp] Add lake-specific exports to support Lake budget closure (PR #1553) CAUTION: This email originated from outside of NASA. Please take care when clicking links or opening attachments. Use the "Report Message" button to report suspicious messages to the NASA SOC. [https://avatars.githubusercontent.com/u/54944691?s=20&v=4]gmao-rreichle left a comment (GEOS-ESM/GEOSgcm_GridComp#1553)<#1553 (comment)> Thanks, @gmao-qliu<https://github.com/gmao-qliu>, for putting this together! I made a few changes, consisting primarily of slightly changing/renaming the budget terms. I also added the exports into Surface, so they become available for GCM runs. PRLAKE and SNOLAKE are meant to mirror PRLAND and SNOLAND from Catch. Rather than use RUNOFF for the lake water budget, I added the same diagnostic with a different name that is (i) less confusing and (ii) does not interfere with the "runoff" diagnostic in Surface GC (which is averaged across land, landice, and lake). Please take a look and let me know if you find anything wrong with my commits. — Reply to this email directly, view it on GitHub<#1553?email_source=notifications&email_token=AMWXGO7UVP6EKWHJNOP5Q4D5VO5YRA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMMZXGQYTENZWGQ4KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-6374127648>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AMWXGO4GKBZM4IDCASL66ND5VO5YRAVCNFSNUABFKJSXA33TNF2G64TZHMYTSNJUGE2DGNRSHNEXG43VMU5TKOJZHA2DAMZXGM42C5QC>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS<https://github.com/notifications/mobile/ios/AMWXGO52ZNKP2BC6IESGSUD5VO5YRA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMMZXGQYTENZWGQ4KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android<https://github.com/notifications/mobile/android/AMWXGOZBEJIVNPFBRQXXU2D5VO5YRA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMMZXGQYTENZWGQ4KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[gmao-rreichle]

see comment below

[gmao-rreichle]

I'm a bit confused why liquid water values for density (RHOWTR) and specific heat (CAPWTR) are used to determine the lake ice heat capacity. MAPL does have CAPICE here:

real, parameter              :: MAPL_CAPICE                    = 2000.                          ! J/(K kg)
real, parameter              :: MAPL_CAPWTR                    = 4218.                          ! J/(K kg)
real, parameter              :: MAPL_RHOWTR                    = 1000.                          ! kg/m^3

A quick internet search suggests a density of bubble-free lake ice around 917 kg/m3, which happens to be the value for sea ice in MAPL:

real, parameter              :: MAPL_RHO_SEAICE                = 917.0                          ! sea ice   density [kg/m^3]

For sea ice, the interwebs suggest a density of something like 910 kg/m3 and lower. I'm not an expert on lake or sea ice, and I don't know what's actually used in sea ice calculations, but at least for lakes there's probably some potential for improvement.

Having said that, the heat capacity used by the lake model includes a layer thickness ("depth") in the calculation, and the ice layer thickness value might have been calibrated to produce a lake ice heat capacity that worked in the GCM of yore.

cc: @lcandre2 @zhaobin74 @gmao-qliu @amfox37 @wmputman @biljanaorescanin

[lcandre2]

I think that you are correct, that the LAKEICECAP should use a ice density, not the water density. This issue also shows up in the Landice gridcomp calculation of LANDICECAP, which also uses water density, not ice density (~917 for land ice).

[gmao-rreichle]

Rolf, I see you renamed runoff, precip and sno as WNETFLUXLAKE, PRLAKE and SNOLAKE. Other export variables don't have 'LAKE' in the name. I'd like to confirm that you prefer to keep 'LAKE' there?

Including "LAKE" in the name is intentional. Without giving the export a lake-specific name, Surface will average over the same-name quantities from tile of other surface types (i.e., land and landice). E.g., to get just land precipitation from Catch, we have an export called "PRLAND".

[gmao-rreichle]

@gmao-qliu : One more thing:

In the intro comment, I changed the fusion heat term in the balance equation to the following:

MAPL_ALHF * FRLAKEICE * SNOWF

Before it was

MAPL_ALHF * (1 - FRLAKEICE) * SNOWF

which seemed wrong. Was this a typo in the original comment, or am I missing something?

[gmao-qliu]

@gmao-qliu : One more thing:

In the intro comment, I changed the fusion heat term in the balance equation to the following:

MAPL_ALHF * FRLAKEICE * SNOWF

Before it was

MAPL_ALHF * (1 - FRLAKEICE) * SNOWF

which seemed wrong. Was this a typo in the original comment, or am I missing something?

The original should be correct because the snow fusion heat term applies only to the water subtile (1-FRLAKEICE).

[gmao-rreichle]

The original should be correct because the snow fusion heat term applies only to the water subtile (1-FRLAKEICE).

Thanks, I see now. This is for snow falling on the unfrozen lake portion! I restored the original equation in the comment.

[gmao-rreichle]

@lcandre2 : If I'm reading this correctly, only the top layers of snow and ice are included. Shouldn't the total energy in the system be computed from all layers? Unless layers 2:N are not connected to the rest of the system, using just the top-layer wouldn't close the budget, I think.

[lcandre2]

We normally do only the top layer -- my plan is to include both. Currently getting this to work.