Running AM3 with COSP2

Hi Team

I managed to run AM3 with COSP1 giving reasonable output. There is an option to run with COSP2 under um>namelist>UM Science Settings>Section 01 -02 Radiation>COSP. However, it failed as COSP2 code is not included with the following error message:

????????????????????????????????????????????????????????????????????????????????
???!!!???!!!???!!!???!!!???!!!       ERROR        ???!!!???!!!???!!!???!!!???!!!
?  Error code: 9
�2�@LATOR
?  Error message: This is a stub interface to COSP2.You need to include the external COSP2 code.
@�'��
0(z�p[???????????????????????????????????????????????????????????????????????????????

May I ask how to include those open source code (GitHub - CFMIP/COSPv2.0: COSP - The CFMIP (Cloud Feedbacks Model Intercomparison Project) Observation Simulator Package)?

Though it seems optional to change to COSP2, I found some of the COSP1 output a bit strange (for a beginner). For example, when I output the variable COSP: ISCCP CTP-TAU HISTOGRAM, the global mean, annual mean total cloud fraction is less than 30% (which is supposed to be >60%). I am wondering whether COSP2 may give similar results or not.

Regards, QG

Hi Qinggang,

It would be quite a lot of work to couple the external COSP2 code to run online in AM3 yourself. (I know this as I coupled COSP to run online in WRF many years ago :upside_down_face: ). I would look to find some AM3 source that already has the COSP2 code coupled to the physics schemes.

Are you working with the AM3 source code or a precompiled ACCESS-NRI version? Asking because I’m currently looking at some rAM3 source code and I can see a COSP2 directory in the atmosphere source code. It’s possible that it’s already there but you need to recompile with it on.

Thank you Bethan

I do not yet work with AM3 source code, but I will have a look and try to recompile once gadi is online.

1 Like

Looks like you might be in luck- seems the COSP2 code is already included in the UM repository here (if you don’t have access to that, request here and specify you want to access the model source code). Actually building it with COSP2 is up to you, we’re unlikely to support that any time soon.

1 Like

Thank you Lachlan. That sounds great. I have access to the source code.

So two steps are required: 1. Recompile UM with COSP2; 2. Point AM3 to use the recompiled executable. Hopefully not too difficult with AM3 :wink:

1 Like

Sounds like it might work @qinggangg. The only thing that concerns me is that it sounds like COSP2 is already in the UM source, and you said the switch for it is in the namelist, so in theory the COSP2 code should already have been compiled into the built executable. You don’t need to recompile for a namelist change, so in this case I’m not sure why it didn’t work for you already.

But I don’t know what ACCESS-NRI have packaged into the precompiled executable, so perhaps the COSP2 source wasn’t included in it.

Do report back - if the AM3 Alpha feedback thread isn’t the right place for this (as it’s not within scope of NRI development) then maybe create a new thread somewhere on the Hive, or post on one of the AM3 pages on Cumulus.

I suspect the code is included/excluded from the build depending on preprocessor directives. Unfortunately this is not done very transparently for the UM code- you have to dig into our access-spack-packages to see the build configuration for the different applications of UM13.

I will move this conversation to a different thread, because it’s pretty far beyond the scope of what we plan to officially support.

1 Like

Agree. Thanks @lachlanswhyborn!

Thank you both. I will give it a try and open a new thread.

I’ve moved it to this thread, use this one to discuss building with COSP2

1 Like

Yup, @qinggangg this is the new (branched) thread, so continue the conversation here :slightly_smiling_face:

So some baby steps now :laughing: May I ask, are there some documentations regarding how to coompile UM with variable configurations and how to point AM3 to the new executable?

I haven’t made a local build of any model myself yet (been too busy helping other people’s modelling :joy:) but from a quick search, it looks like to do this with ACCESS models on gadi you will need to use spack:

1 Like

Yep, start with getting a handle on Spack. Unfortunately our UM13 Spack package is by far the most complicated package we have. This uses specific configurations for each application, which then use the UM build configuration files on Github (rose-stem and fcm-make), as well as configurations on the MOSRS mirror for some of the other components which we don’t have forks of like GCOM… It’s absurd to be honest. I’m still trying to get my head around it.

1 Like

Thank you both. Knowing how difficult it is is already a great step :rofl: I’ll look into it.

1 Like

Hi, I just followed the instructions on Modify and build an ACCESS model’s source code to build the model. The output could be found here: /home/563/qg8515/spack/restricted/ukmo/release/linux-rocky8-x86_64_v4/intel-2021.10.0.

A few quick questions:

  1. There are two folders under the above folder starting with um-13.1-***. What are the differences and which one shall I use?
  2. How do I ask ACCESS-AM3 to use this build?
  3. How could I change configuration settings while building the model, in order to use COSP2 rather than COSP1?

I am walking through the recommended websites and will appreciate any insights.

I can’t see that directory, since it’s in your home, but I suspect there should be a bin directory there? If there is, it should contain um-atmos and um-recon. I think you should be able to change the default and recon targets in app/um/rose-suite.conf to the binaries you’ve built, although I’ve not tried.

As for changing the configuration settings, I’m not sure. I did have a bit of a longer look at that COSP2 directory in the UM source, and I think I may have been wrong on my initial assessment- I think that whole folder may be a stub (just there to allow the code to build while keeping the COSP2 code paths available), and the actual COSP2 source code is not contained there.

Aha yes, that directory is under /g/data/v46 and I think only project members have read access. I copied /home/563/qg8515/spack/restricted/ukmo to /scratch/public/qg8515/.

There is a bin directory but it only contains a file named sbang. I can find executables under release/linux-rocky8-x86_64_v4/intel-2021.10.0/um-13.1-lipklxyhoqkt2adsqkcfljw4zci6zee5/build-recon/bin/um-recon.exe and release/linux-rocky8-x86_64_v4/intel-2021.10.0/um-13.1-lipklxyhoqkt2adsqkcfljw4zci6zee5/build-atmos/bin/um-atmos.exe.

I changed it as suggested and is trying to run again now:
-default=um-atmos
-recon=um-recon
+default=/home/563/qg8515/spack/restricted/ukmo/release/linux-rocky8-x86_64_v4/intel-2021.10.0/um-13.1-lipklxyhoqkt2adsqkcfljw4zci6zee5/build-atmos/bin/um-atmos
+recon=/home/563/qg8515/spack/restricted/ukmo/release/linux-rocky8-x86_64_v4/intel-2021.10.0/um-13.1-lipklxyhoqkt2adsqkcfljw4zci6zee5/build-recon/bin/um-recon

Agree, the error message did say Error message: This is a stub interface to COSP2.You need to include the external COSP2 code. It seems to become too difficult now.

I don’t know if you have access to the COSP2 source code, but if you do, I would try to copy that into the UM source directory in place of the stub directory and build that.

COSP2 is open-access. I will check their web page and have a try now.