NEMOVAR interface to orca-jedi/JEDI

[frld]

Description

Include code to allow orca-jedi and NEMOVAR to interface.

More details to follow...

I've created a branch with some developments but note this is not necessarily the final form the interface will take

https://github.com/MetOffice/orca-jedi/tree/feature/nemovar_interface

Acceptance Criteria (Definition of Done)

TBC

Dependencies

TBC

[twsearle]

One note would be, I think its important to ensure we can build without nemovar for compatibility with the NG-PAO project. So at the CMAKE level perhaps we can use a switch to decide whether we build with nemovar interface or not?

[twsearle]

I have been looking over examples in SABER and trying ot understand your prototype change. I think it would be better if we could get the part of your change that lives in the saber namespace into saber itself, similar to the way this is done for NOAAs GSI. They package their covariance fortran routines as a library and then interface to them as part of saber if the library is found:

Here is the switch they use: https://github.com/JCSDA-internal/saber/blob/48c0f95b83a946277d8c7bcd7c95af898f0d8da3/CMakeLists.txt#L75

and the GSI stuff is here: https://github.com/JCSDA-internal/saber/tree/develop/src/saber/gsi

[frld]

I have been looking over examples in SABER and trying ot understand your prototype change. I think it would be better if we could get the part of your change that lives in the saber namespace into saber itself, similar to the way this is done for NOAAs GSI. They package their covariance fortran routines as a library and then interface to them as part of saber if the library is found:

Here is the switch they use: https://github.com/JCSDA-internal/saber/blob/48c0f95b83a946277d8c7bcd7c95af898f0d8da3/CMakeLists.txt#L75

and the GSI stuff is here: https://github.com/JCSDA-internal/saber/tree/develop/src/saber/gsi

That's useful I guess they've pioneered a way to get my NEMOVAR interface into SABER. Although NEMOVAR does it's own geometry setup and so a user would need to some extra work to use a non-standard grid. Perhaps GSI is more generic and can use the altas geometry data directly which may aid in its SABER acceptability.

I'm giving a DA science meeting talk next week (3 Dec at 11am) about my JEDI work and I'll make a point to raise the question about where to put the interface code.

[twsearle]

@frld sounds good to me! My reasoning that this belongs in SABER is really from a few different directions:

1. SABER users of other models might be surpised to learn that SABER is changed by the inclusion of this model interface - this could have unintended consequences for them.
2. Compiling functions in the SABER namespace without being in the SABER repo represents poor separation of concerns - it makes the code harder to understand as the capabilities are not isolated to SABER. e.g what if someone develops a new and better NEMO model interaface and wishes to use the SABER interface to nemovar? If it is in SABER it is just a configuration, if it is in orca-jedi then they would need to copy code across to the new model interface. This introduces a much higher maintainance burden and multiple versions of the same thing.
3. Most importantly, adding the nemovar ABI to SABER has the benefit that any change to SABER that might affect NEMOVAR would be naturally visible to the SABER developer making the change. This increases the liklihood of them maintaining the interface as SABER changes and keeping it working, or at least flagging issues of compatibility early.

[frld]

I've opened an issue on the SABER repo https://github.com/JCSDA-internal/saber/issues/980