Better interface between MARBL parameters and GCM driver

[mnlevy1981]

This will address part of #11 and all of #51

1. marbl_parms_mod.F90 will be home to all MARBL namelist variables (expanding definition of "parameters" in design document to mean anything set via namelist, differentiated from "configuration" which is set by the complexity level / tracer modules you want from MARBL: ciso_on is a configuration setting, as are autotroph and zooplankton counts. [Gray area: actual autotrophs and zooplankton used in the run?]
2. MARBL will use marbl_parms_define() to set up meta-data: sname, lname, units, type
3. We will provide the following routines to access / set parameter values:
   1. marbl_parms_put(): takes short name (or index?) and value as arguments, sets appropriate parameter to desired value
   2. marbl_parms_get_metadata(): either take index as intent(in) and return any (or all) metadata via optional arguments, or take short name as intent(in) and return rest of metadata
   3. marbl_parms_get_val(): take index or short name as intent(in), return value of parameter as intent(out)

@klindsay28 wants the GCM driver to be able to run the following:

do n=1,marbl_parms_cnt()
  call marbl_parms_get_metadata(n,sname,type)
    select case (trim(type))
      case('r8')
        call marbl_parms_get_val(n, val=r8val)
        print*, trim(sname), " = ", r8val 
      case('i4')
        call marbl_parms_get_val(n, val=i4val)
        print*, trim(sname), " = ", i4val 
    end select
end do

I think we want a similar routine available in MARBL as marbl_parms_write_to_log() that will use MARBL's marbl_log_type to provide the entire list in a pre-determined format (to be clear, I want this in addition to the driver code Keith requested - I think it would be good to have both)

NOTE: we want the driver to use these routines from marbl_interface, so we need something like

module marbl_interface

  use marbl_parms_mod, only : marbl_parms_get_val

  public :: marbl_parms_get_val

Goal: have API finished by May 25 and then we can talk about a marbl_parms_type to store all the parameters or other under-the-covers changes that shouldn't affect the driver.

[mnlevy1981]

I think this ticket will actually address all of #11 because I'll be touching several different modules. Here is what MARBL looks like as of v0.4.0:

• marbl_ciso_mod.F90: CISO tracer module
• marbl_co2calc_mod.F90: compute co2calc for surface, also various co3 terms
• marbl_constants_mod.F90: unitless constants (0, 1, 2, 1000, 1/2) as well as T0_Kelvin and rho_sw
• marbl_diagnostics_mod.F90: store diagnostics in MARBL datatype
• marbl_interface.F90: define marbl_instance... only interaction between GCM and MARBL
• marbl_interface_constants.F90: “constants that need to be shared between public api and private data”
• marbl_interface_types.F90: derived types used by marbl_interface (and GCM)
• marbl_internal_types.F90: derived types used by marbl_interface (but not the GCM)
• marbl_kinds_mod.F90: define kind numbers for integers, reals, and logicals. Also char_lens
• marbl_logging.F90: add messages to MARBL’s status log
• marbl_mod.F90: compute interior and surface forcings / tendencies
• marbl_namelist_mod.F90: routines to help parse namelist (after namelist file has been dumped in string)
• marbl_oxygen.F90: compute Schmidt number of O2 as well as O2 saturation concentration
• marbl_parms.F90: ecosys_parms_nml and also some "true" parameters (c0, c1, etc, as well as some conversion factors and a few common formats for output that are no longer used anywhere)
• marbl_restore_mod.F90: Tracer restoration inside MARBL (applied by MARBL, not GCM!)
• marbl_schmidt_number_mod.F90: compute Schmidt number of CO2
• marbl_share_mod.F90: all MARBL namelist params for ecosys_nml and ecosys_ciso_nml are defined here
• marbl_sizes.F90: contains counts of tracers (ecosys_base, ciso, and marbl_total) as well as zooplankton, autotrophs, and grazer_prey

---

Step 1 to cleaning up marbl_parms.F90 will be moving all the constants to marbl_constants.F90 and deleting the unused formatting variables. Step 2 will be moving the contents of marbl_share_mod.F90 to marbl_parms.F90, which might result in deleting the share module altogether? I should also bring the ecosys_restore_nml variables from ecosys_restore_mod.F90 to marbl_parms.F90.

Other things I'd like to do (but require some discussion first):

• rename marbl_parms.F90 to marbl_namelist_parms_mod.F90, since that seems like a better description of what the module contains
• rename all the namelists so we have &marbl_ecosys_base_nml, &marbl_ciso_nml, &marbl_restore_nml, and &marbl_parms_nml. Clearly this would require a new POP tag as well, but I think it would be worth it.
• Move pi from marbl_ciso_mod.F90 to marbl_constants.F90 (addressing marbl_ciso_set_interior_forcing sets pi every time it is called #36 and use of pi in marbl_ciso_mod.F90 #67 while I'm at it)
• Either move schmidt_o2_surf to marbl_schmidt_number_mod.F90 or move the contents of marbl_schmidt_number_mod.F90 to marbl_co2calc_mod.F90 (a little out of scope for namelist changes, perhaps better suited for Consistent file names #13)

[mnlevy1981]

Step one is [mostly] done on my branch as of d5adaf8 - as noted in a comment from #11 I have put the following in marbl_constants_mod:

• General constants (c0, c1, p5, etc)
• Conversion factors (spd, mpercm, etc)
• Physical constants (T0_Kelvin, rho_sw, R13C_std, etc)

There are still several variables with the parameter attribute in marbl_parms, I don't know if any or all of the following should be in marbl_constants_mod instead:

fe_scavenge_thres1 = 0.8e-3_r8,  & !upper thres. for Fe scavenging
dust_fescav_scale  = 1.0e9         !dust scavenging scale factor
dust_to_Fe=0.035_r8/55.847_r8*1.0e9_r8
caco3_poc_min         = 0.40_r8,  & ! minimum proportionality between 
                                    !   QCaCO3 and grazing losses to POC 
                                    !   (mmol C/mmol CaCO3)
spc_poc_fac           = 0.10_r8,  & ! small phyto grazing factor (1/mmolC)
f_graze_sp_poc_lim    = 0.40_r8,  & 
f_photosp_CaCO3       = 0.40_r8,  & ! proportionality between small phyto 
                                    !    production and CaCO3 production
f_graze_CaCO3_remin   = 0.33_r8,  & ! fraction of spCaCO3 grazing which is remin
f_graze_si_remin      = 0.50_r8,  & ! fraction of diatom Si grazing which is remin
f_toDON               = 0.66_r8
denitrif_C_N  = parm_Red_D_C_P/136.0_r8
thres_z1_auto     =  80.0e2_r8, & !autotroph threshold = C_loss_thres for z shallower than this (cm)
thres_z2_auto     = 120.0e2_r8, & !autotroph threshold = 0 for z deeper than this (cm)
thres_z1_zoo      = 110.0e2_r8, & !zooplankton threshold = C_loss_thres for z shallower than this (cm)
thres_z2_zoo      = 150.0e2_r8, & !zooplankton threshold = 0 for z deeper than this (cm)
CaCO3_temp_thres1 = 4.0_r8,   & !upper temp threshold for CaCO3 prod
CaCO3_temp_thres2 = -2.0_r8,  & !lower temp threshold
CaCO3_sp_thres    = 2.5_r8      ! bloom condition thres (mmolC/m3)
f_qsw_par = 0.45_r8   ! PAR fraction
Tref = 30.0_r8, & ! reference temperature (C)
Q_10 = 1.7_r8     ! factor for temperature dependence (non-dim)
DOC_reminR_light  = (c1/(365.0_r8*15.0_r8)) * dps, & ! remin rate for semi-labile DOC, 1/15yr
DON_reminR_light  = (c1/(365.0_r8*15.0_r8)) * dps, & ! remin rate for semi-labile DON, 1/15yr
DOP_reminR_light  = (c1/(365.0_r8*60.0_r8)) * dps, & ! remin rate for semi-labile DOP, 1/60yr
DOC_reminR_dark   = (c1/(365.0_r8*6.0_r8)) * dps,  & ! remin rate in the dark, 1/6yr
DON_reminR_dark   = (c1/(365.0_r8*5.5_r8)) * dps,  & ! remin rate in the dark, 1/5.5yr
DOP_reminR_dark   = (c1/(365.0_r8*4.5_r8)) * dps     ! remin rate in the dark, 1/4.5yr
DOCr_reminR0      = (c1/(365.0_r8*16000.0_r8)) * dps, & ! remin rate for refractory DOC, 1/16000yr
DONr_reminR0      = (c1/(365.0_r8*9500.0_r8)) * dps,  & ! remin rate for refractory DON, 1/9500yr
DOPr_reminR0      = (c1/(365.0_r8*5500.0_r8)) * dps,  & ! remin rate for refractory DOP, 1/5500yr
DOMr_reminR_photo = (c1/(365.0_r8*18.0_r8)) * dps       ! additional remin from photochemistry, 1/18yrs over top 10m
DOCprod_refract  = 0.01_r8,                   & ! fraction of DOCprod to refractory pool
DONprod_refract  = 0.0115_r8,                 & ! fraction of DONprod to refractory pool
DOPprod_refract  = 0.003_r8,                  & ! fraction of DOPprod to refractory pool
POCremin_refract = DOCprod_refract * 0.06_r8, & ! fraction of POCremin to refractory pool
PONremin_refract = DONprod_refract * 0.03_r8, & ! fraction of POCremin to refractory pool
POPremin_refract = DOPprod_refract * 0.06_r8, & ! fraction of POCremin to refractory pool
DOCriv_refract   = 0.2_r8,                    & ! fraction of DOC river input to refractory pool
DONriv_refract   = 0.1_r8,                    & ! fraction of DON river input to refractory pool
DOPriv_refract   = 0.025_r8                     ! fraction of DOP river input to refractory pool

At the very least, denitrif_C_N depends on parm_Red_D_C_P, and I assumed everything with parm_ was in the correct place already (perhaps a faulty assumption)

[mnlevy1981]

Step two is also done as of 5409968; I did end up removing marbl_share_mod and I moved ecosys_restore_nml into marbl_parms as well. So I think I'm finally ready to start prototyping the marbl_parms_type.

In the "things to discuss" section above, I mentioned cleaning up pi -- I did move that variable from marbl_ciso_mod to marbl_constants (and hard-coded it to 3.14159265358979323846_r8 which is bit-for-bit with using 4*atan(1) with yellowstone_intel).

[mnlevy1981]

The marbl_config_and_parms_type class has get, put, inquire_metadata, and inquire_varid to allow access to individual configuration variables and parameters from the driver. Additionally, all configuration variables and parameters will be written to the log once the GCM can no longer change them (discussion question: currently this is done automatically in MARBL, but should it instead be up to the GCM to decide if these values should be logged or not?)