generate_clearsky_solar_radiation fails if target grid does not have y dimension first

[btrotta-bom]

The cli generate_clearsky_solar_radiation fails if the target_grid argument does not have the y dimension as its first dimension. It should either handle this case or throw a useful error. Example below.

from improver.cli import generate_clearsky_solar_radiation
import datetime as dt
import numpy as np
from iris.coords import DimCoord
from iris.cube import Cube


lat = DimCoord(np.arange(0, 50, 10), standard_name="latitude")
lon = DimCoord(np.arange(0, 90, 10), standard_name="longitude")
target_grid = Cube(np.ones((len(lat.points), len(lon.points)), np.float32), long_name="grid", dim_coords_and_dims=[(lat, 0), (lon, 1)])
surface_altitude = target_grid.copy(data=np.zeros(target_grid.shape))
surface_altitude.rename("surface_altitude")

# works
cube = generate_clearsky_solar_radiation.process(target_grid, surface_altitude, time=dt.datetime(2025, 1, 1), 
                                                accumulation_period=24, temporal_spacing=30)
# fails
target_grid.transpose([1, 0])
cube = generate_clearsky_solar_radiation.process(target_grid, surface_altitude, time=dt.datetime(2025, 1, 1), 
                                                 accumulation_period=24, temporal_spacing=30)

[benowen-bom]

One thing worth calling out here is that the netcdf conventions specify that spatial coordinates should be ordered as t, z, y then x (see here). So the expectation of the coordinate ordering above is not unreasonable, but agree that in the case that coordinate dimensions don't follow this pattern that a useful error is raised.

[btrotta-bom]

The target grid was from our improver ancils repo, so I guess we are not following the convention!

[benowen-bom]

The target grid was from our improver ancils repo, so I guess we are not following the convention!

OK. That's concerning and something we should fix. That being said, I was curious as to why this was not failing within the suite and it the reason is that the improver load function enforces coordinate ordering. So using the CLI will utilise these load functions and the data will be in the ordering that is expected (and cf-compliant). However, using the the plugin directly, this may not be the case if individuals have used a different load function (ie iris.load_cube). So I think the action here should still be to add a reasonable error (and for us to fix our grid ancils!).