ASIS:Gcm coupling

GLIMMER - FAMOUS coupling
Existing coupling, as documented by Jonathan Gregory et. al. August 2008.

Date: 2008-08-14 12:13 +0100 From: Jonathan Gregory  To: "AJ Payne, Geographical Sciences" , V.Lee@bristol.ac.uk, pahol@bas.ac.uk, rcah@bas.ac.uk, jeff.ridley@metoffice.gov.uk, jason.lowe@metoffice.gov.uk Cc: o.j.h.browne@reading.ac.uk Subject: Glimmer-FAMOUS interface

Dear Tony et al.

This is the Glimmer interface currently used by UM-Glimmer coupling, described with help from Oli. When we last met I said I'd summarise it, because we decided to stick to this or something like it for future developments. Sorry it took me a while to get round to doing it.

The organisation into separate instances is largely hidden in the API. However we have to intervene directly in the instances for some purposes, as described below.

At the start of the UM run:

type(glint_params)::ice_sheet

type(ConfigData)::xtr_configs

real(rk)::lats,lons,coverage,cov_orog

integer::forcing_time_step,start_time

character(*)::paramfile

call glimmer_set_msg_level(6) ! 6 is the default - all messages on

call initialise_glint( ice_sheet,             & ! out  Glimmer's structure defining its ice-sheets  lats,                  & ! in   GCM latitudes  lons,                  & ! in   GCM longitudes  forcing_time_step,     & ! in   interval (hours) between GLINT calls  (/paramfile/),         & ! in   Glimmer parameter file  daysinyear=360,        & ! in   length of model year  extraconfigs=xtr_cnfgs,& ! in   Glimmer config info extra to its conf file  start_time=start_time)   ! in  model start time (hours)

rc=glint_coverage_map( ice_sheet,             & ! in  coverage,              & ! out  Glimmer coverage fraction for non-orog  cov_orog)                ! out Glimmer coverage fraction for orog

The use of extraconfigs is inconvenient. It is constructed by using the subroutine ConfigSetValue for each instance separately to specify the name of its Glimmer hotstart file. In a UM run we are continually restarting, and since we want to be able to restart from any point, we have to give all the intermediate hotstart files unique names, so we would like to specify both the input and output hotstart filename through the API. This can be done with the new restart mechanism (Oli tells me - I don't see its API in the documentation). At present we use some awkward communication between the model and the script which runs it.

At the end of the UM runs:

call end_glint(ice_sheet)

We are currently using the annual SMB scheme, so GLINT is called once per month as follows:

integer::UM_time real(rk)::temp,precip,orog,fw_out

call GLINT(             &  ice_sheet,         & !I/O  Glimmer's structure defining its ice-sheets  UM_time,           & !IN   Current model time   (hours)  temp,              & !IN   Surface air temp field on GCM grid (degC)  precip,            & !IN   Precipitation rate on GCM grid (mm/s)  orog,              & !IN   GCM orog on GCM grid (m)  water_out=fw_out)    !I/O  Output water flux from Glimmer on GCM grid (mm/s)

The water_out is the sum of solid and liquid. It would be an improvement to have these separately, since we'd prefer to deal with them differently. They are distinguished internally in Glimmer, but not through the API, and that would be a valuable addition.

Once per year, the state of Glimmer after GLINT is used to update the UM orography and surface type fields. To do this, we have to access the Glimmer internal information directly, since the API does not make available any information on the Glimmer grid. There are two reasons why we need info on the Glimmer grid: (a) in order to compute statistics of the high-resolution topography for boundary-layer and gravity-wave drag on account of orographic roughness; for the solid surface this information is supplied to the UM in ancillary fields computed from a high-resolution DEM; (b) in order to decide whether to treat a GCM box as ice; this could be done with output fields on the GCM grid if Glimmer returned a land-fraction as well as an ice-fraction, although it is natural to do it in conjunction with (a) in order to ensure consistency.

The following info is used, bypassing the Glimmer API:

ice_sheet%instances%model%geometry%usrf*thk0, & ! surface elevation ice_sheet%instances%model%geometry%thkmask,  & ! surface-type mask ice_sheet%instances%model%projection,        & ! projection ice_sheet%instances%lgrid                      ! grid

real::lambda,phi,x,y integer::i,j

type(glimmap_proj)::proj type(coordsystem_type)::grid

call glimmap_xy_to_ll(lambda,phi, & ! OUT lat and lon of Glimmer point  real(i),real(j),                 & ! IN  Glimmer point indices  proj,grid)                         ! IN Glimmer grid and projection call glimmap_ll_to_xy(lambda,phi, & ! IN  lat and lon of Glimmer point  x,y,                             & ! OUT Glimmer point indices  proj,grid)                         ! IN Glimmer grid and projection

It would be better not to have to bypass the API. To avoid this, we would need extra subroutines in the API.

Jeff has recently found that results from Philippe's model are sensitive to whether linearly interpolated temperature, or temperature appropriate to the nearest GCM ice point, are used for the degree-day scheme on the ice-sheet grid, because of the sharp temperature gradient at the ice margin. To be able to deal with that, we'd need to supply Glimmer with temperature on its own grid, rather than the GCM grid. When we have improved the GCM SMB for ice sheets, we will want to supply Glimmer with SMB on the GCM grid in altitude tiles, or alternatively to give it SMB on its own grid.