Closed twsearle closed 2 years ago
Hi @twsearle let me think about this a bit more. I'm off today, but will look tomorrow.
I think what is going on is that my bilinear remapping interp relies on a shared lonlat coordinate system between the mesh, the source points, and the cell centroids in the kd tree. The mesh is used to generate cell centres that are then compared to the source points to identify the cell.
I can make adjustments to the points to ensure they lie between 0-360 during the interpolation, but if I adjust the grid to this range I need to be able to guarantee that the grid shares the same 0 degree line as the source points. In the case of this shift to the orca grid, it depends upon the particular grid used. What do you think? Should an atlas mesh make a promise about the position of the zero line in a grid?
Following on from your suggestions on slack I have been trying out some other solutions for this. I think I might have a fix to apply in the atlas repo that ought to work. I am leaving this PR here because I think this is a useful test to add into atlas-orca either way.
I have revisited my bilinear remapping interpolation PR in atlas ecmwf/atlas#85. This interpolation scheme only works at the moment if I undo this normalisation step in atlas-orca.
I think I understand why this normalisation step is in here - there is a seam in the orca grid with an overlap. Multiple grid points share longitude/latitude positions. The normalisation step moves this seam to the edges of the mesh. I am still not quite sure why this change should lead to all points to the left of the seam being marked as missing. Its possible that the halo is not setup correctly, and I would be better off fixing that rather than making the change in this PR. Please let me know!
I have made some plots to show the overlap in the orca2 and orca12 grids (ignore the black line, I was experimenting with showing the grid extent). In the ORCA2 grid the seam is around 80 degrees longitude in the file with this fix:
Before the change in this PR you can see that the points are no longer doubled up but the range has been shifted:
The eorca12 grid has a similar seam, however it is harder to visualise due to the number of grid points. The seam is around longitude 72:
I am not sure if it is in fact a connectivity issue, because the file generated by atlas-meshgen looks well connected in gmsh:
Testing
This passes the ctests following the change, and the mesh looks identical because I believe it is based on the xy field rather than the lonlat field.
I have added a ctest that along with my ATLAS PR demonstrates the issue with and without this fix. The second section of the test will be marked missing if the unormalise longitude change is omitted.