Inconsistent handling of multiple non-spatial dimensions within nbhood-land-and-sea

[benowen-bom]

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