Versions Compared

Old Version 7

changes.mady.by.user Stephen Price

Saved on

compared with

New Version 8

changes.mady.by.user William Lipscomb

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The GLC model receives surface temperature and surface mass balance from the LND model.  These fields are passed from LND to the coupler on the land grid in each of N elevation classes (where typically N = 10), and then are remapped by the coupler to the ice-sheet grid before being passed to GLC.  This coupling was implemented in CESM for CISM and is available to ACME via CIME. The CISM-CESM coupling also included liquid and solid runoff from the ice sheet model, which while not . GLC returns ice fraction, surface elevation, and upper surface heat flux to the coupler, and coupler remaps these fields to the land grid and elevation classes before sending them to LND.  In addition, GLC passes liquid and solid runoff to OCN (WHL: or ICE?) via the coupler, but this document focuses on the GLC-LND coupling. ... SOMETHING MISSING HERE?  

This GLC-LND coupling is also considered here. This functionality needs to be reproduced for MPASLI in ACME.

Requirements

The implementation of what CISM's GLC requires to work with the GLC-LND coupling in CIME can largely be seen in the GLAD modules created by Bill Sacks (Unlicensed) in CISM: https://github.com/ACME-Climate/cism-piscees/pull/35


Requirement: Fields from coupler to GLC

Date last modified: 2015/09/21
Contributors: Matt Hoffman, Bill Sacks (Unlicensed), Jeremy Fyke (Unlicensed), William Lipscomb (Unlicensed)


The GLC component receives fields from the LND model via the coupler:
  1. qsmb - surface mass balance of glacier ice (kg/m^2/s)
  2. tsfc - surface ground temperature (deg C)

Starting with CIME, the coupler does downscaling so these fields are on the GLC grid. 

In order for the coupler to return correct values of these fields, GLC must pass to the coupler gtopo and ice_covered.  MJH: I'm guessing about this - is this correct?  WHL: For conservative two-way coupling, this is correct. When CISM is run diagnostically with LND->GLC coupling only, the land model does not use gtopo or ice_covered, but I think the coupler will still want this information.   Bill Sacks (Unlicensed), can you confirm?


Requirement: Fields from GLC to coupler

Date last modified: 2015/09/21
Contributors: Matt Hoffman, Bill Sacks (Unlicensed), Jeremy Fyke (Unlicensed), William Lipscomb (Unlicensed)

The GLC component needs to pass fields to the coupler:

  1. gtopo - surface elevation of each GLC grid cell (m) (state: current snapshot) 
  2. ice_covered - whether each grid cell is ice-covered [0,1] (state: current snapshot?) SFP: Clarify if 0,1 are the only options or if a fractional value allowed?  WHL: For GLC -> LND coupling, the values on the GLC grid (in principle) can be any number from 0 to 1, but CISM currently assumes that any ice-sheet grid cell has full or zero coverage.  Does MPAS LI make the same assumption?
  3. hflx - output heat flux (W/m^2, positive down) (flux: time-average) MJH: Is this at the ice sheet-atmosphere boundary? SFP: This is computed in the coupler? It's not computed in the ice sheet model. WHL: From the ice-sheet point of view, this is the conducted heat flux at the upper surface. It is computed in CISM and (hopefully soon) will be computed in MPAS LI as part of the thermal calculation. From the land point of view, it is the heat flux at the base of the ice column and is treated like a geothermal heat flux. This flux is desirable for energy conservation but is not large, so I don't thing it's critical to include it.
  4. rofi - output ice runoff (kg/m^2/s = mm H2O/s) (flux: time-average) (This is not a LND coupling, but including it here as it also needs hooking-up.)  MJH: This is sent to OCN model, correct? WHL: Correct.
  5. rofl - output liquid runoff (kg/m^2/s = mm H2O/s) (flux: time-average) (This is not a LND coupling, but including it here as it also needs hooking-up.) MJH: Is this sent to the ROF or the OCN model? WHL: OCN.
  6. ice_sheet_grid_mask - mask of ice sheet grid coverage (state: current snapshot?)  MJH: how does this differ from "ice_covered"?  WHL: This mask describes the ice-sheet grid, or the set of locations where land ice may or may not be present, whereas "ice_covered" indicates where ice is currently present.
  7. icemask_coupled_fluxes - mask of ice sheet grid coverage where we are potentially sending non-zero fluxes (state: current snapshot? or consistent with the flux fields?) MJH: is there a more complete description of what this means?

These fields need to be accumulated/averaged properly over the coupling interval by GLC.  MJH: Which ones should be averaged vs. using a snapshot of the final time in the coupling interval? WHL: The rofi and rofl fluxes sent to OCN, along with hflx sent to LND, need to be averaged properly.  The states gtopo and ice_covered would be snapshots, I think.

Note that gtopo and ice_covered need to be updated in a TG run for qsmb, tsfc from the coupler to be correct (i.e., updated in time as the ice sheet evolves SFP: does this require dynamic land units then?).  However, those fields are not actually passed on to the LND model as in an IG/BG run.  In contrast, ice_covered is sent back to the LND model to determine where SMB calculations occur.  MJH: I'm guessing about this - is this correct?  WHL: In a TG run, LND is a data model and has no use for gtopo or ice_covered. Bill Sacks (Unlicensed), can you comment on whether the coupler in a TG run requires info from GLC?

Algorithmic Formulations

Design solution: short-description-of-proposed-solution-here

Date last modified:// date
Contributors: (add your name to this list if it does not appear)

 

(Not sure this section is necessary for this as this should be a relatively straightforward software engineering problem.)

Design and Implementation

Implementation: short-desciption-of-implementation-here

Date last modified: // date
Contributors: (add your name to this list if it does not appear)

 

(Leaving this partially blank for now until requirements are more fully understood.  My intent is to get a TG case working first, than move to IG.)

 

Planned Verification and Unit Testing 

Verification and Unit Testing: short-desciption-of-testing-here

Date last modified:  
Contributors: (add your name to this list if it does not appear)

 

How will XXX be tested? i.e. how will be we know when we have met requirement XXX. Will these unit tests be included in the ongoing going forward?

SFP: not sure what a unit or verification test would look like for coupling. Anyone?



Planned Validation Testing

Validation Testing: GLC-LND coupling

Date last modified:2015/09/21
Contributors: Matt Hoffman, Jeremy Fyke (Unlicensed), William Lipscomb (Unlicensed)


Testing will be a sanity check of the MPASLI field sfcMassBal as output from a TG and an IG run.  MJH: Do we want something more substantial than this??
 

SFP: I suggest that the validation test here is, at least for now, an eyeball norm against some previously accepted solution (E.g. RACMO or some prev. version of CESM calc. SMB over Greenland). We could make this more quantitative by suggested a total integrated SMB we want to match (e.g. in Gt / yr) +/- some error range.


Planned Performance Testing 

Performance Testing: short-desciption-of-testing-here

Date last modified:
Contributors: (add your name to this list if it does not appear)

 

How will XXX be tested? i.e. how will be we know when we have met requirement XXX. Will these unit tests be included in the ongoing going forward?

 

...