PCMDI areacell* problems

[martinjuckes]

See https://github.com/PCMDI/cmor/issues/220

[taylor13]

The last entry of PCMDI/cmor#220 that mentions the river grids (see https://github.com/PCMDI/cmor/issues/220#issuecomment-335011850 on October 8) included the following:

@martinjuckes The specifications I wrote down in the google doc ( https://goo.gl/3VSQuK )  
were meant to avoid changing anything in the data request and also to avoid modifying (or 
degrading the utility) of CMOR and PrePARE. ...

In late April a single group asked us to modify the data request to report river model output 
on a native grid.  Since this came so late, I don't think we should be compelled to do 
anything that might make it inconvenient for most modeling groups (who don't report 
river output on a special "river model" grid) to use CMOR to write their model output. 

Release 1.00.17 was consistent with the written grid guidance ( https://goo.gl/3VSQuK ) and with earlier releases of the data request, but release 1.00.18 isn't. Release 1.00.17 would have made it clear that river data was being requested on the atmospheric grid, but would have allowed the few groups who want to report on the native grid to do so as provided for in https://goo.gl/3VSQuK .

Could you please suggest edits to the section V. 2. of https://goo.gl/3VSQuK to explain how the special 7 river variables should be handled?

I was planning to replace the links to grid guidance found at https://pcmdi.llnl.gov/CMIP6/Guide/modelers.html with links to ( https://goo.gl/3VSQuK ), but this now will have to wait until it is modified in response to the changes made in 1.00.18. The sooner we get this guidance in place, the more likely that we'll get uniform compliance, so thanks for your help with this.

Karl

[martinjuckes]

Sorry, I thought I was implementing an approach that you had suggested. I hadn't spotted that "gn" and "gr1" have alternative meanings for data from a river model grid. Given that there is no information in the file metadata other than, in some cases, the cell_measures attribute, to say which grid the variable comes from, it would be confusing.

[taylor13]

This is an important issue concerning sea ice (but related to the above): I think somehow almost all of the sea ice variables have been mistakenly requested on the atmospheric grid, when in fact all models actually originally calculate these variables on the native ocean grid.

Here is some information about sea ice grids from email exchanges between me and sea ice modelers (also see PCMDI/cmor#220):

Karl wrote:
Hi all,

As you know, for CMIP6 we're collecting model output from multiple
experiments.  We are trying to work out the details of some of the
metadata that will be included in the output files.  My knowledge of sea
ice models is now somewhat dated, so I hope that you will be able to
answer the following questions for me about the horizontal grids used in
representing sea ice fields:

1) For models that include prognostic equations for changes in sea ice,
      a) Are the sea ice model prognostic equations in all models
currently solved on the same grid as the hosting ocean grid?  If not, do
they have their own "native" grid, or do they get evaluated, for
example, on an atmospheric grid?
      b) Are any variables characterizing the ice evaluated on a grid
different from the one used for the prognostic equations?   If so, can
you please provide an example. (Note, I realize in some models sea ice
variables might be regridded either to couple to the atmosphere or
simply to be reported on a different grid, but I'm interested here in on
what "native" grid they are generated.]

2)  Are there any purely diagnostic models for sea ice?  If so, on what
grid are diagnostic sea ice variables evaluated?

3)  In the past I know, all (or nearly) all sea ice models shared the
same grid as the ocean.  Do you see that changing in the next 5 years or
so?

thanks very much for your help with this.  I'm afraid hearing from you
about this is rather urgent because folks are beginning to save CMIP6
output.

thanks again and best regards,
Karl

Reply from Cecilia Bitz:

My answers are below. I'll be interested to hear if the others know differently.

> 1) For models that include prognostic equations for changes in sea ice,
>       a) Are the sea ice model prognostic equations in all models 
currently solved on the same grid as the hosting ocean grid?  If not, 
do they have their own "native" grid, or do they get evaluated, for 
example, on an atmospheric grid?

**I have never seen a model where the sea ice output is on a 
different grid than the ocean. I wouldn't rule it out though. A 
possibly relevant odd case I can think of is the Hadley Centre 
models, which has sea ice thermodynamics coupled to the 
atmosphere boundary layer without time splitting. I believe 
they then regrid the thermodynamic variables to the ocean grid 
for transport and deformation steps. I'll see if I can verify this, but 
I'm pretty sure.  I believe all the output has been archived on the 
ocean grid in past CMIPs.**

>       b) Are any variables characterizing the ice evaluated on a 
grid different from the one used for the prognostic equations?   
If so, can you please provide an example. (Note, I realize in some 
models sea ice variables might be regridded either to couple to 
the atmosphere or simply to be reported on a different grid, but 
I'm interested here in on what "native" grid they are generated.]
>
**In the CICE model the sea ice grid is a B grid so (UVEL,VVVEL) 
are staggered from the tracer grid (Tsfc,SIC,SIT,etc). But 
(UVEL,VVEL) are regridded onto the tracer grid when they are sent 
to history or through the coupler to other components. I don't 
know about other sea ice models.**
> 2)  Are there any purely diagnostic models for sea ice?  If so, 
on what grid are diagnostic sea ice variables evaluated?

