Modify field definitions in XML file

[Harry Shepherd (harry-shepherd)]

I am looking at the packing of LFRic output data, using the rose-stem test invoked by:

g=lfric_atm_nwp_gal9-C896_MG_720t_perfRun0_ex1a_cce_production-32bit

To look at the packing I have modified the diagnostic field definitions by adding the XML properties add_offset, scale_factor, and prec to certain fields in field_def_diags.xml.

The model then fails with error

In file "yacc_parser.yacc", function "int yyerror(const char *)",  line 139 -> Parsing error: syntax error

I think my XML changes are properly formed and match what XIOS expects, and I guess I have the following questions

• Is this thing actually parsing the XML files, and if so why?
• Can I get the syntax error to see what mistake I've made?
• Am I going about modifying a field definition to add these parameters in the correct way? If not how should I do it?

[Harry Shepherd (harry-shepherd)]

I've somewhat resolved my own problem, instead of making the changes to the field_def_diags.xml file, I instead made them to file_def_diags_idealised.xml, and the model now behaves and runs how I would expect.

[iboutle]

Not really sure I follow this Harry - field_def_diags seems like the place that you should be making some changes, i.e. this is the definition of the diagnostic fields (single source of truth), and I think we would want the packing information to be part of this? file_def_diags_idealised just determines which diagnostics are output by a particular run, and isn't used by the C896 job you point to (which may be why it then works?!)

[Harry Shepherd (harry-shepherd)]

I've got the C896 job running packing some (quite a bit of) data putting the packing information in the file_def files.

I think by putting the packing information in the field definitions it would make it hard to switch between (for example) packed and unpacked data runs, let alone if any sort of packing profiles want to be used with LFRic.

[iboutle]

My reasoning for not wanting the packing information in the file_def, is that this lives in the suite - we have absolutely no ability to control what is done in this file - there will be a million different copies of it out in the wild, and it will be entirely at the whim of individual users what they do with it - it's a recipe for chaos!

The field_def on the other hand lives on trunk - we have 1 copy of it and changes to it need to go through review. This feels like the right place for packing information to live (in the same way it lives in the stashmaster for the UM). My thought on how we'd deal with this (in the short-term at least) would be to have multiple copies of the field_def for different packing profiles (e.g. field_def_unpacked, field_def_nwp_packing, field_def_climate_packing), and then the suite can choose which packing profile it wants by selecting the appropriate field_def file - and then all fields are packed to the appropriate precision (again, similar to how we select the packing profiles in the UM).

That of course does nothing to address why doing so doesn't work, but if XIOS doesn't support adding packing information to the field_defs, we'd probably need to think about some other way of controlling this information outside of the user-defined file_defs.