BGC namelist - extend by model parameters of iHAMOCC

[jmaerz]

Primarily at @JorgSchwinger , @TomasTorsvik and @tjiputra :

Thus far, the iHAMOCC BGC namelist only holds a very limited number of mainly logical switches and model input files. Most, if not all, model parameters are hard-coded and cannot be changed during run time. With the new hybrid coordinates and the extended nitrogen cycle, there will likely be a new phase of extensive model tuning for iHAMOCC. Hence, as already discussed a few times, it would be good to extend the BGC namelist by (a number of) model parameters to foster easy parameter tuning.

Therefore, I am herewith opening the discussion on how to best extend the BGC namelist by / how we generally handle model parameters in the future. This can include (but being far from conclusive):

• all or only selected, often tuned parameters (default parameters still hard-coded, potentially modified while reading BGC namelist)
• ideally being sustainable to foster allocatable No of tracers at run time (Enable tracer count to be determined at run time #105)
• how to best deal with rates wrt to units conversion?
• ...

It would be also good to know, what has been done already on this topic that is not yet in the master or beyond-CMIP6 branch.

[TomasTorsvik]

Thanks for bringing this up @jmaerz
I started on a framework for making the list of tracers allocatable, but it was never completed. I can try to revive the old branch I made for this.

[jmaerz]

@JorgSchwinger , I just keep note of what you suggested: potentially having an own module for fixed parameters such as for stoichiometry in iHAMOCC (such as rcar, rnit,, ..., making them real, parameter), that are not supposed to be tuning parameters.

[jmaerz]

Dear @JorgSchwinger and @TomasTorsvik , I try to revive the discussion on the BGC namelist again since model tuning is/will be an important task for both the nitrogen cycle and the hybrid coordinates. To provide a discussion basis, I could imagine the following layout of the code:

1. Initializing default parameters and potentially fixed parameters in two separate modules (- with rates in units per day/... - so not per time step)
2. Read tunable parameters via namelist (optional, Tomas suggested support via xml-change handling) - in case of a default run, nothing is read or changed (in case of full xml-change support, this would be different and all parameters would be set/read). Make sure that the parameters are distributed across all nodes.
3. Write the parameter list to log file
4. Multiply rates with dtbgc or equivalent (on all nodes).

In the case of a full xml support, it is questionable, if we need the initialization with default parameters (point 1). On the other hand, I would feel safer, if default parameters are hard coded and only parameters that should be changed are set via the namelist (questionable, if one can achieve this via xml-change...). As written, this should just provide a discussion basis. Any further opinions about the namelist?

[JorgSchwinger]

Just two comments
*I think there should definitely be default values set, everything else is prone to errors. The xml support is NorESM specific, so we shouldn't rely entirely on this.
*Anyway, I wouldn't add tuning parameters to NorESM's env_run.xml. In my opinion tuning is for expert users only, and therefore it suffices if this is done via user namelist. Once a tuning has been established for a release of NorESM, this can be implemented into the buildnml-script.

[TomasTorsvik]

Yes, I agree that we should set default values, preferably with the "protected" attribute, so that the values only can be changed by a function within the same module where the - parameter / protected variable - is defined. To my mind, at least, it makes sense to use the "parameter" attribute when there is no reasonable condition that would make you want to change a value (e.g. conversion between units), but use the "protected" attribute in all other cases.

[JorgSchwinger]

Not sure about the 'protected' - this would imply to move all namelist variables to a new module? Currently they are somewhat ordered after "topic" (carbon chemistry, biogeochemestry). Although I don't think it doesn't have to be like this, I would rather organize it as it makes sense from a structural point of view and see the 'protected' attribute as less important (we are not programming a library that is used by 1000s of developers...)

[TomasTorsvik]

Yes, the "protected" attribute is only applicable to variables declared in a module, so it would require some amount of re-structuring to do it this way. I must admit, I didn't consider how big of a change this would be. However, I don't think we need to collect all namelist variables in a single module, we can still read the namelists in different modules. It would just require collecting the parameters we want to have read-accessible in a namelist in the respective module, and create a "read namelist" function in the module.

The only parameters I see that are currently NOT declared inside a moduel are:

./carchm.F90:               INTEGER, parameter :: niter=20
./carchm_solve_DICsat.F90:  REAL,    PARAMETER     :: eps=5.e-5
./carchm_solve.F90:         REAL,    PARAMETER     :: eps=5.e-5
./inventory_bgc.F90:        real, parameter :: ppm2con = 0.35e-3
./ocprod.F90:               integer, parameter :: nsinkmax = 12
./ocprod.F90:               real, parameter :: dms_gamma = 0.87       ! dms_ph scaling factor
./powach.F90:               integer, parameter :: niter = 5
./profile_gd.F90:           real,     parameter :: dxy = 5.0
./profile_gd.F90:           integer,  parameter :: nread_base = 6
./profile_gd.F90:           integer,  parameter :: nread_ndic = 2
./profile_gd.F90:           integer,  parameter :: nread_ciso = 2
./profile_gd.F90:           integer,  parameter :: maxflds    = nread_base+nread_ndic+nread_ciso

[TomasTorsvik]

On the other hand, it does make sense to have some topical separation and a code structure that reflects this. I don't think it makes sense to do a major re-write to accommodate this, but I don't think it should be such a drastic change.

[jmaerz]

Admittedly, I am a bit shaken on the protect statement. On the one hand, I personally never liked it that parameters are declared/explained in different routines, since one misses an overview, which would call for considering a new(old) module - beleg_parm.F90 would be a good candidate. It would pay out on the long term, I guess. The module could then hold subroutines with the initialization - grouped into the different topics (with more lengthy explanations for the individual parameter setting) - and called early within hamocc_init - subsequently, a call can be made to the/a namelist for tuning parameters. Afterwards the dtbgc, etc. adjustment could be carried out, etc. On the other hand, I do agree that it is some work (time) that would go into it. An interim compromise would be to structure the code along this idea and if it's getting to much time effort, one can do it step-wise (maybe initially only for the default version and I could hook in my extNcycle work then as well). If that would be feasible for you, I would be in favor to opt for this.

[TomasTorsvik]

Ref. list above, the namelist should not include an assumption about the time step, so the namelist should be read before any refernce to dtbgc. So the suggested layout looks reasonable to me.

[jmaerz]

Hi @JorgSchwinger and @TomasTorsvik , I would like to revive this discussion. After tinkering around a bit with a simple dummy code for reading namelists, I see the issue with the protect statement even clearer. Hence, and following my previous suggestion, I would like to turn beleg_parm.F90 into a module mo_beleg_parm or potentially better (less German): mo_modelparam, which then could look as follows (potentially change beleg to init):

module mo_beleg_parm
use ...

contains

subroutine beleg_parm() ! called from outside 1
    call beleg_atmosphere_parm()
    call beleg_bio_parm()
    call beleg_sediment_parm() ! potentially - these can also stay outside of the module (which I did thus far also for the N-cycle, while I would prefer to have it in one module at some point)
    !etc....
end subroutine

subroutine beleg_atmosphere_parm()
     !as now in beleg_parm, but without time step conversion
end subroutine
! same for other parameters

subroutine read_bgcparm_namelist() ! called from outside 2
    ! read namelist

   call convert_rates()
   call init_atm_fields()
   call write_params() ! not sure, if before or after rate conversion.... - I would suggest after, with reverse conversion
end subroutine

subroutine convert_rates()
     ! conversion from /d (or other) -> /dtbgc
end subroutine

subroutine init_atm_fields()
    ! initialize atm fields with (potentially) updated values
end subroutine

subroutine write_params()  ! this could also go into another module
    !write parameters to file like now, with rates converted back to /d, etc.
end subroutine
end module mo_beleg_parm

which would allow to easily move on from this structure towards a the protect statement for the used model parameters (which one can do in a second step, if one wants). As far as I understand, splitting the parameter namelist into several namelists for using the protect statement for parameters declared in individual modules would require to have a namelist read statement in every of those modules (which I would tend to avoid). For now, I would minimize the code change and only change beleg_parm and hamocc_init (the latter for the calls to the subroutines and potentially wrt the namlist stuff). As parameter declared model parameters like stoichiometric values could be outsourced (as discussed above). Any further thought on this? Agreement or disagreements?

[JorgSchwinger]

Sorry I didn't have much time, last few hours before I leave for holidays. Some thoughts from my side, mainly on the naming:

• it is maybe a god idea to get rid of the "beleg" part of the names

• we do already have mo_param1_bgc, so the most logical name would be mo_param2_bgc (half a joke, but I think this would be acceptable, in any case the two modules should have the same base name "mo_param")

• then, inside mo_paramX, beleg_parm -> ini_param, beleg_atmosphere_parm -> ini_param_atm, etc.

• I don't understand the function of init_atm_fields

[jmaerz]

Hi @JorgSchwinger , thanks for the input! - this sounds like at least agreeing on the structural layout (naming can be changed easily). When looking into beleg_parm, the init_atm_fields is a part of beleg_parm that is currently writing default concentrations to fields (l. 122-142 in the current master branch). Since we might want to have access to those default values via the namelist, this requires a bit of reorganization (putting the initialization after having read the namelist). Whether this part can/should be moved into beleg_vars is another question.

[jmaerz]

Hi @TomasTorsvik and @JorgSchwinger , I started with the coding and restructuring of beleg_parms, now called mo_parambgc_ini.F90 (name upon change). If you're curious, have a look at: https://github.com/jmaerz/BLOM/tree/feature-iHAMOC-nml - I haven't included the NML-read thus far, but will do it soon. I guess, I would try to pretty it up a bit further (alignments of =, etc.). One thing, though, is that some parameters probably need to be re-calculated after the NML-read - which either means doubling of code or writing a function (param=param_fun()) for these parameters and calling this function twice (which I feel would be less error-prone). Not sure, what is the best. I thus far incorporated all parameters (excluding dtb) at the top of the module which would ease the modification towards the protect statement. A further question would be, if we should split up the namelist into two: one controlling one (also enabling xml-change) and one only for the parameter values (expert mode only). If so, where to put the atm_co2 - I suspect that many existing scripts already make use of this parameter - maybe add all external (atmospheric) parameters in the current controlling NML?!

[jmaerz]

Moving the discussion to #261 - to enable more concrete adjustments to the changes I made.