Sea-ice stripes: need smoother wind interpolation?

[aekiss]

Symptoms

Sea ice in 0.25 and 0.1 runs shows stripes, eg these plots of aice_m (ice area aggregate) in 0.25 deg run /g/data3/hh5/tmp/cosima/access-om2-025/025deg_jra55_ryf_spinup7/output144/ice/OUTPUT/iceh.0145-12.nc
in the Ross and Amundsen Seas:

The line plots are meridional transects vs grid index at various longitudes in the Amundsen Sea. This shows that the stripes have a scale of about 5 grid points. With the Mercator grid the spacing in MOM is about 0.1deg at this latitude so the scale is about 0.5deg. This is roughly the JRA55 resolution (resolution of JRA55 data in /g/data1/ua8/JRA55-do/RYF/v1-1/ depends on field; for zonal velocity it is slightly uneven 0.55~0.562deg in latitude:
ncdump -v latitude /g/data1/ua8/JRA55-do/RYF/v1-1/RYF.u_10.1990_1991.nc
but uniform 0.5625deg in longitude).

Stripes of the same physical scale are also seen in 1/10 runs.

Diagnosis

The ice banding is probably due to wind stress curl having steps (or spikes?) at the JRA55 grid scale due to the wind velocity interpolation method used (conservative piecewise constant?) in the regridding. This would give stripy Ekman transport that could advect the ice into bands or draw cool water up from below in stripes.

@nicjhan - what interpolation is currently being used for wind?

Cure?

Try using a smoother interpolation method for regridding uas_10m and vas_10m. I think at minimum the interpolated velocities should be continuous (eg piecewise (bi-)linear) so the curl is piecewise constant. But smoother may be better - eg 2nd order velocity interpolation to give continuous curl. Perhaps see what @PaulSpence did to fix this in MOM-SIS 1/4deg.

Conservative 2nd order is in development but not yet available. But it is not important to be conservative when interpolating wind velocity, as the ocean is driven by stress which is quadratically related and so will not be conservatively interpolated even if the velocity is.

It is important to retain conservatve interpolation for the other fields, so these should be left as-is (at least until conservative 2nd order becomes available).

[StephenGriffies]

I agree with all these points. Let's hope the new interpolation fixes the issue.

BTW, atmospheric winds (and other fields) have traditionally been a pain to interpolate onto ocean grids. In the old days, spectral "Gibbs Ripples" emanated from the Andes. We can still see that from the CORE forcing in some of their fields. It is an age-old problem of transferring information across grids without losing information and without adding computational garbage.

[StephenGriffies]

Note: the Gibb's ripples were not a result of interpolation, but instead they exist in the atmosphere model itself. But it does serve as an example of how the noise from atmospheric fields can be felt by the ocean.

Sorry for my review of history; I just finished a chapter with Gent and Danabasoglu on history of ocean modeling, so have history on my mind...

[ofa001]

