How to turn on CISO while rivers are turned off?

[shiannder]

I am running CESM 2.2 compset G1850ECOIAF with rivers turned off, by changing the code in ecosys_forcing_mod.F90 file. Specifically setting river flux DOC to false.

• lhas_riv_flux(doc_ind) = .false.
• lhas_riv_flux(docr_ind) = .false.

I have turned on C isotopes with ciso=true in the user_nl_marbl file which has worked before for me. However, the run does not give me the 92 ciso variables that I should have. I have looked thru the 4 marbl_ciso files to see if there is any river ciso variable to address, but they all have nothing on river carbon isotopes (marbl_ciso_diagnostics_mod.F90, marbl_ciso_init_mod.F90, marbl_ciso_interior_tendency_mod.F90, marbl_ciso_surface_flux_mod.F90 ).

Does anyone know how to turn on the C isotopes with rivers off?
Does setting the "doc_ind=false" affect the ciso variables turning off?

 

[erik]

This would be better in the more focused Ocean model BGC, MARBL section. So moving there.

 

[erik]

@mlevy can you answer this? Thanks...

 

[mlevy]

I'm a little confused by your post -- you seem to be conflating POP and MARBL as well as ocean BGC riverine fluxes and the full river runoff component. So let me try to address that first, and then I'll answer the questions I think you're asking.

1. There is a river runoff model that dumps fresh water into the ocean; this affects salinity (and possibly temperature?) in the ocean, but is separate from riverine nutrients.
2. MARBL doesn't know anything about riverine nutrients; POP can read in a dataset and add river fluxes to the surface fluxes returned from MARBL, but that doesn't involve MARBL itself
3. Carbon isotopes are provided in an optional tracer module inside MARBL.

So I think your questions (and their answers) are:

• How do I turn on carbon isotopes in MARBL?
  • In your CESM case directory, add ciso_on = .true. to the user_nl_marbl file. If this file doesn't exist, you can create it and just include the single line. Note that this will change the tracer count in POP, so you will need to rebuild the model -- I would do that by running ./case.build --clean-all && ./case.build
• How do I turn off river nutrients for the CISO tracers?
  • In POP's source/ directory, there is a file ecosys_forcing_mod.F90 with a block that looks like

    character(len=*), parameter :: riv_flux_components(9) = (/ &
         'din', 'dip', 'don', 'dop', 'dsi', 'dfe', 'dic', 'alk', 'doc' /)

If you want all the nutrients except doc (and its isotopic equivalents), change the dimension of the array from 9 to 8 and remove the last item.

    character(len=*), parameter :: riv_flux_components(8) = (/ &
         'din', 'dip', 'don', 'dop', 'dsi', 'dfe', 'dic', 'alk'/)

Later in the subroutine is a select case statement for each element of the array, and if ciso_on = .true. then all three DOC nutrients are turned on:

        case ('doc')
          doc_riv_flux_ind = n
          file_varname = riv_flux_doc_file_varname
          scale_factor = riv_flux_doc_scale_factor
          lhas_riv_flux(doc_ind) = .true.
          lhas_riv_flux(docr_ind) = .true.
          if (ciso_on) then
            lhas_riv_flux(do13ctot_ind) = .true.
            lhas_riv_flux(do14ctot_ind) = .true.
          endif

Since 'doc' is no longer in riv_flux_components(:) that code will never be run and those flags will remain .false.

 

[shiannder]

Thanks Mike for the advice and Erik for moderating. I really appreciate the support.

I followed your method above with edits to the DOC nutrients in ecosys_forcing_mod.F90, while "ciso=true" in the file user_nl_marbl. However, I am getting the same results with 92 variables missing in my final Netcdf file. The "DOC_RIV_FLUX" variable being missing is correct.

But all the CISO variables, specifically the "CISO_DOCtot_d13C" and "CISO_DOCtot_d14C" are missing.

Something to note, this is the same results as the original method of changing doc_ind in case('doc')

