Add a user namelist for reduced output settings

[JorgSchwinger]

This PR add a file user_nl_blom_outvol_reduced to the directory cime_config. The purpose of this file is to provide a namelist with reduced output settings for the NorESM3 spin-up simulations or test simulations. The following general rules are applied:

• no daily output
• no output on isopycnic layers
• no (HAMOCC) or minimal (BLOM) monthly 3d-output on levels
• reduced annual 3d output

For convenience, and since it increases the output volume only little, I have repeated the output of 2d fields also in annual files.

@matsbn, @TomasTorsvik, @jmaerz , @milicak , @AleksiNummelin please review these output settings and let me know if you see the need for changes (please put a comment at the corresponding line).

@matsbn, one could further reduce the BLOM output by using 2-byte compressed output. After my experience this results in in ~20-30% smaller files after compression to netCDF4 and the accuracy is still good enough for most applications.

[jmaerz]

Hi @JorgSchwinger , is there any good reason to provide this as a user_nl_blom and not similar to/in line with #478?

[JorgSchwinger]

This was discussed here NorESMhub/noresm3_dev_simulations#88 and the conclusion was that it is easier to do it as user-mods_directory

[jmaerz]

Hi @JorgSchwinger , apologize my ignorance, but are user-mods equivalent to the source-mods directory? - if so, I really feel that this is a step backward rather than forward and I would advocate for introducing ONE xml-switch name at the NorESM level for let say CMIP7-spinup (and one for CMIP7-production runs or alike plus other switches needed) that switches on all components output via namelists. Admittedly, that's what I read when looking into issue NorESMhub/noresm3_dev_simulations#88 - the latter has never really conclusively decided to my understanding (and use-mods escaped my understanding...).

[JorgSchwinger]

user-mods are activated with an option when you create the case. The corresponding namelist files are maintained in cime (we could have a copy in BLOM's cime_config, as suggested by this PR, but that's not strictly necessary).

It is much easier, particularly for the other components that are not exclusively used for NorESM. If you don't agree with this solution, you should bring this up for the other components here NorESMhub/noresm3_dev_simulations#88

[jmaerz]

Hi @JorgSchwinger , in any case, many thanks for providing this - let's see, where NorESMhub/noresm3_dev_simulations#88 leads to. In the case that user-mods will be used, I would suggest i) to push this PR ONLY to NorESM (not to BLOM) and ii) potentially include your settings rather with a switch into the currently used namelist_definition_blom.xml-file.

[JorgSchwinger]

Hi all, regardless what we do about this, it would be good to review the content of the user_nl file. Particularly, @matsbn could you review the physical output setting, and @jmaerz could you make sure you are ok with the outputs for the extended N-cycle (and M4AGO).

@matsbn what do you think about using 2-byte compressed output also for BLOM as done for HAMOCC in this namelist? My experience is that the (compressed) files are significantly smaller.

Please let me know any changes.

[JorgSchwinger]

@jmaerz I am also totally fine with having a switch in env_run.xml, which then controls the namelist generation "online". To activate, this would then involve a separate step (an xmlchange command after create_case), but that would be probably also acceptable. I would not have the time right now to do this, though.

[jmaerz]

Hi @JorgSchwinger , thanks for picking up on this - I'll check this tmw. Other than that: if there is an easy possibility via usermods folder+script in BLOM/iHAMOCC, I would suggest to go that route and to put this eventually in the namelist_definition_blom.xml file. Once your current file is properly filled, we can easily translate it via a slightly modified version of the script that I sent you into the namelist_definition_blom.xml file (with a switch in the config_component.xml as done in #478 - essentially combining the two PRs).

[JorgSchwinger]

@jmaerz this would be possible, if cime would pick up user-mods-dirs on a component level (instead of or in addition to at the NorESM level), that is what you are saying, right? This would of course be a nice.

[jmaerz]

Hi @JorgSchwinger , that's at least, how I understood Matvey this morning. Let's see - I asked for advice in NorESMhub/noresm3_dev_simulations#88

