Strange mesh output for the Cartesian domain in LFRic

[Alex Corbett (CorboPy)]

On the back of #466, I am interested in implementing a reshaping/regridding app for the Cartesian domain that would be analogous to the postproc_lfric app used in the regional configuration (e.g. u-dw842), but I've noticed some confusing mesh outputs depending on the name of the NetCDF file and was hoping someone might be able to provide some clarity on this!

There seems to be something special about the name lfric_diag.nc as defined in the file_def_diags.xml. If named this way, the mesh output gives x/y projection coordinates in metres, as expected for the Cartesian domain. If named differently, however, the output mesh incorrectly gives lat/lon coordinates in degrees, which suspiciously are the same digits but a factor of 10⁴ out compared with the projection x/y coordinates (or a factor of 10 too small if naively converting to km). See the example below for a 128x128 grid with 2km spacing:

The projection x/y coordinates output by lfric_diag.nc (in metres) for upward_air_velocity:
[-126999.99809265, -125000, -123000.00190735, ..., 123000.00190735, 125000, 126999.99809265]

The lat/lon coordinates output when diagnostic file is called something other than lfric_diag.nc (in degrees) for upward_air_velocity:
[-12.699999809265137, -12.5, -12.300000190734863, ..., 12.300000190734863, 12.5, 12.699999809265137]

Note the similarity in the digits here, which makes me suspect the same underlying coordinates are being written but interpreted differently depending on the filename. I’d really appreciate some clarification on this behaviour.

Side note: would someone also have an answer as to why the projection x/y coordinates aren't simply -127000, -125000, -123000, etc? What is the reason behind the extra .00190735 / .99809265?

[iboutle]

Not an answer, but the "lfric_diag.nc" file is very dangerous to use, and generally should be avoided. It does not use xios as setup in the xml file, but instead has various things over-written and post-processed from within the model. This, for example, over-writes the time frequency and processing of the output, so that you won't get what you are expecting to get from what is specified in the xml file. It appears it also over-writes the axis labels to make things work "correctly" for a Cartesian mesh!

[cjohnson-pi]

As Ian says, the lfric_diag file has some extra processing applied. For example fix_planar_coordinates in lfric_xios_process_output_mod (lfric_core) which includes a scaling factor. As to why the meshes are not quite exact, I think its because at the moment they are created incrementally. i.e. dx keeps being added on. I have a new ticket to create them by scaling a unit mesh (MetOffice/lfric_core#270, should be included this release). So this should remove the extra bits.

[Ed Hone (EdHone)]

Hi Alex - I believe I can answer your question.

XIOS (the I/O server used by LFRic) has hard-coded assumptions that the only coordinate data is lat/lon and therefore cuts off the coordinates at 360. This means that the coordinates of our non-global domain models would get cut off at 360, which is obviously a problem for models which have their mesh coordinates in metres, rather than degrees. A workaround was introduced using the NetCDF packing infrastructure (https://code.metoffice.gov.uk/trac/lfric/ticket/3110) . Native NetCDF reading tools should automatically multiply the data of a field by the provided scale_factor attribute.

Ian is right about the lfric_diag file name being treated differently in the model but without this treatment the coordinate data would not be correct

[Alex Corbett (CorboPy)]

Thank you all for your input on this. As I'm sure you can understand, I have a few follow-up questions!

1. Is this scaling_factor_xyz arbitrarily set to 10⁴? Does this mean the 'limit' for the size of the planar domain would then be 3600kmx3600km? (360*10⁴ m)
2. Just to make sure, is scaling_factor_xyz at all related to the scaling_factor planet parameter in the namelist?
3a. If we're not supposed to use lfric_diag.nc, doesn't this make the whole fix_planar_coordinates post-processing workaround a bit useless?
3b. What other post-processing occurs on lfric_diag.nc to make it not recommended?
4. Is there any chance we could get some documentation for new LFRic users on this somewhere? Please :)
5. Are there any future plans to reconfigure/update the underlying XIOS assumptions for inherent planar domain support?