**Not that I'm aware of.**

>
> 3)  In the past I know, all (or nearly) all sea ice models shared the 
same grid as the ocean.  Do you see that changing in the next 5 
years or so?
I doubt it. In fact, I think the Hadley Centre is soon to conform to 
other models. I'm in the UK and we have a sea ice modelers meeting 
on Monday (Dirk is attending). We can confirm this with the Hadley 
Centre if you you wish.

Additional information from Cecilia:

I was slightly off about HadGEM3. Not all of the thermodynamics is done 
in the atmosphere. Hewitt et al (2011) 
https://www.geosci-model-dev.net/4/223/2011/gmd-4-223-2011.pdf  say:

Surface sea ice temperature, atmosphere to ice fluxes and the conductive 
heat flux through the ice are calculated in the atmosphere component (as 
in HadGEM1, McLaren et al., 2006) while the remaining calculations (ice 
growth and melt, dynamics and ridging in thickness cate- gories) are 
carried out by the CICE submodel on the ORCA grid at the same resolution 
used by the ocean component. The ocean and sea ice subcomponents 
always need to run on the same grids to ensure that fluxes of heat and 
freshwater can be accurately maintained between both submodels.

Information from Dirk Notz:

Short answer from my side:

- All models I know of calculate all state variables of sea ice on the
ocean grid. This includes the purely diagnostic measures sea-ice extent
and sea-ice area that we request for CMIP6

- Many models calculate atmospheric fluxes over sea ice only on the
atmosphere grid, using a re-gridded sea-ice cover for these
calculations. The sea-ice model on the ocean grid never sees these
individual fluxes but only obtains some integrated net surface flux.
This flux is then used in the sea-ice model on the ocean grid to update
surface temperature, ice thickness, internal temperatures etc. This is
done for most European models I know of, including our MPI models,
Hadley Center models, EC-Earth. These models will hence report
atmospheric fluxes over sea ice on the atmospheric grid, as far as I know.

- I don't believe that sea-ice models will move to a grid separate from
the ocean very soon. However, given the change in computer architecture,
sea-ice rheology might become a burden for high-resolution simulations
eventually. This would imply that high-resolution atmosphere/ocean
models might have to be coupled to a sea-ice model running on its own
grid at lower resolution. We don't have a good solution yet on how to
truly effectively run sea ice on the new generation of exa-scale computers.

Additional information from Cecelia:

Dirk's email reminds me that I did ask the Hadley Centre contingency yesterday 
about their model, and they said HadGEM3 is their CMIP6 model. So the paper I 
quoted in my previous email is up to date. They mentioned that GFDL is using 
the same grid for atmosphere, sea ice and ocean, which they think is the way of 
the future. 

Information from Ed Blockley

As Dirk says we shall be providing sea ice variables for CMIP6 on 2 grids. 
All our surface exchanges are performed in the atmosphere/land model (at 
each atmospheric time step) and so things like the list below (at end email) 
are output from our atmosphere model on the atmosphere grid.

This means that we will also include sea ice concentration and the 'ice present' 
heavyside function variable from the atmosphere.

As Dirk also says the ice model at present does not scale well.
Therefore one of the next tasks that we will perform is to decouple the 
sea ice from the ocean model and run it through OASIS at each time step.
This functionality exists in the NEMO model system but, at present, requires 
the models to be on the same grid (i.e., only load balancing is changed to 
speed the ice up). I suspect this is likely to change in the near(ish) future to 
allow the ice model to run on a different grid if needed (then we could have 
high res NH/SH and low-res tropics).
This could lead to the possibility of the sea ice being done entirely on the 
atmosphere grid instead of the ocean grid but we've not really discussed 
anything like that yet.

PS it's perhaps worth noting that - as we use NEMO ocean and CICE sea 
ice - currently our ice is on a different grid from the ocean. The tracer points 
(grid-cell-centres) are identical but the velocities are quite different owing to 
the fact that CICE uses a B-grid and NEMO a C-grid.

Example (not exhaustive) list of atmosphere diags sea ice for HadGEM3:

Downwelling shortwave flux over sea ice
Upward shortwave flux over sea ice
Downwelling longwave flux over sea ice
Upward longwave flux over sea ice
Net sensible heat flux over sea ice
Atmospheric drag coefficient

My takeaway summary is that sea ice is prognostically calculated on the same grid as the ocean. Given this fact and given that in CMIP5 all sea ice variables were requested on the same grid as the ocean, I see no reason to deviate from CMIP5 and request sea ice variables on the atmospheric grid.

I therefore think that in the data request cell_measures should specify "area: areacello" for all sea ice variables. This mistake should be corrected immediately.

