SLSTR processing fails for atypical granule sizes

[simonrp84]

By default, SLSTR granules for VIS channels are 2400 x 3000 pixels.
But, on occasion, the granules may be of a different width, I have seen granules with 2401 rows (common), 2402 rows (rare) and 2399 rows (pretty rare).

As an example, this granule has 2401 rows: S3B_SL_1_RBT____20200818T170019_20200818T170319_20200818T185402_0180_042_240_2700_LN2_O_NR_004.SEN3

When passing one of these odd sized granules to ORAC, processing will fail with this error:

 Reading geometry data for SLSTR geo grid
 Reading SLSTR data for band           1
 ERROR: ncdf_read_file(): Could not read variable S1_radiance_an
 NetCDF: Start+count exceeds dimension bound

As we're expecting 2400 rows but actually get, in this case, one more.

This should be dealt with by the ORAC preprocessor, either by reading the data and sizing arrays correctly or by dumpig the first or last row of data.
As a side effect, this will also require checking of the VIS-TIR alignment.

[adamcpovey]

How?!? read_slstr_dimensions() uses get_slstr_gridsize() to read the dimension lengths from the file before allocation.

Like, I believe you that it's wrong but I thought I'd fixed that and I'd like to know how I failed yet again.

[simonrp84]

I think the dims are based on the TIR data, then multiplied by two for the VIS chans on the assumption that the 0.5km VIS should mean twice as many pixels as 1km TIR.

[adamcpovey]

That would do it.