Bad IC files for CICE model

[DeniseWorthen]

Description

Testing of the new PIO feature for CICE has led to the determination that the ICs used for the RTs are incorrect for the velocities. These ICs have been created from various sources over the years but to my knowledge all have involved mapping a "source" restart file to the CICE6 grid.

For the current RT IC files, I believe the source for all test cases has been the CPC reanalysis using SIS2 on the MOM6 tripole grid at 1/4 deg resolution and downscaling from that resolution to the lower resolutions. For the benchmark case, the source was most likely the MOM6 DA runs from Travis Sluka, which also would have been SIS2->CICE6.

The issue is that the mapping onto the CICE6 grid does not change the sign of the velocities across the tripole seam.

To visualize the issue, the following shows the uvel on the last row of the 1/2deg RT test. The black line shows the value in the current IC file. Note that the signs of the uvel are the same on either side of the midpoint (180). The red line shows the value of uvel in a restart file written by the model after two hours. At this point, the model is still adjusting, but note that the signs of the uvel are now opposite across the midpoint.

This was found when switching from the NetCDF interface to the PIO interface because some baselines did not reproduce. See CICE-Consortium/CICE#937 for additional details.

To Reproduce:

Look at the velocities across the last row in the IC file for any test case.

Additional context

There are several potential fixes.

1. Accept the B4B changes when we switch from netCDF to PIO. Testing has shown the PIO baselines will reproduce on restart. Continue to use bad ICs for the RTs.
2. Create ICs via a similar process that has been used in the past, but fix the mapped velocity fields.
3. Use none as the initial condition for CICE in the RTs.
4. Create new CICE ICs for the RT by running each configuration forward for the minimum time necessary to generate an ice restart file. Use that restart file as the IC for the RTs.

Output

[apcraig]

Just to add a couple comments if you are going to use an interpolated initial condition file (option 2 above). All fields on the IC file should be appropriately symmetric on the tripole seam. For fields like temperature, that means the field should be identical across the seam. For u and v, that means the value should be identical with opposite sign.

When interpolating, it's possible roundoff (or bigger) differences are being introduced if the two sides of the tripole seam are being interpolated independently. So when interpolating, all values on the tripole seam of all fields may need to be adjusted. A recommended approach would be to reflect the values on one side of the tripole seam to the other side with appropriate sign and to do so for all fields after interpolation. For fields that change sign, it will be important to get the sign correct.

Another option might be to use the interpolated fields, but set the velocities to zero on the seam. This is not ideal, but it's unlikely to affect climate and is a self consistent option. Note that you do not want to do this with temperature and temperature still needs to be identical across the seam for that seam to be physically correct.

[DeniseWorthen]

@apcraig Thanks. I believe the most sensible option is really 4 (generate rational ICs from running forward). They won't be adjusted, but at least they should be self-consistent, and we avoid all the issues that you refer to. For instance---SIS2 restarts are on the C-grid, AFAIK so I'd really like to get away from using them. And, these are really just ICs for the regression testing, not for production runs. Those will most like come from the marine DA system.

[NickSzapiro-NOAA]

A benefit of having odd, jumpy conditions for the regression tests (as opposed to science/forecast simulations) is that they may reveal more errors by exercising less typical edge cases. Maybe an option 5 is to construct ICs particularly for edge cases, if possible.