Thanks, Ros, that has worked. Could I just check whether it is possible at present to run jobs at vn11.9 and above on Archer2? I note that the Archer2 UM page (http://cms.ncas.ac.uk/wiki/Archer2#InitialsetupforrunningUMRoseCylcSuitesonARCHER2) says that versions up to and including 11.8 have been installed and there exist branches from Simon Wilson up to and including vn11.9 for the config_root_path.
I ask because I have taken a copy of u-be303/archer2 and upgraded the suite to vn12.0 (using rose app-upgrade vn12.0) to take advantage of the new CRI-Strat 2 chemistry lodged for vn12.0. If vn12.0 is not possible, I can use an earlier version and manually add the chemistry.
I would give vn12.0 a go.
I think that the issue with previous ones was that the config changes for ARCHER2 hadn’t all been included in the trunk (or that there was a minor typo pointing to a library).
If you try it and it doesn’t work then let us know.
Dave
Thanks, Dave. I ran my suite (u-cj269) ugraded to vn12.0 using fcm:um.xm_br/dev/simonwilson/vn11.9_archer2_compile in the config_root_path and just the trunk in um_sources. The run failed on fcm_make2_um with:
[FAIL] c_shum_word_bytes.h: bad or missing dependency (type=include)
[FAIL] required by: shumlib/shum_data_conv/src/c_shum_data_conv.c
[FAIL] fcm make -C /work/n02/n02/jweber/cylc-run/u-cj269/share/fcm_make_um -n 2 -j 128 # return-code=2
Received signal ERR
I haven’t seen this before - would you have any recommendations?
Simon’s branch uses gcom 7.4, but UM12 would ideally want 7.5 (although it should be slightly backwards compatible with 7.4 …).
I would first remove the extra branch, and make sure the macro is run fully.
If you’ve tried this (with Cray compiler env 10 - because there can be bugs with the c code for shumlib in 11) then let me know and I’ll try to look more closely at your suite this afternoon.
P.S. If I want to upgrade a suite, I use
cd [your suite]
rose macro --fix
cd app/um
rose app-upgrade vn12.0 (or whatever)
cd …/fcm_make
rose app-upgrade vn12.0
Thanks, both. I take your point re upgrading over many versions.
I ran rose macro --fix in roses/u-cj269. I then reran rose app-upgrade vn12.0 in app/um and app/fcm_make_um as a check and this returned [FAIL] vn12.0: already at this version. I removed the branch from the root_config_path but the suite then failed on fcm_make_um with:
[FAIL] config-file=/home/jmw240/cylc-run/u-cj269/work/19790101T0000Z/fcm_make_um/fcm-make.cfg:3
[FAIL] config-file= - /fcm-make/ncas-ex-cce/um-atmos-safe.cfg
[FAIL] /fcm-make/ncas-ex-cce/um-atmos-safe.cfg: cannot load config file
[FAIL] /fcm-make/ncas-ex-cce/um-atmos-safe.cfg: cannot be read
[FAIL] No such file or directory
I’m not sure how to check with Cray compiler I have used - what’s the best way to find out?
You might have better luck working from a vn11.9 suite on Monsoon2 that you have from your UM ticket um:#6135 and then moving this to ARCHER2 using the instructions here:
Thanks, Luke. The current suite is u-cj269. For the vn11.9 suite from ticket #6135 for the lodging of CRI-Strat 2, I think that was a special lodging suite - would that make running normal jobs on it harder?
In general, is it best to do a rosie copy [suite-id]/archer2 for making an Archer2 suite from a Monsoon suitable or is that just applicable for certain suites listed in the example jobs table in http://cms.ncas.ac.uk/wiki/Archer2? I couldn’t work if u-be303/archer2 were special cases.
99% of the time you want to do an ordinary rosie copy to copy a suite to a new suite id so don’t worry about branches of suites for what you’re doing now.
The only reason we used a branch in some of suites was because we wanted to do parallel Archer2 development on a branch without affecting the old Archer version at the time and then eventually will merge those changes into the trunk.
Thanks, I now understand. I had initially thought only those listed as [suite-id]/archer2 could be converted to archer2 suites from Monsoon but I understand this is not the case and will give me greater freedom to in terms of which suites I want to copy and potentially upgrade. In terms of upgrading suites, would you recommend doing it in stages - for example going from vn11.1 to vn11.5 and then again from vn11.5 to a higher version?
We strongly suggest trying to avoid upgrading suites, if possible. Upgrading from 11.9 to 12.0 would probably be fine but upgrading through 9 UM versions will very likely cause loads of issues. It’s better to start with a suite at a version as near to what you want as possible.
Thanks for clarifying, my initial desire to upgrade was based on the fact that most of the CMIP6 style runs (e.g. AMIP) were run at at vn11.1 or vn11.2 and there have been quite a few updates since then. I will have another look at other suites and see how best to proceed.