refactor bkgerrstddev into a saber block

[travissluka]

Description

This PR converts the existing BkgErrGodas linear variable change into a ParametricOceanStdDev saber block (that lives in the SOCA repo for now), written in C++

• closes BkgErrorGODAS needs a QC step #833 (most likely)
• closes move BkgErrGodas to a saber outer block #1004

jedi-ci-test-select=intel

Why?

• This is the first step in generalizing the code enough to be moved out of the SOCA repo and into SABER. Similar to what was done with diffusion, I'll save moving it out of SOCA for a later PR (once we're sure it works as intended and is indeed generic)
• I need to move this into a saber block if I want to move the balance operator into a saber block (which I do want to do)
• It's slightly faster and uses slightly less memory, since we are no longer going in and out of the Fortran code (see timings below)
• By default, this saber block uses the oops::Diffusion class to smooth the resulting stddev by the length scales. Much less noisy now (see images below), the scales by which the fields are smoothed can be configured. Unlike with the correlation operator, no offline parameters need to be calculated to use the smoothing (since there is no normalization)
• By being in C++, now all the yaml parameters are checked when they are read in. No more accidentally setting wrong parameters that don't do anything!
• the "other variable" section (eg. all variables other than T/S/SSH) was hardcoded in the Fortran. This removes that hardcoding and allows for a "fraction of background / min / max" to be set for any input variable

Also,

• I fixed a bug where the values along the bottom level were too large (not sure how we missed that before), (see images below)

Usage:

The saber block has reasonable default values set (in an effort to keep outside collaborators from trying to do crazy things), so, for example you could use a minimum yaml such as

- saber block name: SOCAParametricOceanStdDev
  temperature:  # use defaults other than SST input file
    sst:
      filepath: data_static/godas_sst_bgerr.nc
      variable: sst_bgerr
  unbalanced salinity: {} # use default values
  unbalanced ssh: {} # use default values

this will still enable the smoothing by default.

Or, if you want to set parameters explicitly, see what is given in the testinput/dirac_parametric_ocean_stddev.yml file, or look at the parameters class in src/soca/SaberBlocks/ParametricOceanStdDev/ParametricOceanStdDev.h (real documentation will be coming, I promise!)

Testing

• All ctests have been updated
• a 1/4 deg test has been run. background error is less noisy, doesn't have the bug at the bottom, and the multiply is faster

This is the T bkg error at lvl 15 (very noisy

Same level but with this new saber block, where the stddev is smoothed by the Rossby radius

[kbhargava]

🎉

[Dooruk]

Nice, our group has been looking at this part of the code lately and we are coming up with some questions. Could we expand on the parametric part, for instance bumping SSS error around major river outputs? We could use a static "river map" input of sorts and this could be an optional setting.

One (obvious) thought we were pondering beyond this is to be able to use atmospheric fields, say cloud cover for large storms. Other than surface fluxes, can SOCA access/utilize any atmospheric fields? Is jcsda-internal/coupling the only way of doing that properly? If fv3-jedi is used at each cycle in a weakly-coupled sense, can any fields be utilized within the SOCA context?

Also, please keep the documentation effort going like you mention here. soca-tutorial has been super helpful 🙏

[travissluka]

Nice, our group has been looking at this part of the code lately and we are coming up with some questions. Could we expand on the parametric part, for instance bumping SSS error around major river outputs? We could use a static "river map" input of sorts and this could be an optional setting.

One (obvious) thought we were pondering beyond this is to be able to use atmospheric fields, say cloud cover for large storms. Other than surface fluxes, can SOCA access/utilize any atmospheric fields? Is jcsda-internal/coupling the only way of doing that properly? If fv3-jedi is used at each cycle in a weakly-coupled sense, can any fields be utilized within the SOCA context?

Also, please keep the documentation effort going like you mention here. soca-tutorial has been super helpful 🙏

@Dooruk, yes. The easiest and most flexible thing for me is to make the SSS error read from a file like the SST error is. I can add that capability in a follow-up PR. We could read in atmospheric fields, but that would require you to interpolate them onto the MOM grid offline, then add them to the MOM state.

[travissluka]

This is ready for merge. Does anyone else have time for a second review? (@guillaumevernieres @Dooruk ?)

[HamidehGMAO]

It looks good to me! and it builds fine and all the tests pass except the test 39 for ref. mismatch reasons. I do not see it failing in travis-CI. Anyway it isn't related to this PR.

[travissluka]

It looks good to me! and it builds fine and all the tests pass except the test 39 for ref. mismatch reasons. I do not see it failing in travis-CI. Anyway it isn't related to this PR.

@HamidehGMAO running on Discover I'm assuming? Intel or GCC? It would be nice to update the reference answers at some point.

[HamidehGMAO]

yeah! running on discover and using intel, spack stack 1.7

[Dooruk]

ignore this comment

I'm now updating our workflow for the sprint name changes + this particular PR.

[Dooruk]

Well, I just tested 5-deg within the Swell context rather than my sandbox and it worked there.. so it was just a fluke. I will test with 0.25-deg next.