Configuration parameters set in multiple places

[anton-seaice]

One of the discoveries from #81 is that some IO parameters are set in nuopc.runconfig but also could be set in ice_in and its not clear which is used.

I propose we delete the unused lines in either file. I think I have done this in ice_in through ACCESS-NRI/access-om3-configs#17 but there are lines to delete in nuopc.runconfig, including:

• references to GLC model
• MOM Parallel IO parameters (which are ignored by the MOM cap, MOM uses the netcdf library, not the Parallel IO library).
• ice_nx = 360, ice_ny = 300

I suggest we take a conservative approach. Rather than audit every line, let delete the ones we know are not used and merge the change but leave this issue open. As more unused lines are discovered, we can make another change referencing this issue.

[anton-seaice]

I will add some notes to this effect to the wiki once I get write access :)

[anton-seaice]

Another example:use_leap_year in ice_in needs to be set for the history netcdf units to be correct, even though we have already set the calendar in nuopc.runconfig Now fixed by #112

[dougiesquire]

See also some of the notes here https://github.com/COSIMA/access-om3/wiki/NUOPC-driver

[anton-seaice]

nfreq = 25 in ice_in needs to match SPECTRUM%NK in WW3

EDIT: and is hardcoded in the cice nuopc driver:

[anton-seaice]

We seem to have:

  model_maskfile = "./input/access-om2-1deg-nomask-ESMFmesh.nc"
  model_meshfile = "./input/access-om2-1deg-nomask-ESMFmesh.nc"
  nx_global = 360
  ny_global = 300

in datm_in and drof_in ( and docn_in)

[aekiss]

Can we make a simple script to flag any instances like this in configurations? The script would serve to document these gotchas as we discover them, and at some point might even be something we'd want to add to CI. Could be handy as we develop new configs.

[anton-seaice]

Can we make a simple script to flag any instances like this in configurations? The script would serve to document these gotchas as we discover them, and at some point might even be something we'd want to add to CI. Could be handy as we develop new configs.

Dougie suggested doing it in in payu (#109).

I think "best practice" would be to update the cmeps drivers ... possibly more trouble than its worth.

[dougiesquire]

Dougie suggested doing it in in payu (#109).

Yeah I think it makes sense in many cases. That way the checks will run automatically whenever someone runs the model (and could pick up local changes that are inconsistent). Also, the checks will be automatically run in the repro CI, which uses Payu (though we probably will want a workflow specifically running the checks)

[CodeGat]

Hey - coming in with a bit less domain knowledge here - I'm doing up CI checks as part of configuration modification as part of ACCESS-NRI/model-config-tests#63:

• What parameters should we be checking for? Everything that is in nuopc.runconfig? A subset?
• What files should we be checking against? There is reference to ice_in but also to other files like datm_in and drof_in. While we're at it, what are those filetypes?
• Are the names of parameters in nuopc.runconfig and the other files the same?