-
Notifications
You must be signed in to change notification settings - Fork 168
Fixing unit conversion for C-grid velocity interpolation #2455
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: fieldset_from_nemo
Are you sure you want to change the base?
Fixing unit conversion for C-grid velocity interpolation #2455
Conversation
To test that the spherical mesh conversion leads to the expected meridional velocity
|
OK, I dug a bit deeper and now think that the original interpolation in v3 (and v4) is correct. See the new unit test I created in 5436136. Parcels/tests/test_advection.py Lines 459 to 481 in 5436136
This sets a meridional The test passes with the current v4 (and also v3; I checked manually), but not with the change below in @@ -312,8 +312,8 @@ class VectorField:
if applyConversion:
if self.U.grid._mesh == "spherical":
- meshJac = 1852 * 60.0 * np.cos(np.deg2rad(y))
- u = u / meshJac
+ meshJac = 1852 * 60.0
+ u = u / (meshJac * np.cos(np.deg2rad(y)))
v = v / meshJac
if "3D" in self.vector_type:
w = self.W.units.to_target(w, z, y, x)So this means that |
|
I think the same unit converter |
|
Thanks for this explanation, @MeikeBos. Makes sense, yes! It's a relief that we now also understand why the cosine-factor is also needed for the meridional velocity 😃 |
This PR reverts back the change in c311fba, to avoid having to set
fieldset.V.units = GeographicPolar()Note that this aligns with the implementation of unit conversion in v3, where
uandvare converted by the samemeshJacParcels/parcels/field.py
Lines 1615 to 1635 in 1ce5908
This has been the case since the very first implementation of C-grid interpolation in 19ef089
The question, however, is whether this is indeed correct to do. I never noticed it, but it may feel a bit strange to apply the same unit converter to
lonandlat.From discussions today, I now realise that our 'gold standard test', the zonal flow in nemo_curvilinear, in not a good test for this case, because
v==np.close(0.)in that case, so it doesn't matter if it's decided by1852*60or by1852*60*cos(lat)I will go back to Philippe's original paper to see why we originally implemented the same conversion for
uandvin Parcels v2.0. Hopefully that clarifies this....