Enable choice of LFRic-Atlas map

[ctgh]

As mentioned in #53 we have noticed problems when saving an increment file (produced by an ETKF routine) to netCDF. In essence, the mapping between the 'LFRic' and the 'Atlas' coordinates mixes the locations up such that the increments are saved to the incorrect spatial location.

This PR enables the user to select one of two LFRic-Atlas mapping methods (trivial, which simply counts up from 0, and KDtree, which is the existing method).

This is a draft for two reasons:

• It has not been tested,
• It's probably better to understand exactly why this is necessary in the first place, rather than providing a sticking plaster that may not work properly in the future.

Given that, it would still be very interesting to get some early reviews on this.

Coordinate merge

• lfric-jedi PR to be added

[mo-joshuacolclough]

It would be good to check with Rick maybe if this has come up in the science testing before (maybe this has happened already)...

Having looked through MONIO what I think could be happening is that the data is being mapped back from Atlas space to LFRic space, but the lon/lat locations that are written to the file are not - it should be happening here:

monio/src/monio/UtilsAtlas.cc

Line 91 in 081b1bb

for (const auto& atlasCoord : atlasCoords) {

So you end up with the variable being mapped to the correct LFRic data location in the file, but linked to the Atlas lon/lats, so when plotted it puts the data at the atlas locations (flipped). I can make a branch if you would be happy to test it with plots? Thanks

Perhaps, this is not an issue for the science because when LFRic reads in the variables, they are in the correct data order in the file, they just have strange lon/lats (which are ignored because LFRic reads these from a separate mesh file - I believe...)

[mo-joshuacolclough]

It would be nice to see a switch (lfricAtlasMapMethod) { case ... } for this (very minor change!) - but maybe worth holding off until we understand the issue

[ctgh]

@mo-joshuacolclough Thanks for your quick reply about this. If it's not too much trouble, I would be happy to test a branch with your proposed fix. I'd also be willing to try implementing it if you are short of time.

I was wondering why this hasn't been seen before, e.g. when plotting the output produced by the 3d-FGAT ctests in lfric-jedi. It would be good to verify any proposed fixes in those ctests, as well as malak + c3po. I don't want to entirely rule out the possibility that the ETKF tests are configured incorrectly.

[ctgh]

Closing this as it appears the problem was in the lfric-jedi geometry iterator. So far testing indicates that fixing the iterator solves the problems. If there are any anomalous results I will take another look.