COSIMA / access-om2

Deprecated ACCESS-OM2 global ocean - sea ice coupled model code and configurations.
21 stars 23 forks source link

Sea-ice stripes: need smoother wind interpolation? #52

Closed aekiss closed 6 years ago

aekiss commented 7 years ago

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: wind-interp-stripes-ross-sea aice_vs_j

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 GitHubhttps://github.com/OceansAus/access-om2/issues/52#issuecomment-343094992, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ANrRgqICzPOERssdDoTrbb92lZnGfskSks5s0sP4gaJpZM4QXh_h.

nichannah commented 6 years ago

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 commented 6 years ago

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

aekiss commented 6 years ago

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

aidanheerdegen commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

russfiedler commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

Some notes from reading the docs:

aekiss commented 6 years ago

We should also double-check that the wind is correctly rotated in the restarts with windrotation.ipynb (available from https://github.com/OceansAus/access-om2/issues/30#issuecomment-329685534 )

aekiss commented 6 years ago

summary of TWG today:

russfiedler commented 6 years ago

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 commented 6 years ago

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

nichannah commented 6 years ago

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

screen shot 2017-11-25 at 6 59 36 am
aekiss commented 6 years ago

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

screen shot 2017-11-25 at sat 25-11 9 40am

PaulSpence commented 6 years ago

Looking good :) P

On Nov 25, 2017 9:43 AM, "Andrew Kiss" notifications@github.com 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 https://github.com/OceansAus/access-om2/issues/52#issuecomment-346903442, or mute the thread https://github.com/notifications/unsubscribe-auth/AGVk3DCSiFT0EPpJgAMs1FOTIuWfQx6Xks5s50angaJpZM4QXh_h .

StephenGriffies commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 &

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

nichannah commented 6 years ago

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 commented 6 years ago

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

https://github.com/OceansAus/access-om2/issues/71