When coupling the senior and junior UMs with the UMUI, we essentially had two sets of input files (where the input for the junior UM had a `2' extension, i.e. SHARED became SHARED2); and there were mostly two sets of environment variables (again, the environment variables for the junior UM were given a `2', i.e. AINITIAL became AINITIAL2). And the code for junior UM was modified to read these 2nd versions of the input files - mostly namelists - and environment variables.
We were then required to run three stages
The advantage of Rose should be that it should be possible to run stages 1) and 2) at the same time. And because stage 2 won't see the environment variables or files from stage 1, and vice versa, it shouldn't be necessary to add the extension `2' for both the input files and environment variables needed to run stage 2), the reconfiguration of junior UM.
The structure we expect is
| fcm_make_um | fcm_make_um2 | |
| ↓ | ↓ | |
| fcm_make2_um | fcm_make2_um2 | |
| ↓ | ↓ | |
| recon | recon2 | |
| ↓ | ↓ | |
| coupled | ||
where the left hand branch is for the senior UM and the right hand branch is for the junior UM, and it finishes with running the coupled job.
Environment variables and namelists are set and created in Rose. It is the meta data which specifies where variables are found in the `rose edit' gui and it specifies which variables get written to which namelists. Typically, a standard meta file is used and the final directory structure will be something like rose-meta/um-atmos/vn9.2/rose-meta.conf.
An entry for an environment variable, like RUNID, will look something like
[env=RUNID]
compulsory=false
description=5-character ID associated with each run
help=...
ns=env/runtime
pattern=^[a-zA-Z0-9]{5}$
where `ns=env/runtime' indicates the variable can be found in the `rose edit' gui under the menus -> env -> runtime.
When we couple the atmosphere and ocean the variables all appear in the same app, which is generally fine as all atmosphere and ocean have different names for their variables. However, if we have two UMs, i.e. two atmospheres, and we want RUNID to take one value for the senior UM and one for the junior UM, we can't.
For any namelist variable, like i_so2_hi_level, there are always two issues
An entry like
[namelist:run_ukca=i_so2_hi_level]
compulsory=true
description=Model level to emit SO2 high level emissions into
fail-if=this < 1 or this > namelist:nlsizes=model_levels
help=This must be between 1 and the number of model levels. It will be
= ignored if the CLASSIC sulphur scheme is on,
=
sort-key=a8
type=integer
indicates that i_so2_hi_level will appear the run_ukca namelist list, and the entry
[namelist:run_ukca] compulsory=true description=run_ukca ns=namelist/UM Science Settings/section34 title=Section 34 - UKCA: UK Aerosols and chemistry
shows the variable (assuming it's active) will appear in `rose edit' gui under menus -> namelist -> UM Science Settings -> Section 34 - UKCA: UK Aerosols and chemistry
This is fine, unless we want a i_so2_hi_level value for both senior and junior UMs and, generally, we want two sets of run_ukca namelist variables - one for each UM. It would be a considerable amount of work to have an alternative name for i_so2_hi_level, run_ukca, and all the other namelist variables for use in the junior UM.
Unlike coupling a UM to the ocean, it seems that coupling two UMs together requires at least one extra app.
We've looked into at having a few extra apps, where there's an app for input needed just for senior UM, an app for input needed just for junior UM, an app for input needed by both, and then an app for running the senior, junior (and any ocean) executables concurently - which might be combined with one of the other apps. However, I think we only need one other app.
This one extra app would be a full UM app, say `jnr_um', very similiar to an app used to run a stand alone UM executable (no coupling). The environment variables and input for the senior UM would still be created with the `coupled' app, while the environment variables and input for the junior UM would be created with the `jnr_um' app.
In the diagram above (in `Task diagram' section), the `coupled' app is used for both the `recon' and the `coupled' tasks, while the `jnr_um' app is only used for `recon2' task. However, one of the first jobs in the `coupled' task would be to
By doing this, we'll have the same type of input which we had for running stage 3), as shown near the top of the page, for concurrently running senior and junior UMs with the UMUI.