Skip to content
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

Wrap-around the longitudes in the polygon locator #108

Merged
merged 4 commits into from
Jan 11, 2023

Conversation

twsearle
Copy link
Contributor

Allow the polyon locator to locate points in a grid when the xy space doesn't lie between 0-360 longitude.

JEDI uses ioda to distribute observations onto processors. This is done in ioda in AtlasDistribution to match the observation distribution to a chosen atlas grid. This uses the PolygonLocator to locate the owning partition for each observation.

This doesn't work on atlas-orca grids, because the xy space for orca data does not start at x=0 and doesn't finish at x=360 (see the meshgenerator).

This PR is a proposal for how to solve this. When a point is not located by the locator, we try again but shifted by 360 degrees.

I cannot forsee how this could go wrong, however I don't know all the grids intimately, so I am very interested in your thoughts! I have rerun the tests with this change and things seem fine.

I have experimented with a test for the locator that catches the issue in atlas-orca and added it to atlas-orca PR#6, but this issue doesn't come up for other grids so I can't really cover it within atlas proper.

@codecov-commenter
Copy link

codecov-commenter commented Aug 19, 2022

Codecov Report

Base: 77.58% // Head: 77.56% // Decreases project coverage by -0.01% ⚠️

Coverage data is based on head (d1f6049) compared to base (2a87cae).
Patch coverage: 16.66% of modified lines in pull request are covered.

Additional details and impacted files
@@             Coverage Diff             @@
##           develop     #108      +/-   ##
===========================================
- Coverage    77.58%   77.56%   -0.02%     
===========================================
  Files          805      805              
  Lines        57589    57606      +17     
===========================================
+ Hits         44680    44683       +3     
- Misses       12909    12923      +14     
Impacted Files Coverage Δ
src/atlas/mesh/detail/PartitionGraph.cc 21.64% <0.00%> (-0.23%) ⬇️
src/atlas/util/PolygonLocator.h 71.62% <17.64%> (-14.59%) ⬇️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

@wdeconinck
Copy link
Member

I think it is OK for now. @pmaciel probably has a better idea, but causing a lot of refactoring. That could be done in a follow up as needed.

@pmaciel
Copy link
Member

pmaciel commented Aug 23, 2022

Yes @twsearle, there have been recent developments in eckit with an improved polygon class that correctly handles polygons spawning greater than 360 degree longitude. This is a starting point to introduce polygons as list of coordinates (the current case) and polygons as list of indices to a (fixed) list of coordinates -- such as a mesh element -- and working on (lat,lon), (x,y) and (x,y,z). These don't exist yet, but when they do they could support the partitioner as well as other fundamental functionality, too, also in other software in our stack (this updated polygon came requested from our software dowstream).

There's some distance to cover still, however, so for the moment a solution like this works as well :-)

@twsearle
Copy link
Contributor Author

Hi @pmaciel that sounds great! Yes I am happy with this interim solution for now. It would be good if the final solution can also be tested against the unusual orca edge case - a grid with a latitude domain ~ 60-420 or so for example!

@pmaciel
Copy link
Member

pmaciel commented Aug 25, 2022

That's a good idea to test against that unusual case: would it be possible to contribute a test for this change, so that we can test when the transition to the improved polygon? The ORCA grids are important to us as well!

@twsearle
Copy link
Contributor Author

@pmaciel, I have had a go at adding a test case in atlas-orca pr6, however in the course of doing that, I found another edge case I am not sure how solve. You can have a look there for details, but I think it is due to the particularities of how the atlas-orca partitioner is setup when dealing with the ORCA2 grids. These grids have a region that is offset in latitude longitude space, making a non-convex partition region. I think this is causing the partition polygon creation to fail.

@pmaciel
Copy link
Member

pmaciel commented Sep 1, 2022

@twsearle, I'm not familiar with the ORCA-specific partitioner (@wdeconinck is). I can say, maybe stating the obvious, that partitioning elements (as opposed to points) does commonly generate "degenerate" polygons (where one vertex shares more than two edges) and less commonly disjoint polygons. Both these have to be considered by the partitioner, that it can handle these cases. This is caused by not just one of the grids proper (source or target) but sometimes the specific relation between them.

It is still of great value to write a test, in this case more than one (right?), as precise as possible to trigger the issue, even if it isn't fixed right away. Maybe comment or disable the test out, but for me there's as much value in diagnosing the issue as with solving it ;-)

@DJDavies2
Copy link
Contributor

This change breaks a nemo-feedback test: test_orcajedi_nemo_io_field_writer.x

[1] �[31mTest "test parallel serially distributed write field array views" failed with unhandled eckit::Exception: Assertion failed: mesh_ in NodeColumns, line 209 of /home/h01/frwd/cylc-run/atlas108/share/mo-bundle/atlas/src/atlas/functionspace/NodeColumns.cc @ �[0m
[1] Stack trace: backtrace [1] stack has 15 addresses
[1] (/home/h01/frwd/cylc-run/atlas108/share/build-mo-spice_gnu/lib/libeckit.so+eckit::BackTrace::dumpabi:cxx11)0x1b0
[1] (/home/h01/frwd/cylc-run/atlas108/share/build-mo-spice_gnu/lib/libeckit.so+eckit::Exception::Exception())0x89
[1] (/home/h01/frwd/cylc-run/atlas108/share/build-mo-spice_gnu/lib/libeckit.so+eckit::AssertionFailed::AssertionFailed(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&, eckit::CodeLocation const&))0x12
[1] (/home/h01/frwd/cylc-run/atlas108/share/build-mo-spice_gnu/lib/libeckit.so+)0xc92f8
[1] (/home/h01/frwd/cylc-run/atlas108/share/build-mo-spice_gnu/lib/libatlas.so.0.31+atlas::throw_AssertionFailed(std::__cxx11::basic_string<char, std::char_traits, std::allocator > const&, eckit::CodeLocation const&))0x24
[1] (/home/h01/frwd/cylc-run/atlas108/share/build-mo-spice_gnu/lib/libatlas.so.0.31+atlas::functionspace::detail::NodeColumns::NodeColumns(atlas::Mesh, eckit::Configuration const&))0xae0
[1] (/home/h01/frwd/cylc-run/atlas108/share/build-mo-spice_gnu/lib/libatlas.so.0.31+)0x3df09a
[1] (/home/h01/frwd/cylc-run/atlas108/share/build-mo-spice_gnu/lib/libatlas.so.0.31+atlas::functionspace::NodeColumns::NodeColumns(atlas::Mesh))0x97
[1] (/home/h01/frwd/cylc-run/atlas108/share/build-mo-spice_gnu/orca-jedi/src/tests/orca-jedi/test_orcajedi_nemo_io_field_writer.x)
[1] (/home/h01/frwd/cylc-run/atlas108/share/build-mo-spice_gnu/orca-jedi/src/tests/orca-jedi/test_orcajedi_nemo_io_field_writer.x)
[1] (/home/h01/frwd/cylc-run/atlas108/share/build-mo-spice_gnu/orca-jedi/src/tests/orca-jedi/test_orcajedi_nemo_io_field_writer.x)
[1] (/home/h01/frwd/cylc-run/atlas108/share/build-mo-spice_gnu/orca-jedi/src/tests/orca-jedi/test_orcajedi_nemo_io_field_writer.x)
[1] (/home/h01/frwd/cylc-run/atlas108/share/build-mo-spice_gnu/orca-jedi/src/tests/orca-jedi/test_orcajedi_nemo_io_field_writer.x)
[1] (/usr/lib64/libc.so.6+__libc_start_main)0xf5
[1] (/home/h01/frwd/cylc-run/atlas108/share/build-mo-spice_gnu/orca-jedi/src/tests/orca-jedi/test_orcajedi_nemo_io_field_writer.x)

@twsearle
Copy link
Contributor Author

A quick update on the issue David noticed. We have confirmed that this is not associated with this PR and is in fact down to an issue with the test that occurs when atlas is updated from tags/0.31.1 to develop. More details in orca-jedi PR (Met Office Internal). The issue was caused by the change to check if the mesh has any points in it as part of Mesh().

@wdeconinck
Copy link
Member

wdeconinck commented Jan 11, 2023

Hi @DJDavies2, @twsearle, please could you check if removing this assertion in "NodeColumns" fixes things?

ATLAS_ASSERT(mesh_);

I'll merge this branch and the removal of this assertion in develop.

@wdeconinck wdeconinck merged commit f8ac720 into ecmwf:develop Jan 11, 2023
@wdeconinck wdeconinck added the Status: Merged PR has been merged in alternative way label Jan 11, 2023
wdeconinck added a commit that referenced this pull request Jan 23, 2023
* release/0.32.0: (24 commits)
  Version 0.32.0
  Add function SolidBodyRotation
  Serial distribution to use entire mesh on every partition (#114)
  Adapt StructuredMeshGenerator to allow creation of meshes where some mpi tasks have no elements or nodes
  Allow interpolation to partitions without points or elements
  Remove assertion checking for empty mesh partition in NodeColumns (see #108)
  Wrap-around the longitudes in the polygon locator (#108)
  Github Actions: Prevent homebrew from auto-updating
  Github Actions: Prevent homebrew from auto-updating
  Github Actions: Update macos-11 to macos-12 (latest available)
  ATLAS-373 Enable gaussian latitudes computation for very high resolution, improving memory requirement with orders of magnitude
  Cosmetic change
  Add Fortran constructors for ShiftedLonLat, ShiftedLon, ShiftedLat  grids
  ATLAS-372: Add missing header file
  Fixup previous commit, fixing segmentation fault
  Support more functionspaces for interpolation with FiniteElement, UnstructuredBilinearLonLat, GridBoxMethod, (K)NearestNeighbour
  Rename StructuredMeshGenerator option 3d -> three_dimensional, but still backward compatible
  Fix interpolation method UnstructuredBilinearLonLat for failing triangular elements
  Add missing CellColumns::halo() function
  Fix Mesh::operator bool() to reflect empty mesh
  ...
wdeconinck added a commit that referenced this pull request Jan 23, 2023
* release/0.32.0: (25 commits)
  Version 0.32.0
  Fix compilation with ATLAS_BITS_LOCAL=64
  Add function SolidBodyRotation
  Serial distribution to use entire mesh on every partition (#114)
  Adapt StructuredMeshGenerator to allow creation of meshes where some mpi tasks have no elements or nodes
  Allow interpolation to partitions without points or elements
  Remove assertion checking for empty mesh partition in NodeColumns (see #108)
  Wrap-around the longitudes in the polygon locator (#108)
  Github Actions: Prevent homebrew from auto-updating
  Github Actions: Prevent homebrew from auto-updating
  Github Actions: Update macos-11 to macos-12 (latest available)
  ATLAS-373 Enable gaussian latitudes computation for very high resolution, improving memory requirement with orders of magnitude
  Cosmetic change
  Add Fortran constructors for ShiftedLonLat, ShiftedLon, ShiftedLat  grids
  ATLAS-372: Add missing header file
  Fixup previous commit, fixing segmentation fault
  Support more functionspaces for interpolation with FiniteElement, UnstructuredBilinearLonLat, GridBoxMethod, (K)NearestNeighbour
  Rename StructuredMeshGenerator option 3d -> three_dimensional, but still backward compatible
  Fix interpolation method UnstructuredBilinearLonLat for failing triangular elements
  Add missing CellColumns::halo() function
  ...
@twsearle twsearle deleted the wrap-polygon-locator branch July 12, 2024 10:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Merged PR has been merged in alternative way
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants