Dear Jonathan and Siobhan,
Thank you for your responses. Please see below for an update on the
status of the discussions.
1) We are agreed on surface_downward_heat_flux_in_snow (Wm-2). The CMIP5
output will use
a cell_methods of "area: mean where land".
This name is accepted for inclusion in the standard name table.
2) Jonathan wrote:
> > (a) Long name 'Surface Temperature of Sea Ice' with units of K and
the
> > following explanatory comments: 'When computing the time-mean here,
> > the time-samples, weighted by the area of sea ice in the grid cell,
> > are accumulated and then divided by the sum of the weights. Report
as
> > "missing" in regions free of sea ice. Note this will be the surface
> > snow temperature in regions where snow covers the sea ice.'
>
> > (b) Long name 'Temperature at Interface Between Sea Ice and Snow'
with
> > units of K and the following explanatory comments: 'When computing
the
> > time-mean here, the time-samples, weighted by the area of
snow-covered
> > sea ice in the grid cell, are accumulated and then divided by the
sum
> > of the weights. Report as "missing" in regions free of snow-covered
> > sea ice.'
>
> It seems to me that (a) is surface_temperature for area: where
sea_ice, and (b) is
> sea_ice_surface_temperature for area: where snow_on_sea_ice, in which
I have invented a
> new area_type. Both are time: mean.
Siobhan wrote:
> I think Jonathan's sub categories where snow_on_sea_ice and
snow_free_sea_ice approach
> helps here, we definitely want the surface temperature over the ice
portion of the grid
> cell rather than over the whole grid cell (using cell methods). Also
the interface
> temperature between snow and ice is important to account for, as it is
much warmer than
> the surface temperature due to the thermal insulation on snow so I am
no two worried about
> the case when there is no snow cover but again the snow_on_sea ice
(area type) would help to prevent the confusion.
Jonathan's approach simplifies these quantities and I'm happy to follow
his suggestion. I think, then, that we are agreed on using the existing
standard name of surface_temperature for the first quantity and
introducing a new standard name of
sea_ice_surface_temperature; K
for the second.
This name is accepted for inclusion in the standard name table.
A new type of snow_on_sea_ice will be added to the area_type table.
I will check that the CMIP5 output document contains the correct
cell_methods entries for these quantities.
(Items 3, 4 and 5 are closed).
6) Alison wrote:
> I think we should use the existing standard names of
> rainfall_flux; kg m-2 s-1
> snowfall_flux; kg m-2 s-1
> and supply a cell_methods attribute of "area: mean where sea_ice over
> sea" for each of them.
Jonathan says he agrees.
Siobhan wrote:
> It makes sense to separate the water flux from snow and rainfall as
the impact differently on the
> surface using the cell methods would indicate them onto the sea ice
portion of the cell. Some
> rain may penetrate into the ice lattice if it s very porous Jonathan
or contribute to melt ponds in
> the Arctic summer, but I don't know of a sea ice models IN CMIP5
that sophisticated to allow for
> that effect.
Sorry, Siobhan, I'm not 100 per cent clear whether you are happy to go
with the names I suggested. The names will certainly allow you to
separate snow and rainfall as per your requirements.
7) We are agreed on
tendency_of_sea_ice_amount_due_to_lateral_growth_of_ice_floes; kg m-2
s-1.
This name is accepted for inclusion in the standard name table.
8) Sea ice thermal energy
Jonathan wrote:
> > sea_ice_thermal_energy; J
> Is it really J, not J m-2? If J m-2, the phrase heat_content would be
> better, as it would be consistent with the existing name
>integral_of_sea_water_potential_temperature_wrt_depth_expressed_as_heat
_content
> (J m-2). If really J, I wonder if we can think of a phrase related to
> heat_content. I am assuming that this quantity relates to
> temperature, but maybe it relates to latent heat content? It would be
> good to be clear about this in the name.
>
Alison wrote:
> According to the CMIP5 document, the unit is J and the long name is
'Sea
> Ice Total Heat Content'. The explanation says, 'Ice at 0 Celsius is
> assumed taken to have a heat content of 0 J. When averaging over
time,
> this quantity is weighted by the mass of sea ice. Report as
"missing"
> in regions free of snow on land.'
>
> I find this rather confusing - if it is supposed to be a sea ice
> quantity, then surely it should always be reported as "missing" over
> land and open sea. It doesn't sound as though latent heat is
included.
> I don't think we can call it a 'content' because it isn't a quantity
per
> unit area. Perhaps Siobhan can help to clarify this quantity further.
Siobhan wrote:
> Sea ice thermal energy, I am a bit confused on the history on this one
there were two
> requests originally made in my 2008 document sent To Karl and
circulated through the
> cryosphere community.
>
> The first was
> Snow_thermal_energy_content Snth new Jm-2 month 1
all
>
> For the land surface component. It was in an earlier version of Karl's
document (I had
> saved 16/6/2009) but is not in the latest 17/9/2010.
>
> The sea ice heat content was given as
>
> integral_of_sea_ice_temperature_wrt_depth_expressed_as_heat_content
hcice New Jm-2 Month 1 All
>
>
> It looks like they retained the hcice name but changed the units.
>
> So I am puzzled as well, I think it should be Jm-2.
>
> The issue of whether the heat content of the snow over the ice should
be included is highlighted, it is possible,
> but it would be preferable as separate variable, as the thermal
properties are very different form the ice, and it
> could confuse interpretation of result if they were merged into one
effect (Unless you are using the UM, Jonathan
> where the atmosphere model treats the two media as if they are
combined).
We already have the standard name thermal_energy_content_of_surface_snow
(J m-2) which, if supplied with the correct cell_methods, would deal
with the first quantity Siobhan mentions. However, I agree that it
doesn't seem to be listed as a separate output in the 17/9/2010 CMIP5
document. If it is needed for CMIP5, then Karl would be the person to
contact.
We seem to be in general agreement that the units of the sea_ice thermal
content should be J m-2, so I will feed that information back to Karl. A
quantity per unit area can certainly be called a 'content' in standard
names, so in fact the original suggestion of
integral_of_sea_ice_temperature_wrt_depth_expressed_as_heat_content; J
m-2
would be appropriate and it would fit with Jonathan's comments. Is this
OK?
9) Sea ice albedo
Siobhan wrote:
> I was bothered that the bare sea ice albedo has been flagged for
> removal, It probably should be total sea
> ice albedo, though in NCAR model bare ice albedo is changeable due to
> black carbon and multi-scattering in
> internal layers. There is a comment on the next page about getting
> albedo from the downwelling and
> upwelling shortwave radiation, but this would not allow for the
> penetration of shortwave radiation into the
> ice. My preference is for total sea ice albedo to be saved. This will
> allows for the more sophisticate
> schemes to have an areal average of seasonal changes in albedos across
> thickness categories, snow cover
> properties, melt ponds and now aerosols effects to be analyzed, I
> couldn't find surface albedo being
> saved elsewhere in the CMIP5 document.
Alison wrote:
> In view of Siobhan's comments I think there is definitely a need to
> agree a name for this quantity. I think that Karl is correct that
> 'surface_albedo' would normally refer to the whole grid cell. It
should
> really be 'sea_ice_albedo'. We could introduce a new name of
> 'sea_ice_albedo_assuming_no_snow' but I'm not sure whether it is
really
> correct to use the "assuming" phrase here. Perhaps it would be more
> accurate to use the existing name 'sea_ice_albedo' and introduce a new
> area_type of 'snow_free_ice'. I'd welcome opinions on this.
Jonathan wrote:
> I think that would be a correct description, yes. This area-type is
the counterpart of
> snow_on_sea_ice which I needed above. I think yours should be
snow_free_sea_ice.
Siobhan wrote:
> I still support the need for a sea ice albedos, my comments on whether
it is total or bare
> still stand, again it should be defined on the sea ice portion of the
grid. Alison's
> suggestion of an area type snow_free_ice could help distinguish it is
bare, but if the snow
> depth is also known, then that would be clearer, though there will be
transition months as
> the ice becomes snow free.
>
> So is one total sea ice albedo sufficient?
One CF standard name for sea ice albedo is sufficient if it is
essentially the same geophysical quantity for snow covered/bare sea ice.
Then the only issue is to distinguish between surface types and this is
the role of the area_types. Area types of snow_free_sea_ice and
snow_on_sea_ice would allow you to make that distinction, so I am in
favour of introducing one new standard name of sea_ice_albedo, plus the
new area_types.
Again regarding CMIP5, Karl would be the person to contact if you wish
to save the albedo for both surface types as currently only the bare ice
quantity is listed in the output document. The quantity
surface_snow_thickness is listed as an output with a cell_methods of
'mean where sea'. If you wanted the same quantity saved with a
cell_methods of 'mean where sea_ice' then I think it would be a separate
output. In practice, would the quantity that is already being saved be
enough to tell you whether the ice is bare?
10) We are agreed to use the existing names
surface_downward_x_stress; Pa
surface_downward_y_stress; Pa
and introduce two new standard names
upward_x_stress_at_sea_ice_base; Pa
upward_y_stress_at_sea_ice_base; Pa
(all accompanied by a cell_methods attribute of "area: mean where
sea_ice" for CMIP5.)
The new names are accepted for inclusion in the standard name table.
Best wishes,
Alison
------
Alison Pamment Tel: +44 1235 778065
NCAS/British Atmospheric Data Centre Fax: +44 1235 446314
Rutherford Appleton Laboratory Email: alison.pamment at stfc.ac.uk
Chilton, Didcot, OX11 0QX, U.K.
--
Scanned by iCritical.
Received on Tue Sep 28 2010 - 06:14:45 BST
