Writing out file changing lbnrec

[Rhiannon Davies (rsdavies)]

If I read in a UM dump file (e.g. a glu_t+3 file) using

glu = mule.DumpFile.from_file(glu_t+3)

and then immediately write it out again,

glu.to_file('out')

Then the lbnrec (position 30 in the header) is doubled for all the fields. No other element is affected (e.g. the packing code remains the same)

According the the UMDP F03, lbnrec is defined as:

Dumps and Ancillary files with well-formed records : Length on disk which is number of words (after
packing for packed fields). The length includes rounding up to an exact number of sectors. Sector
length currently in use is 2048 words.

I suspect there is an issue with the packing, or at least, with the calculation of lbnrec as various other tools (xconv/iris) read the files fine.

Is this a known issue, or is there a better way to save my file to ensure its not got this problem?

[Yaswant Pradhan (yaswant)]

John Edwards flagged this recently. I think what you see is related..

While helping in the debugging of an ancillary problem in pre-operational trialling of PS47, I have come across something which looks like an oversight in updating https://code.metoffice.gov.uk/doc/um/latest/papers/umdp_F03.pdf. In the discussion of Word 160 on p.11 and again in the discussion of LBNREC on p.26, it is stated that the sector length is 2048 words. I believe this was the case up to UM 7.9 (the file SCRIPT in old jobs up to UM7.9 sets UM_SECTOR_SIZE to 2048), but from UM8.0 onwards this has been changed to 512. The variable has been renamed as io_field_padding (set in io_services/common/io_configuration_mod.F90), where it is set to 512, and this is also the setting in mule and ANTS.