choose different namelist.recom depending on setup

[chrisdane]

Hi

The default behavior of

configs/components/recom/recom.yaml:
config_sources:
        recom:  "${namelist_dir}/namelist.recom"

needs to be changed depending on the setup in which recom is used: If the setup is awicm-1.0-recom (i.e. fesom+recom+echam), a specific namelist.recom should be used. If the setup is fesom-recom (i.e. fesom+recom), another namelist.recom should be used. Both namelists are provided in the recom repository, i.e. the model directory.

I dont know how to do that. Should this go into recom.yaml or awicm_recom.yaml or fesom-recom.yaml or a completely different place?

I tried this and it works: 12e95950. But now a user provided further_reading is not on top of the priority chain and is ignored in the finished config:

Thanks for help (is this the right place?)
Chris

[pgierz]

Hi Chris,

yes, this is the right place (i.e. it is a usage question and not a program bug. Use issues for the latter case). There are two options for this, please have a look:

1. You can set the namelist you wish to use directly in your user run configuration:

recom:
    config_sources:
        recom: /some/path/to/your/desired/namelist.recom

2. We could set the config_sources inside of a choose_ block. @mandresm put together a nice presentation which we will eventually migrate into the handbook: https://github.com/esm-tools/workshops/blob/main/PalMod2022/docs/pdf/6.4_choose_blocks.pdf

If we do option 2, this could be handled at the esm-tools internal level, e.g. the user would not notice this. You would need to modify configs/components/recom/recom.yaml accordingly.

Also, looking at your commit 12e95950: I am not sure I like dependence on environmental variables directly in the default configs. That currently is allowed everywhere, but it should be in real-world usage be restricted to user run scripts. You get a friendly error if you don't have the environmental variable set in your shell, but that is one more hoop people need to jump through, and if someone puts that in their dot files and then forgets about it, they will be running simulations with unintended settings. I prefer to use direnv for per-folder environmental variables, but there seems to be some induced wall time overhead (which I haven't had time to look at or understand yet)

[denizural]

Hi @pgierz, we already discussed that with @chrisdane and came to a conclusion. I am currently working on this and move this as an issue together with the pull request.

[pgierz]

Alright, then migrate this discussion to an issue please :-)

[mandresm]

To add to @pgierz suggestion:

I don't think there is a need for using the choose_ logic here. The default namelist in my view for the "standalone" recom.yaml file should be the one for FESOM-REcoM simulations. The AWICM-REcoM is a coupled setup, higher in the priority chain, and awicm-recom.yaml is the file to include the modifications needed by the fact that is a coupled setup, so defining the coupled-system specific namelist there (as it is already) makes sense.

The fact that your further_reading does not work is not related to this, but related to the fact that changes in the configuration files on the output are now in conflict with the further_reading. I would recommend to not use the further_reading option in your runscript, there might be a bug there, but will need further investigation. If you want to change the lists monthly/year/..._output you can do it directly from your runscript.

[nwieters]

Related issue: #646

[nwieters]

Hi @chrisdane,

has your question been answered here? Do you remember about your discussion with Deniz about this issue? I am wondering, because I think nothing as been done so far related to the issue #646.

@pgierz, do you know about the related issue #646?

Thank you for your update on this.