Add more sea ice variables

[guillaumevernieres]

Description

I'm planning to add the following to the soca State. The fields will be read from a typical CICE6 history output:

2D atmos
========
    float Tair_h(time, nj, ni) ;

2D air ice interface
===============
       float Tsfc_h(time, nj, ni) ;

2D aggregated seaice variables
==========================
    float hi_h(time, nj, ni) ;
    float hs_h(time, nj, ni) ;
    float aice_h(time, nj, ni) ;
    float sice_h(time, nj, ni) ;

3D seaice dynamic
===============
    float aicen_h(time, nc, nj, ni) ;
    float vicen_h(time, nc, nj, ni) ;
    float vsnon_h(time, nc, nj, ni) ;

4D seaice thermo
===============
    float Tsnz_h(time, nc, nksnow, nj, ni) ;
    float Tinz_h(time, nc, nkice, nj, ni) ;
    float Sinz_h(time, nc, nkice, nj, ni) ;

2D cice mask (probably not needed?)
==============================
    float tmask(nj, ni) ;

The 2D variables can be read by simply changing the field_metadata yaml, that should be straight forward (this is what we currently do in the gdas implementation of soca).

The 3D seaice dynamic will require some coding on the io side since the categorical variables will have to be considered as separate variables (aice_1, aice_2, ...)

The 4D seaice thermo variables will be treated as the 3D ones by removing the category dimension.

This should help the cleanup and debugging of the Soca2Cice variable change as well as the AI based balance.

[guillaumevernieres]

~I self assigned myself, but ... Anybody else interested in doing this work before I start? @travissluka ? @Dooruk ?~

[guillaumevernieres]

@travissluka, as I'm plugging away on the coding front, I'm realizing that what I'm doing is very UFS/CICE-centric, and it's adding quite a bit of clunky Fortran to the already clunky IO module. Are we okay with that approach, or should we assume that the background files should be reformatted before being read by SOCA? The latter would require only minimal code changes to allow for a sea ice level dimension at the expense of extra IO.

[travissluka]

@travissluka, as I'm plugging away on the coding front, I'm realizing that what I'm doing is very UFS/CICE-centric, and it's adding quite a bit of clunky Fortran to the already clunky IO module. Are we okay with that approach, or should we assume that the background files should be reformatted before being read by SOCA? The latter would require only minimal code changes to allow for a sea ice level dimension at the expense of extra IO.

I would rather not have to do extra I/O, so, yes, continue adding it into SOCA. Why is it so clunky? I wouldn't think it would have to be. Worst case, cram something in and we can refactor later. Cleaning up the MOM6 file I/O is on my todo list anyway (not anytime soon, there's more important things to do first) there's way too much hardcoded stuff in there.

One request I have: I unfortunately think its a good time to take a look at the variable naming convention, since we're adding in new variables. Otherwise, we'll have to go back later and rename everything whenever I finally get around to talking to ALGO about what our variables should be renamed to. I'll find the CCPP spreadsheet and talk to ALGO about how these things with "categories" should be named