Also, I would like to point out again (see PCMDI/cmor#220) that a cell measure of "area: areacello OR areacella" breaks CMOR so must be replaced with either "area: areacello" (or "area: areacella", but this would be ruled out by the above considerations).

[taylor13]

It is now really urgent that the areacella problem in the sea ice tables be corrected. This not only affects the attribute but incorrectly indicates that most variables should be reported on the atmospheric grid. This needs to be fixed in the next release.

In the sea ice tables, there are several instances of cell_measures being specified as "areacello OR areacella". This is not a CF-compliant option and it breaks CMOR. A similar problem was noted concerning areacellr, which I think has now been corrected (see https://github.com/PCMDI/cmor/issues/220 ).

From the information provided by sea ice experts (above), it is clear that nearly all sea-ice related information is calculated in the model on the ocean grid, so nearly all variables in tables SIday and SImon that currently have cell_measures of either "areacella" or "areacello OR areacella" should be changed to "areacello".

The only possible exception according to those experts could be certain fluxes of energy/water between the sea ice surface and the atmosphere, and also atmospheric drag, but I really think these too should be reported on the ocean grid so one can do budget studies of sea ice mass, energy content, and momentum. Only if a modeler provides convincing evidence that budget studies of can be done without saving all the sea ice variables on the ocean grid should we consider doing something else.

The only definite exception is siconca, which should have areacella.

[taylor13]

In emails (Jan 9, 2018), Dirk Notz and Martin Vancoppenolle indicated that only the following variables need to be collected on the atmospheric grid: siflswdtop, siflswutop, sifllwdtop sifllwutop siflsenstop sifllatstop I would add to that "siconca".

We might want to wait to hear from Cecelia Bitz.

[taylor13]

@martinjuckes I think time has run out on getting further input from the sea ice experts. Let's go with the recommendation we have from them summarized in the comment immediately above.

[taylor13]

@martinjuckes: If this issue was "urgent" more than 2 months ago, it is critically urgent now. All cell_measures in SIday and Simon should be set to "area: areacello" except those currently set to "--MODEL" or "", and except siflswdtop, siflswutop, sifllwdtop sifllwutop siflsenstop sifllatstop siconca which should be set to area: areacella.

I note that IPSL is using release 01.00.20 and won't update, so they will be producing files with incorrect metadata. PrePARE will catch the problem and won't let them publish. This will cause headaches all around.

[senesis]

CNRM will use 01.00.21 and will set area:areacellao for all seaice variables except for siconca, siu and siv (we do not produce the shortlist of other variables needing areacella) CNRM provides the dr2xml software to IPSL, so IPSL will be able to do the same.

[taylor13]

@senesis was that a typo? I hope you meant area: areacello (not areacellao, which is not a CMIP6 variable).

[senesis]

It was a typ : I meant areacello. And also : transports won't get a value

[taylor13]

I also had two critical typos in my note above https://github.com/cmip6dr/CMIP6_DataRequest_VariableDefinitions/issues/252#issuecomment-371653618 where my use of areacello and areacella were reversed. I have now edited that comment to correct it. To be sure, nearly all sea ice variables should be reported on the ocean grid with area: areacello. Sorry for the confusion. What @senesis plans is, I think, consistent with what the DREQ will specify, once the needed corrections to the DREQ are made.

[taylor13]

My understanding is that we need to make the data request consistent with the guidance provided by sea ice modelers (and also CF-compliant and avoid CMOR error exiting). To repeat the request from early March (see https://github.com/cmip6dr/CMIP6_DataRequest_VariableDefinitions/issues/252#issuecomment-371653618):

All cell_measures in SIday and Simon should be set to "area: areacello" except those currently set to "--MODEL" or "", and except siflswdtop, siflswutop, sifllwdtop sifllwutop siflsenstop sifllatstop siconca which should be set to area: areacella. All cases of "areacella OR areacello" must be eliminated.

[martinjuckes]

OK, this will be updated in the next release.

[taylor13]

Excellent news. Thanks.

[martinjuckes]

Email from Matthew M.: the following also need to be changed to areacello: 'sidconcdyn', 'sidconcth', 'sidmassdyn', 'sidmassevapsubl', 'sidmassgrowthbot', 'sidmassgrowthwat', 'sidmasslat', 'sidmassmeltbot', 'sidmassmelttop', 'sidmasssi', 'sidmassth', 'sihc', 'siitdconc', 'siitdsnconc', 'siitdsnthick', 'siitdthick', 'simass', 'simpconc', 'sisaltmass', 'sisnthick', 'sitimefrac', 'sivol', 'sndmassdyn', 'sndmassmelt', 'sndmasssi', 'sndmasssnf', 'sndmasssubl', 'sndmasswindrif'

[martinjuckes]

siitdconc: structure str-b117 edited to be areacello simpconc: structure str-d84 edited to be areacello sisnthick: structure str-387 edited to be areacello (and procNote changed to glsl); 'siitdsnconc', 'siitdsnthick', 'siitdthick': structure str-d57 edited to be areacello The remaining: change structure reference from str-013 to str-a098.