Sounds like it’s not included as default:
1 Like
@qinggangg if copying the code into the stub directory doesn’t work (i.e. you need to couple it), I would recommend contacting Alejandro Bodas-Salcedo.
I’ve just had a poke around in the (now frozen due to the git migration!) svn repo and there are some COSP2 branches there.
https://code.metoffice.gov.uk/svn/um/main/branches/test/alejandrobodas/
If he has something working and is willing to share, it might be easier to take an existing suite implementation and merge it into AM3 than trying to couple COSP2 from scratch.
If you need his email address, send me an email or private message.
Thanks @bethanwhite I will contact Alejandro and Mark Webb now.
Please don’t copy source code or builds to publicly accessible locations. This is expressly forbidden by the UKMO license terms.
I know. I wish it weren’t so too.
If you need to share you can make directories like above accessible to only a limited set of users using ACLs (setfacl).
Run this to limit access to your shared directory
chmod go-rx /scratch/public/qg8515/
And run the following command to give a specific user XXXXXX access:
setfacl -m u:XXXXX:rx /scratch/public/qg8515/
1 Like
Thank you for reminding me. Sorry I forget about the license issue with UM. I just deleted it.
1 Like
No worries. I suspect in this case it is probably easier for you to use the rose+cylc compilation to modify and build the model, as suggested by @bethanwhite.
The spack build is something ACCESS-NRI supports, and it makes our job easier because spack compiles and manage many of the dependencies in a systematic way.
The barrier to entry for someone like yourself is lower using the traditional suite build rather than spack as long as all the dependencies are easily available. The qualification is important, because it has taken a fair bit of work in the past to make sure this was true.
We could switch the suite compilation to use spack, but it is non-trivial, not consistent with what other sites currently do, and not necessarily what everyone in the community currently wants. Hence we’re in something of a limbo between one approach and the other at the moment.
@qinggangg in the meantime you could try just copying the COSP2 code into the stub directory and see if the COSP1 coupling picks it up.
I’m assuming the motivation for running COSP2 is the scientific concern about the low annual mean total cloud fraction? It might be easier to do some digging into that in the meantime as well (even bring it up with Alejandro to ask if it could be a COSP-related issue).
I think @Aidan is right and it would be easier to use the rose + cylc model build. The only thing is, the only supporting documents on the Hive for modifying and building code are spack-related.
1 Like
Thank you @Aidan I am happy to try any approaches that may work. I did also try to recompile using rose/cylc but that failed as well. Here is a brief summary of what I have tried and failed.
-
I tried to build UM while running AM3 by setting
TASK_BUILD_UM=trueas suggested here. It failed right away, sorry I forget to record the error message. -
I tried to build the model using spack as described here and run AM3 with new executables. But it also failed for the job
reconwith the following error message:
? Error code: 30
? Error from routine: CHECK_UNAVAILABLE_OPTIONS
? Error message: One or more JULES options (1) have been incorrectly set for use in UM-JULES. Please see job output for details.
? Error from processor: 0
? Error number: 0
Would it be related to the warning message while I do spack install:
==> Warning: The vn13 model sets DR_HOOK=false but the spec sets DR_HOOK=true. The value true will be used.
==> Warning: The vn13 model sets eccodes=true but the spec sets eccodes=false. The value false will be used.
I am fine to move ahead with either rose/spack, whichever is easier for us. If you may have any thoughts for me to try, I am happy to do it.
Does this apply for rose run directories too? e.g., if the cylc-run directory, which is sent to your scratch automatically, is also protected then this implies every user has to tighten the permissions of their root /scratch/project/user directory, otherwise anyone on their project will be able to access their cylc-run information.
No. If they contain no source or binaries that is fine.
If you’re using ACCESS-NRI precompiled binaries you’re sweet: we put the in directories that only allow access to members of specified groups.
I don’t know where the rose+cylc jobs compile their code, or if there are any modifications to permissions of the compile directories, so can’t comment on that.
1 Like
It usually copies the scripts used to the working directory. This can potentially be an issue for ancillary suites which will source things from the ANTS Contrib, which is still private, even though the ANTS core is now public on Github.
1 Like
This is moving off-topic, so apologies (but perhaps we should branch it and pin it elsewhere), my current understanding is:
rose suites: 
source code: 
executables:
processed suites (cylc dir): if they don’t contain or point to source code or compiled executables [EDIT: accessible code / executables]
1 Like
I heard from Dr. Alejandro Bodas-Salcedo that COSP2 is not readily available in UM, and COSP1 is scientifically equivalent to COSP2. So I will go with COSP1 and try to find the issue with total cloud cover. I will close the ticket for now.
2 Likes
Hi Qinggang - great to see you are using COSP here - I’ve done a bit with COSP in AM2 (sorry I’m so late to the party here to help) but I’d love to see how you go with AM3 and also if you have any questions about the post porocessing that the COSP output needs - let me know - I know it took me some time to work all of that out, so perhaps I can be of help!
Hi Sonya.
Thank you, that’s nice to know.
The main issue I meet is that for the variable cosp_isccp_ctp_tau, the global mean annual mean sum across CTP and Tau, which should represent total cloud cover, is only about 36%. Other products normally suggest a total cloud cover of around 60%. Have you meet this issue before?
Alejandro suggests “the underestimate is likely to be caused by using stash 2337
without correct for the sunlit fraction (2330). You need to calculate 2337/2330, with missing data where 2330 == 0.” I am not sure how it works with monthly data. Have you tried this before?
What are included in your post processing steps and what research did you use COSP for?
Thank you in advance.