GRIB2 file stored in scanning mode 160
======================================

This record exercises the fix for
[#3535](https://github.com/dtcenter/MET/issues/3535), where MET computed the
wrong data index for GRIB2 scanning mode 160 and read past the end of the
decoded data array.

`scan_mode_160.grib2` holds the same geographic field as the single `TMP`/`P500`
GRIB2 record of `model_data/grib2/sref_mn/sref_mean_2012040821_F003.grib2` in
the unit test input data, stored in scanning mode 160 instead of mode 64. Mode
160 sets bits 1 and 3 of
[GRIB2 Flag Table 3.4](https://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_doc/grib2_table3-4.shtml),
so the points are stored column by column, the i direction runs east to west,
and the j direction runs north to south.

The field is unchanged, only its storage order differs, so MET must produce the
same data plane from this file as from the original record. That is what makes
the file a regression test rather than a smoke test: a wrong index mapping
changes the plotted field, and an index mapping that leaves the array changes
the data range. On the 185 x 129 grid used here, the defective expression
reached 56 elements past the end of a 23,865 element array, and the resulting
plane reported a minimum of 0 K against a true minimum of 241 K.

How it was made
---------------

1. Extract the single record and convert it from its original JPEG2000 packing
   to simple packing, so the packed values can be reordered without re-encoding:
   ```
   grib_copy -w shortName=t,level=500 sref_mean_2012040821_F003.grib2 src.grib2
   grib_set -s packingType=grid_simple src.grib2 simple.grib2
   ```
2. Parse the GRIB2 sections, read the 23,865 packed 9-bit integers out of
   Section 7, and permute them from the mode 64 order, `y*Nx + x`, into the mode
   160 order, `(Nx-x-1)*Ny + (Ny-y-1)`, where x increases east and y increases
   north.
3. Write the permuted integers back into Section 7 and set the scanning mode
   octet, Section 3 octet 65 for Grid Definition Template 3.30, to 160.

Because only the stored order changed and the packing parameters were left
alone, the decoded values are bit for bit the same set. `grib_get_data` on this
file and on `simple.grib2` produce identical sorted latitude, longitude, value
triples.

Note that `grib_set` on the scanning flags alone relabels the record without
reordering the data, which produces a file that is valid but no longer holds the
original field. That shortcut is good enough to show the out of bounds read, but
not to prove that a corrected index is right, which is why the values are
permuted here.