[matsbn]

Hi all, regardless what we do about this, it would be good to review the content of the user_nl file. Particularly, @matsbn could you review the physical output setting, and @jmaerz could you make sure you are ok with the outputs for the extended N-cycle (and M4AGO).

@matsbn what do you think about using 2-byte compressed output also for BLOM as done for HAMOCC in this namelist? My experience is that the (compressed) files are significantly smaller.

Please let me know any changes.

I will have a look at this and sorry I was not able to attend to it sooner. I would like to keep some of the daily output BLOM output and a minimal set of output in model layers (LYR).

Using 2-byte output is not ideal for variables like salinity where the global value range is large, but the majority of values are within a narrow range (low accuracy for the bulk of the ocean volume). I felt that when we started to use the netCDF4 compression of output, the size benefit of 2-byte output was reduced (cannot recall numbers, though). Putting in automatic netCDF4 compression in the short term archiving process for NorESM3 (as we did it in NorESM2) was discussed at a recent NorESM tag team meeting. This gives a significant space saving and must be automatic, since experience show that users typically don't do this themselves afterwards.

[JorgSchwinger]

Using 2-byte output is not ideal for variables like salinity where the global value range is large, but the majority of values are within a narrow range (low accuracy for the bulk of the ocean volume). I felt that when we started to use the netCDF4 compression of output, the size benefit of 2-byte output was reduced (cannot recall numbers, though). Putting in automatic netCDF4 compression in the short term archiving process for NorESM3 (as we did it in NorESM2) was discussed at a recent NorESM tag team meeting. This gives a significant space saving and must be automatic, since experience show that users typically don't do this themselves afterwards.

Files are about 20-30% smaller with the 2-byte option (after compression, recently tested) - so it is not a huge saving (but still something...)

[jmaerz]

... maybe worth considering something like a spinup and a production run flag for output?

[mvdebolskiy]

• make a directory: cime_config/usermods_dirs/reduced_output
• mv cime_config/user_nl_blom_outvol_reduced cime_config/usermods_dirs/reduced_output/user_nl_blom
  It will allow to have a usermods_dir in coupled model to pick this user_nl_blom up for coupled simulations by adding ../../../components/blomcime_config/usermods_dirs/reduced_output in cime_config/usermods_dirs/reduced_out_devsim/include_user_mods
  See Add reduced output usermod for dev simulations NorESM#654

[jmaerz]

Can we have inventory output as well on a yearly basis? And switch on the monitoring files!

[JorgSchwinger]

Sure, but what do you mean by "switch on the monitoring files"?

[jmaerz]

It would be good to have the netcdf-monitoring files - at least yearly - hence:

GLB_INVENTORY = 1,2

which should switch on the monitoring files for the yearly monitoring output (>1) - maybe I should just do so for the current master as well?

[jmaerz]

any reasons to have this set to 4? (similar oxygen above).

[JorgSchwinger]

For oxygen the 2-byte output does not provide enough resolution for oxygen minimum zones. Here 4-bytes are really needed, while for other tracers, it is less critical.

[jmaerz]

