Something I have been struggling with for months now is the issue of super thick sea ice. After 3 years of simulation the sea ice is around 4 times as thick as ICESat measurements, with some coastal areas as thick as 80 metres (!) This means I can't keep polynyas open, and the lack of strong localised dense water plumes causes all sorts of other problems.
After going through just about every part of the CICE code, I concluded the problem was most likely with ROMS, specifically the supercooling which ROMS calculates and passes to CICE to form new ice. This code is based on the POP code for coupling with CICE: the ocean integrates the net supercooling over the upper few layers, sets the supercooled temperatures back to the freezing point, and sends the energy to CICE in W/m^2. Since POP is a z-coordinate model but ROMS is terrain-following, rather than integrating over a specified number of layers, MetROMS integrates over a specified surface thickness (I'm using 5 metres) for which the number of terrain-following layers can vary.
I was checking the original POP code and found this warning:
Code: Select all
! WARNING: unless a monotone advection scheme is in place,
! advective errors could lead to temps that are far below freezing
! in some locations and this scheme will form lots of ice.
! ice formation should be limited to the top layer (kmxice=1)
! if the advection scheme is not monotone.
So I started looking for evidence of spurious supercooling, and this is what I found. Here is a slice through the Ross Sea with no time-averaging or spatial interpolation/averaging. It shows the difference from the freezing point (as seen by the supercooling code, Tf = -0.054*salt, depth dependence shouldn't matter over the upper 5 metres):
There is definitely some spurious supercooling going on over the steeper areas of the continental shelf, far from the ice shelf cavity (which deals with supercooling separately). The spurious mixing is even more obvious with the absolute temperature:
and to some extent with salinity:
The velocities u and v look better, I think any weirdness there is largely just in response to the tracers, but I might be wrong:
If the spurious supercooling happens below 5 metres it won't directly form any ice (although I'm wondering if it would indirectly form ice by cooling the upper layers or just generally causing more instability?). But if it happens within 5 metres of the surface it won't show up in these plots because it's immediately set to the freezing point and sent to CICE to form new ice. I wasn't sure if this would even happen at the surface or if spurious mixing was largely a problem at depth. But then I compared plots of the positive freeze/melt potential (i.e. energy from supercooling sent to CICE):
to the bathymetry:
and if you line them up, the highest areas of supercooling are right near the continental shelf breaks of the Ross and Weddell Seas. In reality frazil formation should be concentrated right by the coast or ice shelf fronts, where there should be polynyas. The only reason supercooling would be strongest at the continental shelf break, as far as I can see, would be advective errors due to the steepness of the bathymetry there.
These are the CPP options I am using for advection and related things (eg mixing) right now:
Tracers: TS_C4HADVECTION, TS_C4VADVECTION, MIX_ISO_TS, TS_DIF2, DIFF_GRID
Momentum: UV_ADV, MIX_S_UV, UV_VIS4, VISC_GRID
and I have Vtransform=2, Vstretching=2.
By looking through other posts on this forum I think the culprit is TS_C4HADVECTION and TS_C4VADVECTION. I am writing to ask what would be better schemes to use. It looks like TS_MPDATA is the only monotonic advection scheme available, but Ben mentioned it might have other weaknesses. I have also seen posts suggesting TS_U3ADV_SPLIT or TS_A4HADVECTION/TS_A4VADVECTION are less prone to spurious maxima and minima, even though they aren't monotonic.
I can't test any of these until 1 October (when the CPU time allocation for next quarter becomes available) but I thought it would be wise to ask for expert advice in the meantime, rather than going down a path that is likely not to work. What do you think would be my best option(s)?
Many thanks,
Kaitlin