MARBL Support

[mnlevy1981]

When NCAR/MOM6#157 is merged, this PR will be required to build CESM + MARBL. I think this branch is fully functional, but there may be a few small tweaks to things like default parameters or diag table settings. Replaces #75 to reflect the master -> main renaming.

I'll take it out of draft status once the MOM6 PR is ready for review.

[mnlevy1981]

It turns out this block is necessary -- without it, h.bgc.native, h.bgc.daily, and other h.bgc.* streams are not archived. I wonder if one fix would be to change lines 5 and 6:

    <!-- match filenames of the form
-         h[.optional stream name][._optional instance number].(date string).nc[.optional tile number] -->
-    <hist_file_extension>h(\.\w+)?(\._\d*)?\.[-\d+]+\.nc(\.\d*)?$</hist_file_extension>
+         h.stream_name.[.optional stream name][._optional instance number].(date string).nc[.optional tile number] -->
+    <hist_file_extension>h\.\w+(\.\w+)?(\._\d*)?\.[-\d+]+\.nc(\.\d*)?$</hist_file_extension>

We don't generate a mom6.h, do we? I'm going to leave this file as-is, but we can revisit it after it's merged -- I don't want to get side-tracked going down a rabbit-hole of testing various possible changes when this works and removing it doesn't.

[mnlevy1981]

dbe3d4e got most of the easy-to-implement suggestions from the code reviews, and then c0c8d88 ran black on the scripts that I had created to help buildnml call python code from the MARBL repo. Still remaining

• Investigate whether my FMS changes are actually necessary, or if they can go in input_nml.yaml instead
• Add G1850MOMMARBL tests to prealpha and prebeta (SMS in former, ERS in latter... this should've happened in dbe3d4e!)
• Merge in latest main. The switch from manage_externals to git fleximod is going to be a little intrusive (we'll move MARBL from ${MOM_interface}/MOM6/pkg/MARBL to ${MOM_interface}/externals/MARBL since ${MOM_interface}/MOM6 isn't actually part of MOM_interface), and then I'll need to update buildlib and the stand-alone examples.

I did not look into replacing standalone/examples with a sparse checkout of MOM6-examples; that seems like something to tackle after this PR is merged in because we'll need to decide if we want to support our own fork or use the same code as GFDL before adding single_column_MARBL/ to that repo. I also didn't look at having create_newcase create an empty user_nl_marbl file (that's definitely a feature I'd like to have in the future, but it's not necessary in the first pass), nor did I add default values to all the MARBL parameters because we don't want them in MOM_input unless we are running MARBL (maybe I'm misinterpreting my notes on that suggestion?).

[mnlevy1981]

Investigate whether my FMS changes are actually necessary, or if they can go in input_nml.yaml instead

I do need to open an FMS PR to handle two changes

diff --git a/affinity/affinity.c b/affinity/affinity.c
index fff6622f..10b5a753 100644
--- a/affinity/affinity.c
+++ b/affinity/affinity.c
@@ -48,7 +48,7 @@
  * gettid function for systems that do not have this function (e.g. on Mac OS.)
  */
 #ifndef HAVE_GETTID
-static pid_t gettid(void)
+pid_t gettid(void)
 {
 #if defined(__APPLE__)
   uint64_t tid64;
diff --git a/diag_manager/diag_data.F90 b/diag_manager/diag_data.F90
index a1f59470..6791f91c 100644
--- a/diag_manager/diag_data.F90
+++ b/diag_manager/diag_data.F90
@@ -64,7 +64,7 @@ MODULE diag_data_mod
   PUBLIC

   ! Specify storage limits for fixed size tables used for pointers, etc.
-  INTEGER, PARAMETER :: MAX_FIELDS_PER_FILE = 300 !< Maximum number of fields per file.
+  INTEGER, PARAMETER :: MAX_FIELDS_PER_FILE = 500 !< Maximum number of fields per file.
   INTEGER, PARAMETER :: DIAG_OTHER = 0
   INTEGER, PARAMETER :: DIAG_OCEAN = 1
   INTEGER, PARAMETER :: DIAG_ALL   = 2

The former is necessary for building MOM6 with solo_driver instead of the NUOPC cap, and the latter is necessary because the test suite includes every possible MARBL output field.

[mnlevy1981]

I do need to open an FMS PR

That PR is ESCOMP/FMS#2