Sea Ice Extent as a derived variable

[sloosvel]

Is your feature request related to a problem? Please describe.
The sea ice extent is computed by summing areacello over the points in which siconc/sic (sea_ice_area_fraction) has values > 15%.

It would be useful to be able to compute this quantity as a derived variable and reduce the amount of data that is stored after the preprocessing. The derivation could return an array of ones, with masked values where the sea ice area fraction has values < 15%. This array could later be used in combination with area_statistics(operator='sum') in order to obtain the true sea ice extent, since areacello would be used as the weights to compute the weighted sum.

Units of the derived variable should be set to 'm2', since area_statistics does not handle very well the resulting units.
In summary, with the addition of the derived variable, the sea ice extent could be computed at preprocessor level using a recipe such as:

preprocessor:
  preproc:
    # extract_region / extract_shape (in order to obtain regional values)
    area_statistics:
      operator: 'sum'
   # extra time operations if needed
    convert_units:
      units: 10^6 km2 # the units we ultimately use

variables:
  siextent:
    derive: true
    preprocessor: preproc
  

Where the derivation would consist of:

        siconc = cubes.extract_cube(Constraint(name='sea_ice_area_fraction'))
        ones = da.ones_like(siconc)
        siextent_data = da.ma.masked_where(siconc.lazy_data()<15, ones)
        siextent = siconc.copy(siextent_data)
        siextent.units = 'm2'

Would you be able to help out?
Yes

[dhohn]

Ive been looking at sea ice myself recently, So Id be happy to help out with code and/or testing!

[sloosvel]

Great! Does this approach look good to you?

[sloosvel]

I started the work in branch https://github.com/ESMValGroup/ESMValCore/tree/dev_siextent , but I could open a draft PR

[dhohn]

Yea looks good to me!
I was looking at CMIP6 tho. Where the variables are called siconc and siconca (only GISS afaics). So we could select those based on the project.

[dhohn]

Another challenge Im currently struggling with is with NorESM. For the sea ice variable the areacello needs to be modified: https://noresm-docs.readthedocs.io/en/latest/faq/postp_plotting_faq.html#different-sea-ice-and-ocean-grid
which is inconvenient...

That another issue though!

[sloosvel]

I was looking at CMIP6 tho. Where the variables are called siconc and siconca (only GISS afaics). So we could select those based on the project.

There is already a mapping between variable aliases for sic/siconc based on the project (https://github.com/ESMValGroup/ESMValCore/blob/main/esmvalcore/cmor/variable_alt_names.yml). So in principle ESMValTool should already be able to detect that the variable is named sic in CMIP5 and siconc in CMIP6. Using siconca would be different though.

Another challenge Im currently struggling with is with NorESM. For the sea ice variable the areacello needs to be modified

I think it would be better if this got addressed as a model-dependent fix. Dropping the last the last row of areacello would be a bit tricky though, because then there would be a shape mismatch with the ocean variables. Maybe the fix should be developed so that a row with NaNs is added in sea-ice variables for that model? But I agree with this being a different issue.

[sloosvel]

I have been working on this in #1695, in case you want to test it I could mark the PR as ready for review

[dhohn]

Hi @sloosvel,

I had a look at your branch in #1695 and tried it with a few datasets. It looks good to me (Im attaching some examples). The only thing I would add would be the possibility to use models that publish a siconca but not siconc (GISS being the only example right now). Maybe with another alias to sic?

[sloosvel]

Thanks for the feedback @dhohn !

Regarding making the branch work with models that have siconca, I think I can make the code look for both siconc and siconca. The tests I have done are with a model that outputs siconc in gn and siconca in gr and it seems to work fine.

However, do you know if models can output both variables at the same time with the same grid label? Because I think this could be a source of issues, since the tool would find both variables.

Otherwise, maybe what could be done is also derive siextenta from siconca ?

[dhohn]

However, do you know if models can output both variables at the same time with the same grid label? Because I think this could be a source of issues, since the tool would find both variables.

Yes. I saw e.g. ACCESS-ESM1-5 in the 1pctCO2 publishing both. I also tried to modify the required variables in the DerivedVariable. Indeed it gives an error because both are found!

Otherwise, maybe what could be done is also derive siextenta from siconca ?

That would work, but it would be much more convenient to have everything under siextent. Is there some precedent for this?

[sloosvel]

Is there some precedent for this?

I don't think so. In any case, maybe it's enough setting both sic and siconca as optional variables. If both are found, the derivation script should only use sic. If none are found, the missing variable error would appear later during the derivation, but I think it's the easiest way to make this case work.

[dhohn]

I tried that. It doesn't work when both are present because they have the same standard_name and you get 2 cubes in the extract_cube.

[sloosvel]

Yes, but they can be extracted using the var_name, which is different. I updated the branch and did some tests and it seemed to work.

[dhohn]

Ah of course. Nice and pragmatic :)