Thanks for the info! (I guessed so, but wasn't sure - so thanks for confirmation).

[jmaerz]

I am wondering, how much info we would need for the sinking. Maybe it would reasonable during spinup to at least write out the LVL_AGG_WS - to enable having a rough idea on e.g. remineralization length scales? - for production runs, I would clearly opt for some more information later.

[jmaerz]

Are we going to use this user_nml also for continued tuning purposes? If so, some layer information (annual) for the N-cycle would be appreciated - if, yes, I can provide a list.

[JorgSchwinger]

What do you mean by "continued tuning purposes"?

You would want layer output rather than level?

[jmaerz]

Hi @JorgSchwinger , how to phrase it - for single years, I have build a routine that very well analyzes the budgets and flows inside the N-cycle based on annual layer data. In addition to the classical tracer fields and fluxes, it helped me a lot to understand, where the N-cycle stands and what to potentially tune. Hence, I feel it could be useful, when we would want to run some extended nitrogen cycle simulations to switch some layer output on. Does that make sense to you?

[jmaerz]

I am wondering, if we could/should add the shelfage tracer for spinup - to get information on it during pi and potentially, how that changes over hist+scenario.

[JorgSchwinger]

But this is only the output setting. We will certainly switch on the output for the piControl and all subsequent simulations, but here the question is whether the output would be useful for spinup? IMO this would only be the case if this could provide information for tuning purposes.

[jmaerz]

I agree that we can keep shelfage off for the spinup. - would be nice to switch it on, when starting pi-simulations (that need to be long enough to reach steady state in age - which should be about 100yrs+).

[JorgSchwinger]

@matsbn could you please provide a list of variables for which you would want daily output?
@jmaerz could you provide a list of variables that you would like to add for sinking/N-cycle?
Tusen takk!

[jmaerz]

Hi @JorgSchwinger,

for the extended nitrogen cycle, we would need to write out the following variables:

n2oflux, nh3flux, nfixint , pddpo, nitr_n2o, no2denit, n2odenit, nh4nitr, no2nitr, no3denit, no2dnra, anmx_n2, phosy_nh4, phosy_no3, remina, remins, nh4nitr_om, no2nitr_om, anmx_om, sedfox, carflx_bot, sedfno2, sedfn2o, sedfnh4, sedfno3, sedfn2, burfsso12, nitr_n2osdm, no2denitsdm, n2odenitsdm, nh4nitrsdm, no2nitrsdm, no3denitsdm, no2dnrasdm, anmx_n2sdm, reminasdm, reminssdm, nh4nitr_omsdm, no2nitr_omsdm, anmx_omsdm

For sediment dry-weight comparison:
ssso12,sssc12,ssssil

on a yearly basis. In terms of namelist flags, this translates to (considering some as monthly values as well):

SRF_N2OFX         = 2,2
SRF_ANH3FX        = 2,2
INT_NFIX          = 0,2
LYR_DP            = 0,2
LYR_NITR_N2O_PROD = 0,2
LYR_DENIT_NO2     = 0,2
LYR_DENIT_N2O     = 0,2
LYR_NITR_NH4      = 0,2
LYR_NITR_NO2      = 0,2
LYR_DENIT_NO3     = 0,2
LYR_DNRA_NO2      = 0,2
LYR_ANMX_N2_PROD  = 0,2
LYR_PHOSY_NH4     = 0,2
LYR_PHOSY_NO3     = 0,2
LYR_REMIN_AEROB   = 0,2
LYR_REMIN_SULF    = 0,2
LYR_NITR_NH4_OM   = 0,2
LYR_NITR_NO2_OM   = 0,2
LYR_ANMX_OM_PROD  = 0,2
FLX_SEDIFFOX      = 0,2
FLX_CAR_BOT       = 0,2
FLX_SEDIFFNO2     = 0,2
FLX_SEDIFFN2O     = 0,2
FLX_SEDIFFNH4     = 0,2
FLX_SEDIFFNO3     = 0,2
FLX_SEDIFFN2      = 0,2
FLX_BURSSO12      = 0,2
SDM_NITR_N2O_PROD = 0,2
SDM_DENIT_NO2     = 0,2
SDM_DENIT_N2O     = 0,2
SDM_NITR_NH4      = 0,2
SDM_NITR_NO2      = 0,2
SDM_DENIT_NO3     = 0,2
SDM_DNRA_NO2      = 0,2
SDM_ANMX_N2_PROD  = 0,2
SDM_REMIN_AEROB   = 0,2
SDM_REMIN_SULF    = 0,2
SDM_NITR_NH4_OM   = 0,2
SDM_NITR_NO2_OM   = 0,2
SDM_ANMX_OM_PROD  = 0,2

For sediment dry-weight:

SDM_SSSO12 = 0,2
SDM_SSSC12 = 0,2
SDM_SSSSIL = 0,2

For the sinking (and just spinup):

LVL_AGG_WS = 0,2

should suffice to understand potential issues (while for production it would nice to have more).

[JorgSchwinger]

Thank you @jmaerz. I am wondering, is there a scientific reason to write out lyr-fields for the N-cycle? I understand you have a script that uses the lyr-output, but in general I think it is unfortunate to write out parts of the model output on lvl-only and another part lyr-only... Also in view of diagnostics.

[jmaerz]

Hi @JorgSchwinger , since these outputs are tendencies (and afterward integrated over the individual volumes during the post-processing step for budgeting - currently abusing the output in this way), the budgets are already now posing some error. When using lvl output, I fear this error to be increasing. Technically, it would be good to rewrite the output to "tendency*\DeltaV" and average over those... - for the purpose of closed budgeting.

[TomasTorsvik]

Hi @jmaerz - I think for this PR/issue we should just specify a reduced output from what we already have. I fear we open up a new lengthy process if we start to introduce changes to the output in the same setting.

[JorgSchwinger]

Hi @JorgSchwinger , since these outputs are tendencies (and afterward integrated over the individual volumes during the post-processing step for budgeting - currently abusing the output in this way), the budgets are already now posing some error. When using lvl output, I fear this error to be increasing. Technically, it would be good to rewrite the output to "tendency*\DeltaV" and average over those... - for the purpose of closed budgeting.

Not sure - the interpolation to z-levels is conservative, so any linear operation on the output should be conserved, too (for budgets on z-levels, one needs to take into account the bathymetry, though, in order for sums and averaged to be correct).

[jmaerz]

The diagnostics need to be rewritten (*dz - changing units from mol/(m3 s) to mol/(m2 s)). #521

[jmaerz]

As discussed offline, the layer data are more precise for the budgeting, which is useful, when fluxes cover different orders of magnitudes (and when percentage-error margins aren't the same for the different fluxes, since the processes occur in different oceanic regions).

[matsbn]

@matsbn could you please provide a list of variables for which you would want daily output? @jmaerz could you provide a list of variables that you would like to add for sinking/N-cycle? Tusen takk!

My suggestion for reduced output for BLOM variables is below. Certainly more variables are kept than the original suggestion, but should still be a significant reduction. The variables kept are the ones I anticipate will be looked at during testing and spinup. This includes some fundamental monthly LYR state variables and diffusivities. I also tried to check that variables needed for the standard diagnostics are in place.

  GLB_FNAMETAG@diaphy = 'hd', 'hm', 'hy'
  GLB_AVEPERIO@diaphy = 1, 30, 365
  GLB_FILEFREQ@diaphy = 30, 30, 365
  GLB_COMPFLAG@diaphy = 0, 0, 0
  GLB_NCFORMAT@diaphy = 1, 1, 1

  H2D_ABSWND   = 0, 4, 0
  H2D_ALB      = 0, 0, 0
  H2D_BTMSTR   = 0, 4, 0
  H2D_BRNFLX   = 0, 4, 0
  H2D_BRNPD    = 0, 4, 0
  H2D_DFL      = 0, 0, 0
  H2D_EVA      = 0, 4, 0
  H2D_FICE     = 0, 4, 0
  H2D_FMLTFZ   = 0, 4, 0
  H2D_HICE     = 0, 0, 0
  H2D_HMLTFZ   = 0, 4, 0
  H2D_HSNW     = 0, 0, 0
  H2D_IAGE     = 0, 0, 0
  H2D_IDKEDT   = 0, 4, 0
  H2D_LAMULT   = 0, 4, 0
  H2D_LASL     = 0, 4, 0
  H2D_LIP      = 0, 4, 0
  H2D_MAXMLD   = 0, 4, 0
  H2D_MLD      = 0, 4, 0
  H2D_MLTS     = 4, 4, 0
  H2D_MLTSMN   = 0, 4, 0
  H2D_MLTSMX   = 0, 4, 0
  H2D_MLTSSQ   = 0, 0, 0
  H2D_MTKEUS   = 0, 4, 0
  H2D_MTKENI   = 0, 4, 0
  H2D_MTKEBF   = 0, 4, 0
  H2D_MTKERS   = 0, 4, 0
  H2D_MTKEPE   = 0, 4, 0
  H2D_MTKEKE   = 0, 4, 0
  H2D_MTY      = 0, 4, 0
  H2D_NSF      = 0, 4, 0
  H2D_PBOT     = 0, 4, 0
  H2D_PSRF     = 0, 4, 0
  H2D_RFIFLX   = 0, 4, 0
  H2D_RNFFLX   = 0, 4, 0
  H2D_SALFLX   = 0, 4, 0
  H2D_SALRLX   = 0, 4, 0
  H2D_SBOT     = 0, 4, 0
  H2D_SEALV    = 4, 4, 0
  H2D_SLVSQ    = 0, 0, 0
  H2D_SFL      = 0, 4, 0
  H2D_SOP      = 0, 4, 0
  H2D_SIGMX    = 0, 4, 0
  H2D_SSS      = 4, 4, 0
  H2D_SSSSQ    = 0, 0, 0
  H2D_SST      = 4, 4, 0
  H2D_SSTSQ    = 0, 0, 0
  H2D_SURFLX   = 0, 4, 0
  H2D_SURRLX   = 0, 4, 0
  H2D_SWA      = 0, 4, 0
  H2D_T20D     = 0, 4, 0
  H2D_TAUX     = 0, 4, 0
  H2D_TAUY     = 0, 4, 0
  H2D_TBOT     = 0, 4, 0
  H2D_TICE     = 0, 0, 0
  H2D_TSRF     = 0, 0, 0
  H2D_UB       = 0, 4, 0
  H2D_UICE     = 0, 0, 0
  H2D_USTAR    = 0, 4, 0
  H2D_USTAR3   = 0, 4, 0
  H2D_USTOKES  = 0, 0, 0
  H2D_VB       = 0, 4, 0
  H2D_VICE     = 0, 0, 0
  H2D_VSTOKES  = 0, 0, 0
  H2D_ZTX      = 0, 4, 0

  LYR_BFSQ     = 0, 0, 0
  LYR_DIFDIA   = 0, 4, 0
  LYR_DIFINT   = 0, 4, 0
  LYR_DIFISO   = 0, 4, 0
  LYR_DIFVHO   = 0, 4, 0
  LYR_DIFVMO   = 0, 0, 0
  LYR_DIFVSO   = 0, 0, 0
  LYR_DP@diaphy= 0, 4, 0
  LYR_DZ       = 0, 4, 0
  LYR_SALN     = 0, 4, 0
  LYR_TEMP     = 0, 4, 0
  LYR_TRC      = 0, 0, 0
  LYR_UFLX     = 0, 0, 0
  LYR_UTFLX    = 0, 0, 0
  LYR_USFLX    = 0, 0, 0
  LYR_UMFLSM   = 0, 0, 0
  LYR_UMFLTD   = 0, 0, 0
  LYR_USFLSM   = 0, 0, 0
  LYR_UTFLTD   = 0, 0, 0
  LYR_UTFLLD   = 0, 0, 0
  LYR_UTFLSM   = 0, 0, 0
  LYR_USFLTD   = 0, 0, 0
  LYR_USFLLD   = 0, 0, 0
  LYR_UVEL     = 0, 4, 0
  LYR_VFLX     = 0, 0, 0
  LYR_VTFLX    = 0, 0, 0
  LYR_VSFLX    = 0, 0, 0
  LYR_VMFLSM   = 0, 0, 0
  LYR_VMFLTD   = 0, 0, 0
  LYR_VTFLTD   = 0, 0, 0
  LYR_VTFLLD   = 0, 0, 0
  LYR_VSFLSM   = 0, 0, 0
  LYR_VSFLTD   = 0, 0, 0
  LYR_VSFLLD   = 0, 0, 0
  LYR_VTFLSM   = 0, 0, 0
  LYR_VVEL     = 0, 4, 0
  LYR_WFLX     = 0, 0, 0
  LYR_WFLX2    = 0, 0, 0
  LYR_PV       = 0, 0, 0
  LYR_TKE      = 0, 0, 0
  LYR_GLS_PSI  = 0, 0, 0
  LYR_IDLAGE   = 0, 0, 0

  LVL_BFSQ     = 0, 0, 4
  LVL_DIFDIA   = 0, 0, 4
  LVL_DIFINT   = 0, 0, 4
  LVL_DIFISO   = 0, 0, 4
  LVL_DIFVHO   = 0, 0, 4
  LVL_DIFVMO   = 0, 0, 0
  LVL_DIFVSO   = 0, 0, 0
  LVL_DZ       = 0, 4, 4
  LVL_SALN     = 0, 4, 4
  LVL_TEMP     = 0, 4, 4
  LVL_TRC      = 0, 0, 0
  LVL_UFLX     = 0, 0, 4
  LVL_UTFLX    = 0, 0, 4
  LVL_USFLX    = 0, 0, 4
  LVL_UMFLSM   = 0, 0, 4
  LVL_UMFLTD   = 0, 0, 4
  LVL_USFLSM   = 0, 0, 4
  LVL_UTFLTD   = 0, 0, 4
  LVL_UTFLLD   = 0, 0, 4
  LVL_UTFLSM   = 0, 0, 4
  LVL_USFLTD   = 0, 0, 4
  LVL_USFLLD   = 0, 0, 4
  LVL_UVEL     = 0, 4, 4
  LVL_VFLX     = 0, 0, 4
  LVL_VTFLX    = 0, 0, 4
  LVL_VSFLX    = 0, 0, 4
  LVL_VMFLSM   = 0, 0, 4
  LVL_VMFLTD   = 0, 0, 4
  LVL_VSFLSM   = 0, 0, 4
  LVL_VTFLSM   = 0, 0, 4
  LVL_VTFLTD   = 0, 0, 4
  LVL_VTFLLD   = 0, 0, 4
  LVL_VSFLTD   = 0, 0, 4
  LVL_VSFLLD   = 0, 0, 4
  LVL_VVEL     = 0, 4, 4
  LVL_WFLX     = 0, 0, 4
  LVL_WFLX2    = 0, 0, 0
  LVL_PV       = 0, 0, 0
  LVL_TKE      = 0, 0, 0
  LVL_GLS_PSI  = 0, 0, 0
  LVL_IDLAGE   = 0, 4, 4

  MSC_MHFSM    = 0, 4, 4
  MSC_MMFLXL   = 0, 4, 4
  MSC_MMFLXD   = 0, 4, 4
  MSC_MMFSMD   = 0, 4, 4
  MSC_MMFSML   = 0, 4, 4
  MSC_MMFTDL   = 0, 4, 4
  MSC_MMFTDD   = 0, 4, 4
  MSC_MHFLX    = 0, 4, 4
  MSC_MHFTD    = 0, 4, 4
  MSC_MHFLD    = 0, 4, 4
  MSC_MSFLX    = 0, 4, 4
  MSC_MSFSM    = 0, 4, 4
  MSC_MSFTD    = 0, 4, 4
  MSC_MSFLD    = 0, 4, 4
  MSC_VOLTR    = 0, 4, 4
  MSC_MASSGS   = 0, 4, 4
  MSC_VOLGS    = 0, 4, 4
  MSC_SALNGA   = 0, 4, 4
  MSC_TEMPGA   = 0, 4, 4
  MSC_SSSGA    = 0, 4, 4
  MSC_SSTGA    = 0, 4, 4

[JorgSchwinger]

Hi @jmaerz @matsbn I have now updated the user-nml file and committed it. Jöran, will you take care of implementing this into the namelist generation script as discussed above and offline? I will afterwards close this PR, since we agreed that it will not be merged in this form.

[jmaerz]

With the merged PR #478, this PR could be closed now - I leave this to either @JorgSchwinger or @TomasTorsvik