If the UKV model is used then the wind components u and v are rotated to match the coordinates of the domain. Before writing out the CX columns, the wind components are unrotated back to their original values. In Jopa, the rotation is performed in the UM interface, but the unrotation is not currently performed. This leads to offsets between the CX values of u and v obtained in OPS and Jopa.
In OPS, the original wind components are stored in a dummy variable which is used to overwrite the rotated components before the CX columns are produced. However, this won't be possible in Jopa because of the fact that the GeoVaLs of u and v produced by the UM interface are already rotated and the original values are not stored. It seems likely that obtaining both rotated and unrotated GeoVaLs from the UM interface would be tricky. Instead, a new routine is added to the Cx Writer that reverses the rotation performed.
Two things to note:
Calling Ops_UnRotateWinds from within the CX writer does not work. The booleanCx % header % u_orig % present is always false because the original u is not stored.
Code relating to u10 and v10 should be added at some point.
Fixes #132
Testing
A test has been added to check that the un-rotation works on the LamNoWrapEq grid.
There is also a test on the standard grid in which no rotation occurs.
The rotation coefficients are:
coeff1 = -0.5122
coeff2 = -0.8588
Alternative
I believe it is possible to configure VAR to perform the rotation, in which case this may not be necessary. (In fact, not performing the rotation in VAR could be the correct thing to do.) This routine does ensure that the CX columns are identical between Jopa and OPS at the point at which they are passed to VAR. I wonder if that's advantageous for comparisons and avoiding mistakes at a later date.
If the UKV model is used then the wind components u and v are rotated to match the coordinates of the domain. Before writing out the CX columns, the wind components are unrotated back to their original values. In Jopa, the rotation is performed in the UM interface, but the unrotation is not currently performed. This leads to offsets between the CX values of u and v obtained in OPS and Jopa.
In OPS, the original wind components are stored in a dummy variable which is used to overwrite the rotated components before the CX columns are produced. However, this won't be possible in Jopa because of the fact that the GeoVaLs of u and v produced by the UM interface are already rotated and the original values are not stored. It seems likely that obtaining both rotated and unrotated GeoVaLs from the UM interface would be tricky. Instead, a new routine is added to the Cx Writer that reverses the rotation performed.
Two things to note:
Ops_UnRotateWinds
from within the CX writer does not work. The booleanCx % header % u_orig % present
is alwaysfalse
because the original u is not stored.Fixes #132
Testing
A test has been added to check that the un-rotation works on the LamNoWrapEq grid. There is also a test on the standard grid in which no rotation occurs.
The rotation coefficients are:
Alternative
I believe it is possible to configure VAR to perform the rotation, in which case this may not be necessary. (In fact, not performing the rotation in VAR could be the correct thing to do.) This routine does ensure that the CX columns are identical between Jopa and OPS at the point at which they are passed to VAR. I wonder if that's advantageous for comparisons and avoiding mistakes at a later date.