• lhas_riv_flux(doc_ind) = .false.
• lhas_riv_flux(docr_ind) = .false.

I know my user_nl_marbl works since other runs are working and the "executable, read, write permissions" are available for me. It's just when I remove the DOC river flux variables in ecosys_forcing_mod.F90 all the CISO variables do not show up in my netcdf file.

I guess my questions are:

Does the River DOC being turn off (removing the case('doc')), also turn off all isotope carbon variables in the ocean DOC too?
Is there a way to keep ocean DOC and C isotopes on, while river DOC and river DOC isotopes are kept off?



The variables missing are below. I am fine with missing "DOC_RIV_FLUX" and "DOCr_RIV_FLUX". Overall, I want to see the difference in model output between rivers off and rivers on in the model, specifically to see how the rivers contribute to carbon 13C and 14C change in the ocean carbon cycle. I hope this clarifies things, let me know if it is still confusing.

## [1] "CISO_PO13C_FLUX_IN" "CISO_PO13C_PROD"
## [3] "CISO_PO13C_REMIN" "CISO_DO13Ctot_prod"
## [5] "CISO_DO13Ctot_remin" "CISO_Ca13CO3_FLUX_IN"
## [7] "CISO_Ca13CO3_PROD" "CISO_Ca13CO3_REMIN"
## [9] "CISO_photo13C_TOT" "CISO_DIC_d13C"
## [11] "CISO_DOCtot_d13C" "CISO_zoototC_d13C"
## [13] "CISO_PO14C_FLUX_IN" "CISO_PO14C_PROD"
## [15] "CISO_PO14C_REMIN" "CISO_DO14Ctot_prod"
## [17] "CISO_DO14Ctot_remin" "CISO_Ca14CO3_FLUX_IN"
## [19] "CISO_Ca14CO3_PROD" "CISO_Ca14CO3_REMIN"
## [21] "CISO_photo14C_TOT" "CISO_DIC_d14C"
## [23] "CISO_DOCtot_d14C" "CISO_zoototC_d14C"
## [25] "CISO_photo13C_TOT_zint" "CISO_photo14C_TOT_zint"
## [27] "CISO_sp_Ca13CO3_form" "CISO_sp_Ca13CO3_form_zint"
## [29] "CISO_sp_Ca14CO3_form" "CISO_sp_Ca14CO3_form_zint"
## [31] "CISO_autotrophCaCO3_d13C_sp" "CISO_autotrophCaCO3_d14C_sp"
## [33] "CISO_eps_autotroph_sp" "CISO_d13C_sp"
## [35] "CISO_d14C_sp" "CISO_mui_to_co2star_sp"
## [37] "CISO_eps_autotroph_diat" "CISO_d13C_diat"
## [39] "CISO_d14C_diat" "CISO_mui_to_co2star_diat"
## [41] "CISO_eps_autotroph_diaz" "CISO_d13C_diaz"
## [43] "CISO_d14C_diaz" "CISO_mui_to_co2star_diaz"
## [45] "CISO_eps_aq_g" "CISO_eps_dic_g"
## [47] "calcToSed_13C" "pocToSed_13C"
## [49] "calcToSed_14C" "pocToSed_14C"
## [51] "CISO_FG_13CO2" "CISO_FG_as_13CO2"
## [53] "CISO_FG_sa_13CO2" "CISO_D13C_atm"
## [55] "CISO_FG_14CO2" "CISO_FG_as_14CO2"
## [57] "CISO_FG_sa_14CO2" "CISO_D14C_atm"
## [59] "DOC_RIV_FLUX" "DOCr_RIV_FLUX"
## [61] "DI13C" "J_DI13C"
## [63] "Jint_100m_DI13C" "DI13C_RIV_FLUX"
## [65] "FvPER_DI13C" "FvICE_DI13C"
## [67] "DO13Ctot" "Jint_100m_DO13Ctot"
## [69] "DO13Ctot_RIV_FLUX" "DI14C"
## [71] "J_DI14C" "Jint_100m_DI14C"
## [73] "DI14C_RIV_FLUX" "FvPER_DI14C"
## [75] "FvICE_DI14C" "DO14Ctot"
## [77] "Jint_100m_DO14Ctot" "DO14Ctot_RIV_FLUX"
## [79] "zootot13C" "zootot14C"
## [81] "sp13C" "sp14C"
## [83] "spCa13CO3" "spCa14CO3"
## [85] "diat13C" "diat14C"
## [87] "diaz13C" "diaz14C"
## [89] "tend_zint_100m_DI13C" "tend_zint_100m_DO13Ctot"
## [91] "tend_zint_100m_DI14C" "tend_zint_100m_DO14Ctot"

 

[mlevy]

I need a little bit more information about your setup -- what computer did you run this on? If it's a machine I can access, I'm happy to poke around your case directory and try to figure out what is going on. In the meantine, can you please run the following commands in your case root and report the output from each one?

$ grep create_newcase README.case
$ cat user_nl_marbl
$ ./xmlquery POP_CPPDEFS
$ grep CISO_PO13C_FLUX_IN Buildconf/popconf/gx1v7_tavg_contents
$ find . -name ecosys_diagnostics

The first one will just show the command you used to create your CESM case, and the second will show the contents of user_nl_marbl. The third command will report the build flags used by POP, including the number of MARBL tracers it is expecting. The fourth command will show whether CISO_PO13C_FLUX_IN should be in a POP history file or not, and the last one will show all locations of the file MARBL generates to help POP create the list of variables written to each history file.

 

[shiannder]

I am running on the Marvin computer at the University of New Hampshire with Robert Letscher. He said you should have access to the machine.

The requested output is attached for the directory in /mnt/lustre/letscher/jsl1063/cesm_runs/jsl.033

Thank you for the technical support. Let me know if you need anything else.

 

[mlevy]

Can you tell me about the files you put in the POP SourceMods/ directory?

$ ls SourceMods/src.pop/
ecosys_diagnostics  ecosys_forcing_mod.F90  ocn.base.tavg.csh

I'm guessing the ecosys_diagnostics file came from a run where ciso_on = .false., because it doesn't contain any of the CISO_ variables (and POP translates that file to determine what output to generate). The fix would be to regenerate the updated ecosys_diagnostics so that it includes the CISO variables; I would do that with the following steps:

$ mv SourceMods/src.pop/ecosys_diagnostics SourceMods/src.pop/ecosys_diagnostics.old
$ ./preview_namelists
$ cp Buildconf/popconf/ecosys_diagnostics SourceMods/src.pop/

This will give you all the default output variables, including the CISO diagnostics. You should then do a diff between SourceMods/src.pop/ecosys_diagnostics.old and SourceMods/src.pop/ecosys_diagnostics to see what you had changed in the non-ciso tracers, and update those variables in SourceMods/src.pop/ecosys_diagnostics to match what is in SourceMods/src.pop/ecosys_diagnostics.old.

 

[shiannder]

For my files in "/mnt/lustre/letscher/jsl1063/cesm_runs/jsl.033/SourceMods/src.pop",

• the ocn.base.tavg.csh is unchanged
• I believe the ecosys_diagnostics is copied over from another file called ecosys_diagnostics.nodocriv
  • cp ecosys_diagnostics.nodocriv ${SCRIPT_DIR_BASE}/${CASE}/SourceMods/src.pop/ecosys_diagnostics
  • From my notes, This file is edited to comment out the DOC and DOCr river flux (see below code)
    • "# DOC_RIV_FLUX : medium_average"
    • "# DOCr_RIV_FLUX : medium_average"
• The ecosys_forcing_mod.F90 file should just be changed based on your original recommendation in removing doc in the riv_flux_components
  • character(len=*), parameter :: riv_flux_components(8) = (/ &
    'din', 'dip', 'don', 'dop', 'dsi', 'dfe', 'dic', 'alk'/)

For your listed steps, I made corrections to your code to work

• mv /mnt/lustre/letscher/jsl1063/cesm_runs/jsl.033/SourceMods/src.pop/ecosys_diagnostics /mnt/lustre/letscher/jsl1063/cesm_runs/jsl.033/SourceMods/src.pop/ecosys_dianostics.old
• ls -latrh: to see the listed file names
• cp /mnt/lustre/letscher/jsl1063/cesm_runs/jsl.033/Buildconf/popconf/ecosys_diagnostics /mnt/lustre/letscher/jsl1063/cesm_runs/jsl.033/SourceMods/src.pop

After downloading both old and new ecosys_diagnotics, I compared the text files and found the CISO variables were deleted/missing in the older version.



I guess I should not run the line below and use the original ecosys_diagnostics with your ecosys_forcing_mod.F90 modification to the riv_flux_components code.

• cp ecosys_diagnostics.nodocriv ${SCRIPT_DIR_BASE}/${CASE}/SourceMods/src.pop/ecosys_diagnostics

I will try running with the original ecosys_diagnotics file from the Buildconf/popconf/ecosys_diagnostics. Thank you Mike!


Below is some code that was missing. Most were the isotope carbon variables. See attached for the comparison files.

Diagnostics for tracer DI13C
DI13C : medium_average
STF_DI13C : never_average
J_DI13C : medium_average
Jint_100m_DI13C : medium_average
Jint_DI13C : never_average
DI13C_zint_100m : never_average
tend_zint_100m_DI13C : medium_average
DI13C_RIV_FLUX : medium_average
FvPER_DI13C : medium_average
FvICE_DI13C : medium_average
UE_DI13C : never_average
VN_DI13C : never_average
WT_DI13C : never_average
DIA_IMPVF_DI13C : never_average
HDIFE_DI13C : never_average
HDIFN_DI13C : never_average
HDIFB_DI13C : never_average
TEND_DI13C : never_average
RF_TEND_DI13C : never_average
KPP_SRC_DI13C : never_average
#
# Diagnostics for tracer DI14C
#
DI14C : medium_average
STF_DI14C : never_average
J_DI14C : medium_average
Jint_100m_DI14C : medium_average
Jint_DI14C : never_average
DI14C_zint_100m : never_average
tend_zint_100m_DI14C : medium_average
DI14C_RIV_FLUX : medium_average
FvPER_DI14C : medium_average
FvICE_DI14C : medium_average
UE_DI14C : never_average
VN_DI14C : never_average
WT_DI14C : never_average
DIA_IMPVF_DI14C : never_average
HDIFE_DI14C : never_average
HDIFN_DI14C : never_average
HDIFB_DI14C : never_average
TEND_DI14C : never_average
RF_TEND_DI14C : never_average
KPP_SRC_DI14C : never_average
#
# Diagnostics for tracer DIC

Diagnostics for tracer DO13Ctot
#
DO13Ctot : medium_average
STF_DO13Ctot : never_average
J_DO13Ctot : never_average
Jint_100m_DO13Ctot : medium_average
Jint_DO13Ctot : never_average
DO13Ctot_zint_100m : never_average
tend_zint_100m_DO13Ctot : medium_average
DO13Ctot_RIV_FLUX : medium_average
UE_DO13Ctot : never_average
VN_DO13Ctot : never_average
WT_DO13Ctot : never_average
DIA_IMPVF_DO13Ctot : never_average
HDIFE_DO13Ctot : never_average
HDIFN_DO13Ctot : never_average
HDIFB_DO13Ctot : never_average
TEND_DO13Ctot : never_average
RF_TEND_DO13Ctot : never_average
KPP_SRC_DO13Ctot : never_average
#
# Diagnostics for tracer DO14Ctot
#
DO14Ctot : medium_average
STF_DO14Ctot : never_average
J_DO14Ctot : never_average
Jint_100m_DO14Ctot : medium_average
Jint_DO14Ctot : never_average
DO14Ctot_zint_100m : never_average
tend_zint_100m_DO14Ctot : medium_average
DO14Ctot_RIV_FLUX : medium_average
UE_DO14Ctot : never_average
VN_DO14Ctot : never_average
WT_DO14Ctot : never_average
DIA_IMPVF_DO14Ctot : never_average
HDIFE_DO14Ctot : never_average
HDIFN_DO14Ctot : never_average
HDIFB_DO14Ctot : never_average
TEND_DO14Ctot : never_average
RF_TEND_DO14Ctot : never_average
KPP_SRC_DO14Ctot : never_average
#
# Diagnostics for tracer DOC

# Diagnostics for tracer diat13C
#
diat13C : medium_average
STF_diat13C : never_average
J_diat13C : never_average
Jint_100m_diat13C : never_average
Jint_diat13C : never_average
diat13C_zint_100m : never_average
tend_zint_100m_diat13C : never_average
UE_diat13C : never_average
VN_diat13C : never_average
WT_diat13C : never_average
DIA_IMPVF_diat13C : never_average
HDIFE_diat13C : never_average
HDIFN_diat13C : never_average
HDIFB_diat13C : never_average
TEND_diat13C : never_average
RF_TEND_diat13C : never_average
KPP_SRC_diat13C : never_average
#
# Diagnostics for tracer diat14C
#
diat14C : medium_average
STF_diat14C : never_average
J_diat14C : never_average
Jint_100m_diat14C : never_average
Jint_diat14C : never_average
diat14C_zint_100m : never_average
tend_zint_100m_diat14C : never_average
UE_diat14C : never_average
VN_diat14C : never_average
WT_diat14C : never_average
DIA_IMPVF_diat14C : never_average
HDIFE_diat14C : never_average
HDIFN_diat14C : never_average
HDIFB_diat14C : never_average
TEND_diat14C : never_average
RF_TEND_diat14C : never_average
KPP_SRC_diat14C : never_average
#
# Diagnostics for tracer diatC

 

[gvettoretti]

I'm a little confused by your post -- you seem to be conflating POP and MARBL as well as ocean BGC riverine fluxes and the full river runoff component. So let me try to address that first, and then I'll answer the questions I think you're asking.

1. There is a river runoff model that dumps fresh water into the ocean; this affects salinity (and possibly temperature?) in the ocean, but is separate from riverine nutrients.
2. MARBL doesn't know anything about riverine nutrients; POP can read in a dataset and add river fluxes to the surface fluxes returned from MARBL, but that doesn't involve MARBL itself

Hi @mlevy , I'm confused about this line in Section 2.2.6 of
Long, M. C. et al. Simulations With the Marine Biogeochemistry Library (MARBL). Journal of Advances in Modeling Earth Systems 13, e2021MS002647 (2021).
“This estuary box-model framework is also used in CESM2 to distribute riverine biogeochemical inputs, ensuring consistent treatment of freshwater and biogeochemical riverine inputs, and also avoiding the unrealistic spreading of inputs over a large region of the surface ocean.”

But I don't see the EBM code in CESM2 doing anything with the riverine nutrients. Do you know if this is incorrect?

 

[mlevy]

In CESM2, POP has an estuary box model and freshwater is mapped from the runoff grid to ocean grid using a nearest-neighbor map (so all the runoff is mapped to the coast of the ocean). This is different from CESM1, which did not have an estuary box model and instead relied on the coupler to map the freshwater over a larger area of the ocean surface (this is the "unrealistic spreading" mentioned in the paper). For BGC riverine inputs, we map river nutrients from observational datasets to the runoff grid, and then use the same nearest-neighbor map CESM2 uses for freshwater to map the river nutrients to the ocean grid. So the estuary box model is not doing anything with the BGC inputs, but BGC inputs are mapped from the runoff grid to the ocean grid in the same way as the EBM inputs.

 

[gvettoretti]

Thank you for the response Michael.