Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update glc coupler budgets for active Greenland ice sheet [DRAFT] #6634

Draft
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

stephenprice
Copy link
Contributor

This DRAFT PR adds functionality to coupler budget code so that x2g_ and l2x_ fields associated with Greenland ice sheet surface mass balance are accounted for in the coupler budget tables. Also added, but currently passing fields of zeroes, is support for g2x_ fields associated with iceberg fluxes when running with a dynamic Greenland ice sheet. Additional information for testing this PR is included in the notes below.

Update various bits of code needed for completing and testing of glc
coupler budgets. Still very much in the testing and debugging phase.
Code additions and debugging for addition of Greenland surface
mass balance terms to glc budget code, including temporary lines
for debugging and validation.
… component

Given known number of time steps smb flux is accumulated over, x2g_ smb
flux term in budget table now agrees with value calculated from mali and
cpl hist files (still need to add support for automatically determining
number of averaging steps).

Similar support on l2x_ side is close (summing product of accumulation
fluxes in different MECs w/ area fractions and cell areas) but off in
budget tables from cpl calculated values by ~5%.
Checkpointing changes to coupler budget code that accounts for
l2x_ and g2x_ Greenland surface mass balance fluxes, with various
lines supporting debugging outputs included. Cleaned up code
without debug lines to follow.
Clean up commenting and debugging lines, leaving bare minimum
needed to make draft PR understandable.
@stephenprice
Copy link
Contributor Author

Status summary and instructions for testing:
For fluxes related to surface mass balance and for simulations of 1 day duration only, l2x_ and x2g_ fields in the coupler budget tables "close" to within approx. 5-10%. A hypothesis is that the remaining 5-10% difference is due to the fact that fluxes on a sphere (from lnd / clm) are being mapped to a planer mesh (to glc / mali). Below is an example from a 1 day BG test case (details for recreating this included below):

Screen grab of budget table for net water budget with Greenland SMB-related fluxes in the "wgsmb" row:
Screenshot 2024-09-20 at 1 12 31 PM

The values in the table can be compared with values collated from the mali and coupler history files. The grab below shows output when applying an NCO script to do that (see below) to the cpl hist files from this 1 day BG case. This script pulls out the relevant coupler hist. vector, multiplies it by the relevant areas, sums the product, and then normalizes by earth surface area (approximately) to provide a value that can be compared to budget table values.

Output from NCO script to sum relevant fields from coupler history files:
Screenshot 2024-09-20 at 1 12 49 PM

The first three values are on the x2g_ side and represent (in order) 1) the summed flux from mali history files, 2) the summed flux from cpl hist files for x2g_Flgl using "model areas" and 3) the summed flux from cpl hist files for x2g_Flgl using "mapping file areas".

The last two values are on the l2x_ side and represent (in order) 1) the summed flux from l2x_Flgl using "model areas" and 2) the summed flux from l2x_Flgl using "mapping file areas" (identical).

Note that the latter two, when multiplied by the SMB renomalization factor listed in the coupler budget table (here, 0.8823), give a value (0.0125e-6) very close to the value provided in the wgsmb row and lnd column of the coupler budget table (0.0129e-6).

Remaining issues

  1. Currently, the x2g_ values in the coupler history file only work correctly for a run of 1 day. This is because the local coupler vector these fluxes are collected in represent an average value rather than a summed value (even though the 'acc' in the vector name, x2gacc_Flgl, implies 'accumulation' or summation). Thus, to recover the summed value, this vector must be multiplied by some number of time steps (here, the no. of lnd model steps in a day, 48). This value can be recovered using a counter (hack in current code) but something more robust is needed to account for runs of multiple days or longer. Similar sections of the budget code don't appear to have this problem and/or it is accounted for automatically.
  2. The discrepancy between the l2x_ (from lnd to coupler) and x2g_ (from cpl to glc) values in the table may be due to the spherical vs. planer mapping issue noted above. This may be treatable by the use of a specially generated mapping file (?) or something other correction factor applied within the code. This requires more discussion to decide on a solution.

Scripts to recreate run and cpl hist file analysis
A copy of the script to set up the relevant 1 day BG case can be found here:
/home/ac.sprice/e3sm_cases/BGelm.chrys.bash

It requires updating of a few shell / path variables at the top.

A copy of the script to sum and normalize fluxes from mali and cpl history files can be found here:
/lcrc/group/e3sm/ac.sprice/scratch/chrys/20240920.BGWCYCL1850.ne30pg2_r05_EC30to60E2r2_gis20.chrysalis.gnu.CplBudgetDevel/run/calcBudgetsFromHistFiles.sh

If placed in the relevant "run" directory, it requires only that the name of the relevant 1 day mali and cpl hist files be updated at the top of the script.

@rljacob
Copy link
Member

rljacob commented Oct 31, 2024

Notes: Jon has been meeting with Steve about this. Will test more for impact when no glc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants