Winds are not being rotated onto the tripole grid

[nichannah]

We are not rotating winds from the spherical atm grid to the ocean tripolar grid. I think we need to do this for both CICE and MOM.

[StephenGriffies]

Wow! That is potentially a very nontrivial mistake. The Arctic sea ice is predominantly wind driven!

I imagine the code is there since POP has both a displaced pole and a tripolar option. I would be surprised if they made this mistake at NCAR, so the code may be there. If you do not see it, then I will query NCAR folks to be sure.

[AndyHoggANU]

Yes, this is worth investing some time in. Was there code as part of CICE4 to do this? That is, are all ACCESS versions with the tripole grid forced with non-rotated winds? You imply that is also the case for MOM, but I find that hard to believe.

My guess is that we want to first look for versions of code where this has been done (either NCAR, CICE4, MOM-SIS) and then decide how to implement it.

[ofa001]

I can have a look on Wednesday when I stop travelling at airport now. If Nic is rigt its moved away from the originial set up perhaps when the CORE fluxes bdy layer was added in.

…

________________________________________ From: Andy Hogg [notifications@github.com] Sent: Monday, 4 September 2017 9:27 AM To: OceansAus/access-om2 Cc: Subscribed Subject: Re: [OceansAus/access-om2] Winds are not being rotated onto the tripole grid (#30) Yes, this is worth investing some time in. Was there code as part of CICE4 to do this? That is, are all ACCESS versions with the tripole grid forced with non-rotated winds? You imply that is also the case for MOM, but I find that hard to believe. My guess is that we want to first look for versions of code where this has been done (either NCAR, CICE4, MOM-SIS) and then decide how to implement it. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#30 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ANrRgnhJpIox4yrHbJFx31R5lUALX_I_ks5sezXZgaJpZM4PIY08>.

[russfiedler]

@nicjhan I see that you've changed input_ice.nml to have rotate_winds=.true. for the latest experiments. I think you should remove the VECTOR flag for the 10m winds from the namcouple file since OASIS-MCT no longer supports vector fields. It's redundant and just makes things confusing. There's no need to do a further rotation of the stresses for CICE -> MOM. In fact I think the if clause in the routine prepare_forcing_from_oasis should be removed as it's now impossible for OASIS to send vector fields.

!bi003: 20090109--set 'rotate_wind' option in case oasis sends U, V as scalars
! NOTE different namcouple is used for oasis this case!
!-----------------------------------------------------------------------------
if (rotate_winds) then ! Get rid of this
workx = uatm(i,j) ! wind velocity, m/s
worky = vatm(i,j)
uatm (i,j) = workxcos(ANGLET(i,j)) & ! convert to POP grid
+ workysin(ANGLET(i,j)) ! note uatm, vatm, wind
vatm (i,j) = workycos(ANGLET(i,j)) & ! are on the T-grid here
- workxsin(ANGLET(i,j))
endif ! Get rid of this

[AndyHoggANU]

@russfiedler - I'm not quite clear on what is happening here. Are you saying there is no vector support so that the rotation is not happening? Or are you saying that it is dealt with correctly and we should relax?
From our side (myself and Andrew K) we were thinking of doing some checks on the wind stresses that are calculated to satisfy ourselves that the code is behaving. Worth doing?

[ofa001]

Definitely think both @russfiedler idea and @AndyHoggANU are correct it would be worth checking what the stresses actually look like before we make cahnges, I am not sure of the OASIS-MCT options but if its now always scalar then we should simplify the loops and have rotate_wind set to true as default set on. Arnold can you check with Dave that he is in the loop on the this.

[russfiedler]

@AndyHoggANU There was a stage (long time ago) when OASIS could perform the rotation of vectors for you. Now it's the responsibility of the users to do this and I'm pretty sure this has been standard for quite a while. Turning on the flag rotate_winds achieves this. My old AusCOM runs definitely did it. Your latest spinup configurations are doing this correctly so all should be good.

[aekiss]

I think we can close this issue.

I've checked this using restart files (ice/i2o.nc, coupler/a2i.nc, ice/grid.nc). This confirms that the wind stress vector (strsu_io, strsv_io) direction in i2o.nc is relative to the (rotated) grid. When the grid rotation is added on, it matches the direction of the JRA55 wind speed vector (uwnd_ai, vwnd_ai) in a2i.nc.

I've attached a jupyter notebook that does this check. It might be useful as a test case to double-check future configurations.

windrotation.ipynb.zip

[AndyHoggANU]

Great - good to know. I agree we can close this.

[StephenGriffies]

So was there in fact no problem, or has the problem now been fixed?

[AndyHoggANU]

@StephenGriffies - it turns out that all was being done correctly so our existing runs are OK. But it's nice to be sure.

[aekiss]

@StephenGriffies, @AndyHoggANU - just a clarification: This was a non-issue for the 025deg_jra55_ryf_spinup6 and 025deg_jra55_ryf_spinup7 runs I checked, which had rotate_winds=.true. in input_ice.nml.

rotate_winds is defined for all /g/data3/hh5/tmp/cosima/*/*/*/ice/input_ice.nml and is .true. for every existing run except these three early tests which have rotate_winds=.false.:
1deg_jra55_ryf_spinup1
025deg_jra55_ryf_spinup1
025deg_jra55_ryf_spinup2
The wind in these three is unrotated so the runs should probably be ignored.

The rest have rotate_winds=.true. and so I'm confident they're OK (though I've only checked a few).

[ofa001]

That’s good news Andy that you had the namelist setting rotate_winds true in most of your runs it was set to default in the old set up and was allowing the oasis to do it handle it but since OASIS_MCT it needed to be switched on. I guess it just need to be documented somewhere and defaults turned the other way round. Sorry to use email its easier than github when travelling. From: Andy Hogg [mailto:notifications@github.com] Sent: Saturday, 16 September 2017 12:21 PM To: OceansAus/access-om2 <access-om2@noreply.github.com> Cc: O'Farrell, Siobhan (O&A, Aspendale) <Siobhan.O'Farrell@csiro.au>; Comment <comment@noreply.github.com> Subject: Re: [OceansAus/access-om2] Winds are not being rotated onto the tripole grid (#30) @StephenGriffies<https://github.com/stephengriffies> - it turns out that all was being done correctly so our existing runs are OK. But it's nice to be sure. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#30 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ANrRgvNPn6VsyFeVNVlD-iKVealu3VS9ks5sizB9gaJpZM4PIY08>.

[StephenGriffies]

Yes, good news. Glad this is clear now.

Steve