You can get Gibbs ripples close to the Antarctic too (anywhere near steep topography) not sure if that’s whats causing these problems in the JRA55 winds or if it is just the interpolation. Siobhan From: Stephen Griffies [mailto:notifications@github.com] Sent: Thursday, 9 November 2017 8:21 PM To: OceansAus/access-om2 <access-om2@noreply.github.com> Cc: Subscribed <subscribed@noreply.github.com> Subject: Re: [OceansAus/access-om2] Sea-ice stripes: need smoother wind interpolation? (#52) Note: the Gibb's ripples were not a result of interpolation, but instead they exist in the atmosphere model itself. But it does serve as an example of how the noise from atmospheric fields can be felt by the ocean. Sorry for my review of history; I just finished a chapter with Gent and Danabasoglu on history of ocean modeling, so have history on my mind... — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#52 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ANrRgqICzPOERssdDoTrbb92lZnGfskSks5s0sP4gaJpZM4QXh_h>.

[nichannah]

Bob Oehmke from ESMF has provided a development snapshot of the 2nd order ESMF regrid weight generation. The documentation is here:

http://www.earthsystemmodeling.org/esmf_releases/last_built/ESMF_refdoc/node3.html#SECTION03020000000000000000

I'll set this up and let you know @aekiss so that you can compare the differences.

[aekiss]

Great, thanks Nic. I think it would be best to apply 2nd order conservative interpolation to all fields, not just velocity.

[aekiss]

Should we also apply 2nd order conservative interpolation to WOA for salt restoring?

[aidanheerdegen]

I thought we had decided that smoother was better than conservative for winds?

As far as other fields go, sure. Wen it is good to go we an look into it.

[aekiss]

Yes it is more important to be smooth than conservative for wind (it would be better to conserve the squared velocity, which would conserve stress if we ignore differences in drag coefficient). There are smoother non-conservative options available (patch interpolation) but I suspect that 2nd order will be smooth enough? Certainly better than 1st order which is piecewise constant. I'm just reading the docs now, hopefully I've got this right!

[aekiss]

Actually, just looking at the variables in /g/data1/ua8/JRA55-do/RYF/v1-3, only rain, rdls, rsds, runoff_all and snow are fluxes, so these ones should have conservative interpolation (preferably 2nd order if that works). I think the rest (q_10, slp, t_10, u_10, v_10) just need to be smooth? (Or is it important the that various fields are interpolated in a consistent way so that bulk formulas behave themselves?)

[aidanheerdegen]

We can discuss at TWG, would be good to hear others opinions

[russfiedler]

Horizontal velocity is not conserved at all over the cells so it is incorrect to even try to conserve it. The patch interpolation looks to be interesting. It seems to use the same sized stencil as bicubic but I think the derivatives might be a bit smoother.

[nichannah]

I made a mistake before and told you that wind is using 1st conservative. I double checked this and in fact presently we're using nearest neighbour (nearest to dest) for wind and 1st conservative for everything else. Apologies for the confusion.

[aekiss]

Some notes from reading the docs:

• 1st order conservative is piecewise constant: http://www.earthsystemmodeling.org/esmf_releases/last_built/ESMF_refdoc/node3.html#SECTION03023400000000000000 and http://www.earthsystemmodeling.org/esmf_releases/last_built/ESMF_refdoc/node5.html#SECTION05012500000000000000
• 2nd order conservative involves a less-sparse matrix multiply than 1st order - hopefully not a significant performance hit? http://www.earthsystemmodeling.org/esmf_releases/last_built/ESMF_refdoc/node3.html#SECTION03023500000000000000 and http://www.earthsystemmodeling.org/esmf_releases/last_built/ESMF_refdoc/node5.html#SECTION05012600000000000000
• should we use --norm_type dstarea ? or do our grids completely overlap? see http://www.earthsystemmodeling.org/esmf_releases/last_built/ESMF_refdoc/node3.html#sec:rwg:conservative_norm_opts and http://www.earthsystemmodeling.org/esmf_releases/last_built/ESMF_refdoc/node5.html#SECTION05012800000000000000
• 1st and 2nd order interpolation uses great circles, not latitude lines, but the differenece should be insignificant at high resolution such as 0.1deg: http://www.earthsystemmodeling.org/esmf_releases/last_built/ESMF_refdoc/node5.html#SECTION05012900000000000000

[aekiss]

We should also double-check that the wind is correctly rotated in the restarts with windrotation.ipynb
(available from #30 (comment) )

[aekiss]

summary of TWG today:

• patch (the smoothest available) for u_10, v_10
• 2nd order conservative for fluxes (rain, rdls, rsds, runoff_all and snow)
• patch or bilinear for non-flux scalars (q_10, slp, t_10) - I'd suggest trying patch and only using bilinear if performance with patch is bad

[russfiedler]

Yep, I reckon this is the way to go. May as well try to be consistent.

I think we should be using latitude lines for the coarse->fine interpolation if possible since that's what is consistent for the regular lon-lat part of the grid. It's an interesting point though.

[aekiss]

related slack discussion: https://arccss.slack.com/archives/C6PP0GU9Y/p1511503476000008

[nichannah]

The results look promising so far. For example, here is a before and after shot of ice atmosphere stress in x (stairx_m).

before on the left is:
/g/data3/hh5/tmp/cosima/access-om2-025/025deg_jra55_ryf_spinup7/output013/ice/OUTPUT/iceh.0014-08.nc

after on the right is:

/g/data3/hh5/tmp/cosima/access-om2-025/025deg_jra55v13_ryf8485_spinup_A/output009/ice/OUTPUT/iceh.0014-08.nc

[aekiss]

Stripes are also gone from the sea ice. This is aice_m (ice area aggregate) in the same files

[PaulSpence]

Looking good :) P

…

On Nov 25, 2017 9:43 AM, "Andrew Kiss" ***@***.***> wrote: Stripes are also gone from the sea ice. This is aice_m (ice area aggregate) in the same files [image: screen shot 2017-11-25 at sat 25-11 9 40am] <https://user-images.githubusercontent.com/31054815/33225055-d89b6d4e-d1c4-11e7-84b5-625124b534d4.png> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#52 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGVk3DCSiFT0EPpJgAMs1FOTIuWfQx6Xks5s50angaJpZM4QXh_h> .

[StephenGriffies]

Agree. Quite nice.

Please let's do a thorough job documenting this issue. It seems to arise every few years. It would be very useful to have a full accounting of it for future model developments.

[nichannah]

Work continues on the 0.1 deg. I've been using the raijin megamem nodes but still no success. I'm going to try an older version of ESMF_RegridWeightGen (without 2nd order conservative remapping) to see how far that gets with patch and bilinear.

[aekiss]

Thanks @nicjhan

I have a 0.1deg ACCESS-OM2-01 spinup underway with the latest code (0e01779) which includes the new forcing (input_d4d65b11.tar.gz). Results are in /g/data3/hh5/tmp/cosima/access-om2-01/01deg_jra55v13_ryf8485_spinup4 (only 2 months so far).

ncview /g/data3/hh5/tmp/cosima/access-om2-01/01deg_jra55v13_ryf8485_spinup4/output*/ocean/ocean_month.nc &

• tau_x, tau_y are beautifully smooth
• sfc_salt_flux_restore, net_sfc_heating, swflx, lw_heat, fprec_melt_heat, sfc_hlux_pme are blocky on a fairly fine scale - did you end up having to use 1st order conservative interpolation for those?

ncview /g/data3/hh5/tmp/cosima/access-om2-01/01deg_jra55v13_ryf8485_spinup4/output*/ice/OUTPUT/iceh* &

• aice_m: no stripes

[nichannah]

Well done @aekiss, glad that you got it working. Yes, we're still doing 1st order for the fluxes. I'll make a separate issue for this.

[nichannah]

The remaining work for this issue has been postponed due to limitations with ESMF_RegridWeightGen. This is documented here:

#71