CICE6 initial condition

[aekiss]

In ACCESS-OM2 the first run has restart=false and ice_ic=‘default‘ so the sea ice and snow initial conditions are set in subroutine set_state_var in ice_init.F90 at high latitudes where SST is less than or equal to 1°C above freezing (NB: AusCOM is defined in the ACCESS-OM2 build). The initial SST is apparently read from monthly_sstsss.nc (e.g. in /g/data/ik11/inputs/access-om2/input_20201102/cice_1deg) in the AusCOM driver.

Both these steps involve some custom code in ACCESS-OM2. This raises some questions

• how are initial conditions set up in CICE6?
• do we want to replicate exactly the same initial condition in ACCESS-OM3, and if so, how?

I think it would be nice to replicate the ACCESS-OM2 IC so we have a closer comparison, but not if it involves a lot of custom code. Can this be achieved by a custom restart file somehow?

[aekiss]

I guess a restart from a 1-timestep run of access-om2 would work, with whatever tweaks are needed for compatibility between CICE5 and 6.

[dougiesquire]

Interestingly, in the version of CICE6 we're currently using, the "default" ice initial condition is done based on air temperature and latitude, not SST and latitude - see https://github.com/ESCOMP/CICE/blob/28210220e662108824f10b47873cebd994d2d7b7/cicecore/cicedynB/general/ice_init.F90#L2740

[aekiss]

Ah, interesting! So if we want to reproduce the IC we'll need to use an ACCESS-OM2 restart file, not the "default" IC

[dougiesquire]

Ah, interesting! So if we want to reproduce the IC we'll need to use an ACCESS-OM2 restart file, not the "default" IC

I guess so. I think it's easy to have CICE write out its initial condition when it's run, so we could possibly just turn that on in an ACCESS-OM2 run and then use that? We'll need to be careful that the time of year is consistent between the ACCESS-OM2 and ACCESS-OM3 runs, but we need to make sure of that anyway!

[aekiss]

Yeah, cold starts begin on 1 January.

[dougiesquire]

Yeah, cold starts begin on 1 January.

Which is 1 May 1990 "forcing time" for the RYF runs? I feel like I've misunderstood something there

[aekiss]

nope, it's 1900-01-01 on the time axis in the RYF .nc files, which is actually data from 1991-01-01.

1 Jan - 30 Apr in each RYF cycle comes from 1991, and 1 May - 31 Dec is from 1990 (so it joins seamlessly at new year; the only jump is 1 May).

Confusing, right?

[aekiss]

The join is near the equinox because the jump is smaller then.

[dougiesquire]

Ah, I get it. That makes a lot more sense than what I was thinking - Ta

[micaeljtoliveira]

Done in https://github.com/COSIMA/MOM6-CICE6/pull/5

[aekiss]

Reopening, as we'll need to revisit this question for production runs when we update the topography and land mask (especially if we switch to a C-grid) because we won't be able to use ACCESS-OM2 for initial conditions any more.

We also need to consider what initial conditions to use at higher resolution.

I guess we could just use the CICE6 default and see how that goes?

[anton-seaice]

Default + nuopc don't play nice, at least in our current configuration.

When we tested in previously, we found that is basically gave sea ice over all the ocean poleward of some cutoff latitude (e.g. 60S/N).

That might work though? Given the ocean takes longer to initialize than the ice (but is quite messy).

[aekiss]

Default + nuopc don't play nice, at least in our current configuration.

But default what we're currently using at 0.25 deg https://github.com/COSIMA/access-om3/issues/125 so that might explain why we can't run very far? https://github.com/COSIMA/access-om3/issues/101#issuecomment-2019129099

[dougiesquire]

so that might explain why we can't run very far? https://github.com/COSIMA/access-om3/issues/101#issuecomment-2019129099

It's worth looking at the ice area. This is what things looked like when I tried to use the default CICE ICs when setting up the 1 deg inputs:

[anton-seaice]

Thanks Dougie :)

Intuitively I would expect this to lead to errors in thermo-dynamics, rather than dynamics, but it is possible its the issue with the .025 degree config.

[aekiss]

Thanks @dougie, I'd forgotten how bad the default IC is.

[aekiss]

I guess the simplest approach would be to make a January climatology from a spinup at each resolution and use that as the initial condition. Best done after the land mask is finalised at each resolution.

[anton-seaice]

I guess the simplest approach would be to make a January climatology from a spinup at each resolution and use that as the initial condition. Best done after the land mask is finalised at each resolution.

What do you mean climatology? From what data source?

Depending on how similar you want this IC to be to OM-2 spinup, a simple thing to choose would be a restart from an OM2 RYF run (I don't think it really matters which restart to be honest, as long as the grid is the same).

[aekiss]

@dougie has found a ice_data_type = 'latsst' option in CICE6 that seems to be roughly equivalent to ice_ic = 'default' used in ACCESS-OM2 and reads initial SST from a file.

However, note that the CICE6 SST threshold condition differs from what was used in ACCESS-OM2.

We could use these files from ACCESS-OM2 /g/data/ik11/inputs/access-om2/input_20201102/cice_*deg/monthly_sstsss.nc for initial SST.

At some point we might want to update all these: https://github.com/COSIMA/access-om3/issues/161