You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@zklaus says: Fortunately, it is also unnecessary: the information of the area is available in areacello.
The reason why iris does not provide this information is that it is really hard impossible to calculate in general. It becomes merely really hard when you accept the simplication of connecting points with arcs of great-circles. In that case, triangulation of cells with triangles on the surface of a sphere is possible, as done by cdo. This is, however, not a good approximation for some of the most common model grids.
This would be a problem with ideal model data. In reality, the problem is larger. Take as a case study the orca grids as used by nemo. They have two poles that come to lie at the top row of the data after unwrapping of the grid. But to ensure computational continuity, the two top rows are repeated and prepended to the data, this time mirrored left to right. Consequently, taking the coordinates just from that row for all rows is not merely dramatically wrong (as it would be if you took the, say, tenth row) but really in completely unrelated areas of the world.
PS: (Ofx, areacello) should be available more reliably than other ocean measures like volcello because the variation generally stems from variations in layer thickness, either from a free surface or a density or bathymetry based vertical coordinate,none of which influence purely horizontal quantities like the area.
Problem
iris.analysis.cartography.area_weights
calls it a day whencube.coord("latitude")
and/orcube.coord("longitude")
are 2DWhen using
_volume.volume_statistics()
area_weights
need to be computed that crashes when passed in ocean data with 2D coordsSpecialists like @ledm @zklaus @bjlittle should chip in here plese 🍺
The text was updated successfully, but these errors were encountered: