Passing in-vicinity output through the nbhood-land-and-sea CLI (when using topographic aware neighbourhoods) currently fails due to a ValueError being raised when the land/sea data is combined back into a common cube. The issue raised is the following:
File "/g/data/zd19/bo1606/miniconda3/envs/improver/lib/python3.8/site-packages/improver/cli/nbhood_land_and_sea.py", line 183, in process
combined_data = result_land.data.filled(0) + result_sea.data.filled(0)
ValueError: operands could not be broadcast together with shapes (27,2,427,490) (2,27,427,490)
Tracing the issue back through the code, it stems from differences in how the NeighbourhoodProcessing.process and ApplyNeighbourhoodProcessingWithAMask.process functions handle dimension coordinate ordering for the resultant cube. In the latter case, the result is compared against the input cube and then passed through the check_cube_coordinates function to give consistent ordering with the input cube. This check does not occur within NeighbourhoodProcessing.process and so the resultant cube shape can differ from that of the input cube.
In the specific case of using nbhood-land-and-sea with topographic aware neighbourhoods, the land points are processed using ApplyNeighbourhoodProcessingWithAMask.process while sea points are processed using NeighbourhoodProcessing.process which gives rise to the mismatch in the dimension coordinate ordering. These functions should pass output that has consistent ordering of the dimension coordinates.
As a general point, the NeighbourhoodProcessing.process function in its current form will produce outputs that have a different dimension coordinate ordering to the input cube.
Acceptance criteria:
Establish what is the desired behaviour for the NeighbourhoodProcessing.process function
Update relevant functions to provide consistent dimension coordinate ordering for neighbourhood CLIs
Passing in-vicinity output through the
nbhood-land-and-seaCLI (when using topographic aware neighbourhoods) currently fails due to aValueErrorbeing raised when the land/sea data is combined back into a common cube. The issue raised is the following:Tracing the issue back through the code, it stems from differences in how the
NeighbourhoodProcessing.processandApplyNeighbourhoodProcessingWithAMask.processfunctions handle dimension coordinate ordering for the resultant cube. In the latter case, the result is compared against the input cube and then passed through thecheck_cube_coordinatesfunction to give consistent ordering with the input cube. This check does not occur withinNeighbourhoodProcessing.processand so the resultant cube shape can differ from that of the input cube.In the specific case of using
nbhood-land-and-seawith topographic aware neighbourhoods, the land points are processed usingApplyNeighbourhoodProcessingWithAMask.processwhile sea points are processed usingNeighbourhoodProcessing.processwhich gives rise to the mismatch in the dimension coordinate ordering. These functions should pass output that has consistent ordering of the dimension coordinates.As a general point, the
NeighbourhoodProcessing.processfunction in its current form will produce outputs that have a different dimension coordinate ordering to the input cube.Acceptance criteria:
NeighbourhoodProcessing.processfunction