Spear ecda

[MJHarrison-GFDL]

These updates are supporting the SPEAR online ensemble data assimilation system using MOM6. This update includes minor changes to existing interfaces, as well as a complete implementation of the online incremental updates returned from the ensemble filter routine. A background temperature and salinity increment (e.g. an ensemble climatology of previous increments) read from file can be enabled using the APPLY_TRACER_TENDENCY_ADJUSTMENT option .

[MJHarrison-GFDL]

Comment from @Hallberg-NOAA : Why is oda_CS%h initialized to "Angstrom_m" instead of zero? This will cause the SPEAR data assimilation configuration to fail dimensional consistency tests.

[MJHarrison-GFDL]

Added dimensional rescaling for DA thickness initialization.

[codecov]

Codecov Report

Merging #1453 (bab9c91) into dev/gfdl (ebd0393) will decrease coverage by 0.03%.
The diff coverage is 0.61%.

❗ Current head bab9c91 differs from pull request most recent head 88da4c9. Consider uploading reports for the commit 88da4c9 to get more accurate results

@@             Coverage Diff              @@
##           dev/gfdl    #1453      +/-   ##
============================================
- Coverage     29.08%   29.04%   -0.04%     
============================================
  Files           236      236              
  Lines         71294    71391      +97     
============================================
  Hits          20736    20736              
- Misses        50558    50655      +97     

Impacted Files	Coverage Δ
src/core/MOM.F90	58.60% <0.00%> (-0.17%)	⬇️
src/ocean_data_assim/MOM_oda_driver.F90	0.00% <0.00%> (ø)
config_src/infra/FMS1/MOM_interp_infra.F90	42.85% <50.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ebd0393...88da4c9. Read the comment docs.

[marshallward]

Gaea regression: https://gitlab.gfdl.noaa.gov/ogrp/MOM6/-/pipelines/13511 ✔️

[Hallberg-NOAA]

I have examined this code, and overall it seems to be correct, so I am approving this PR.

There is, however, one minor point that we may want to address in a subsequent PR. The description of the new optional arguments correct_leap_year_inconsistency to the two init_extern_field() functions, which are inherited from the underlying FMS code, as "If present and true, then allow for leap year inconsistency" is confusing to me. Does this option fix the problem or allow it to persist? We should clarify these two comments at some point to unambiguously describe what this argument actually does.

[adcroft]

There is, however, one minor point that we may want to address in a subsequent PR. The description of the new optional arguments correct_leap_year_inconsistency to the two init_extern_field() functions, which are inherited from the underlying FMS code, as "If present and true, then allow for leap year inconsistency" is confusing to me. Does this option fix the problem or allow it to persist? We should clarify these two comments at some point to unambiguously describe what this argument actually does.

Just for reference, the relevant bit of FMS code is https://github.com/NOAA-GFDL/FMS/blob/main/time_interp/time_interp_external.F90#L590-L594 .

[Hallberg-NOAA]

There is no description of this correct_leap_year_inconsistency argument in time_interp_external.F90, but there is a description of this argument (repeated identically 3 times) further into the FMS code in time_interp.F90, for example at https://github.com/NOAA-GFDL/FMS/blob/a7b4e6d5dce7853366834203107977d3f4a1f0cd/time_interp/time_interp.F90#L492-L499. However, even after reading this description in the FMS code, I still don't have a clear idea what this argument is intended to do. Is argument this to allow for datasets with a leap year to be used in models that do not use a leap year (by skipping the extra day of input data), the reverse (by duplicating a day of input data), or something even more obscure to do with the difference between the leap years in Gregorian and Julian calendars? If we are adding an optional argument to MOM6 code, its function should be clearly described.

[Hallberg-NOAA]

With the updated comments, this finally makes sense to me. Thank you @MJHarrison-GFDL !