Sediment depth flexible via namelist

[jmaerz]

The aim of this PR is to make the number of sediment layers, their vertical extensions and the porosity flexibly settable via the namelist. This is thus far only for test purposes, but can lead for a more sediment-oxygen-deficit layers-oriented setup (i.e. testing, if this improves the nitrogen cycle representation in sediments). I hope to make this work in combination with the still in progress offline sediment spinup (#560).

An example user_nl_blom snippet to make use of the flexible number of sediment layers looks like:

KS = 4
DZS = 0.001 0.003 0.005 0.007 0.009
SED_POROSITY = 0.85 0.83 0.6 0.5

Here, the number of sediment layers is reduced to 4 and a changed porosity of the third and fourth layer. Note that the length of DZS is by one longer than SED_POROSITY.

NOTE that due to numerics, there is a lower limit of sediment layers to be used.

Changing the sediment initialization came with a small restructuring of mo_hamocc_init - placing now the memory allocation of fields before reading bgcnml - which made it necessary to move use_M4AGO out of bgcnml and instead put it into config_nml (where it is actually better placed as well).

Changes required in the 1D vertical columns setup limits file:

USE_M4AGO needs to be moved from bgcnml into nml section config_nml
KS=12 needs to be added to config_nml
and

 DZS = 0.001 0.003 0.005 0.007 0.009 0.011 0.013 0.015 0.017 0.019 0.021 0.023 0.025 
 SED_POROSITY= 0.85 0.83 0.8 0.79 0.77 0.75 0.73 0.7 0.68 0.66 0.64 0.62

needs to be put into bgcnml.

[jmaerz]

Hi @JorgSchwinger and @TomasTorsvik , I still need to test the code in 3D for bfb, while in 1D it works as expected. The idea is to enable deeper sediment (and thus more oxygen deficit areas in deeper sediment) to enhance the representation of anaerob processes, i.e. the nitrogen cycle processes. This isn't related to any CMIP7 Fast Track simulations, but rather for a version towards NorESM3.X (e.g. X=5).

[TomasTorsvik]

@jmaerz - looks fine to me.
I'm not sure if I understand, if the number of layers can be flexible, as long as there are fixed parameter settings for porwat_def and dzs_def.

[jmaerz]

Hi @TomasTorsvik , the number of layers is set via: ks_flexi (in the config_bgc-nml), the layers values are then provided through sed_dzs_flexi and sed_porwat_flexi (in the bgcnml - read in mo_hamocc_init - and then the values are populated to ini_sedmnt). The porwat_def and dzs_def are the current default values (to keep hopefully bfb - I am currently running simulations for testing) and are set by default (ks=12). I am currently only hitting issues in the blom-xml - with the real(:) expression - which I need to resolve (+small issue for type of ks_flexi - needs to be of course integer). The whole thing should work with use_sedflexi=True also in the config_bgc.

[jmaerz]

@TomasTorsvik , I am not sure, how the regression testing is carried out, but it could fail due to non-comparable number of variables, since two more variables and one dimension have been added in this PR (i.e. the vertical extension of sediment grid boxes and porosity) - both in case of default values as well as the flexible settings. Writing porosity is currently neglected, when 3D porosity is (optionally) chosen. The latter maybe a matter of -later- change.

[jmaerz]

@TomasTorsvik and @JorgSchwinger , from my side, the PR should be ready.

[jmaerz]

Maybe worth to note that one could even read in the ks, dzs and porosity values via the namelist all the time (these nmls are written by default to ocn_in) - which would shorten the code a bit in the sediment initialization. But this is maybe for later consideration.

[JorgSchwinger]

Maybe worth to note that one could even read in the ks, dzs and porosity values via the namelist all the time (these nmls are written by default to ocn_in) - which would shorten the code a bit in the sediment initialization. But this is maybe for later consideration.

To be honest, I would prefer this solution. To have duplicate fields, one of which is used when USE_SEDFLEXI = .true., the other if it is .false. is quite confusing. Would then also be possible to have all the allocate statements in mo_sedmnt (?)

[jmaerz]

Hi @TomasTorsvik and @JorgSchwinger , I now updated the code in such a way that the sediment porosity and sediment layer thickness is always read from the bgcnml, while the number of layers are set -always- via the config_nml. Further, I moved the memory allocation section in mo_hamocc_init before reading bgcnml which required to put use_M4AGO into the config_nml. I updated the header comment of this PR accordingly - also giving advice on how to change the limits file for the 1D vertical column setup. I hope that helps for further applications. I am currently setting up and running a new 1month run to check for bfb against the current master.

[jmaerz]

@TomasTorsvik and @JorgSchwinger , indirectly shown via po4lvl and no3lvl, the results look like remaining bfb. But maybe it's worth running the full test-suite on the branch? Any chance you could give it a try with it, @TomasTorsvik ? (Note again that some issues may come up due to changed number of variables - seddz and sedpor are added together with new dimension ksp).

[TomasTorsvik]

@jmaerz - Thanks for the update, I will run the BLOM regression tests for the branch.

[TomasTorsvik]

Test output available here:

/cluster/work/users/tomast/noresm/nor3_b05-hamocc_flexi_sediment

I'm getting the expected namelist fail (NLFAIL) for all test with active BGC. One unexpected fail on ERS_Ld5.T62_tn14.NOINY.betzy_intel.blom-woa_nuopc at RUN stage. Looks like Betzy stalled. Will run this again.

[TomasTorsvik]

@jmaerz - The ERS_Ld5.T62_tn14.NOINY.betzy_intel.blom-woa_nuopc test went through on second attempt, so it looks fine now.

[jmaerz]

Hi @TomasTorsvik , thanks for the testing and sorry to burden you with it in addition to the NorESM3 development stuff.

@JorgSchwinger , I would suggest that you could approve it and @TomasTorsvik decides, when to bring in the changes - just let me know, when it suits best the development plan of NorESM3.

[TomasTorsvik]

@jmaerz - I think this can be merged now. Perhaps the next merge to NorESM will only include #689 + CDEPS fix, and this comes in after, as not to introduce namelist changes as well in a minor update.

[jmaerz]

@JorgSchwinger , are you fine with merging this sediment PR?

[JorgSchwinger]

Looks ok to me. If it is bit-for-bit I am fine with merging it, although we might want to wait until after the spinup has started?

[JorgSchwinger]

Sorry I didn't look deeper into this, but why is it necessary to have these variables local and allocate them here in the top-level routine? Couldn't this be done in alloc_mem_sedment?

[jmaerz]

Hi @JorgSchwinger , ok, I now allocate those fields in mo_read_X... - I do it this way, to not screw up the current structure of reading and subsequent initialization - technically, one could restructure the whole sediment initialization (again), which goes beyond the current PR in my opinion.

[JorgSchwinger]

I approve this PR now, however I have a general comment, which is actually not specific to to this PR, but about the general model structure: The way the sediment age and quality fields are read in and passed to HAMOCC break with the general paradigm of separating everything that is related to the BLOM model grid and parallelism from the core HAMOCC routines. To comply with this paradigm, the fields would be read in outside hamocc4bgc and then passed as an argument (as it is the case now for e.g. iron and fe-deposition). This might be something to think about at a later stage.

[jmaerz]

Hi @JorgSchwinger , I am not entirely sure, if I really understand the issue with these fields as they -can be- dynamically changed during runtime and are just once read at initialization for initialization from scratch (afterwards included in the restart file), but maybe better to discuss this offline (and for a later PR).

@TomasTorsvik , I leave the merging to you so that you can better organize the tags for NorESM.

[TomasTorsvik]

I'm putting the merging of this PR temporarily on hold until we get in #691 (hopefully this is soon).

[TomasTorsvik]

@jmaerz - #691 is merged, so you can merge this now.