I plan to check impacts of the new convection scheme CoMorph on clouds in ACCESS-AM3 with this repository: /home/563/qg8515/roses/am3-comorpha. I set l_mcr_precfrac=.true. and i_convection_vn=12. The model output can be found here: /g/data/gx60/experiments/2026-03-04_am3-control/cylc-run/am3-comorpha/.
The job recon failed with the following error message:
????????????????????????????????????????????????????????????????????????????????
???!!!???!!!???!!!???!!!???!!! ERROR ???!!!???!!!???!!!???!!!???!!!
? Error code: 100
? Error from routine: CHECK_RUN_RADIATION
? Error message: i_fsd is set to use separate convective cloud arrays from
? deep, shallow and mid convection schemes, but i_convection_vn
? has been set to use the comorph convection scheme, which does
? not have separate deep, shallow and mid-level schemes.
? Error from processor: 0
? Error number: 0
????????????????????????????????????????????????????????????????????????????????
It may not be an essential part of my research but likely a nice-to-have thing. Is it easy to get AM3 running with CoMorph? Thank you in advance for your support.
Hi @qinggangg, note that CoMorph is not just a convection scheme but an entire series of physics package changes that accompany the new scheme.
You would be best to revert your changes, open the GUI and set the science setting to “CoMa9” where you would otherwise have GAL9 selected.
I haven’t run it in the global model myself yet (only regional), so I’m not entirely sure where that is in AM3 vs rAM3, but that’s the setting you need to change. That will pull in all the science changes that you need to run CoMorph.
Thank you. I set i_convection_vn=12 in the GUI (per description, this mean CoMorph is used) and many other parameters are changed automatically (I assume this is what you mean all the science changes?).
I cannot find any settings pointing to GAL9. It seems AM3 is using GA8.0: rose-suite.conf:EXPT_CONFIG='ga8p0'
I resolved the above problem by setting i_fsd=1. But the following error occurs here /g/data/gx60/experiments/2026-03-04_am3-control/cylc-run/am3-comorpha/:
????????????????????????????????????????????????????????????????????????????????
???!!!???!!!???!!!???!!!???!!! ERROR ???!!!???!!!???!!!???!!!???!!!
? Error code: 30
? Error from routine: RCF_RESET_DATA_SOURCE
? Error message: Section 0 Item 92 : Required field is not in input dump!
? Error from processor: 0
? Error number: 1
????????????????????????????????????????????????????????????????????????????????
Section 0 and Item 92 points to the variable PRECIP FRACTION IN EACH LAYER. It may only be output when l_mcr_precfrac=.true.. Is there a start dump where this variable is present? Or how could I avoid this check?
In addition, I see the *.ainitial file points to /g/data/vk83/configurations/inputs/access-am3/CM3/de208a.da20000101_00_redated. Is it the initial condition? How is it created?
Hi @qinggang, I’m just having a look at the suite GUI for the AM3 2025.11.01 tag.
In the regional nesting suite (rAM3) there is a science configuration setting with options such as GA8, GAL9, CoMorphA. That one setting applies all the relevant settings for that particular science configuration to the model. I can see that there is no option to change the science configuration from anything other than GA8.0 in AM3 (see screenshot).
I would be cautious continuing. For example, if I set i_convection_vn=12, changes automatically appear in Section 05 - convection, but nowhere else in the suite.
To run CoMorph-A as tested and intended by its developers, changes to other parameterisations should also be made in conjunction - see Section 3.2 of the CoMorph-A paper. For example, graupel should be included in the microphysics. If I set i_convection_vn=12 in the convection section, I get no accompanying change to graupel_option - it doesn’t change value in Section 04 - Microphysics; Ice processes from no graupel to an option for graupel. This makes me suspicious that simply changing the option for the convection scheme isn’t pulling through the full set of package changes that are needed to run CoMorph-A in a scientifically valid way.
Also note that TOA tuning is changed in CoMorph-A (see Sec 3.3 of the paper), and if i_convection_vn=12 isn’t picking up all the science changes - including the tuning - that should be made to run CoMorph-A. it’s unlikely to give you valid results for looking at cloud impacts.
I resolved the above problem by setting i_fsd=1.
I would also be cautious about doing this without confirming with the CoMorph developers that it is a change that is compatible with CoMorph.
Hi @bethanwhite Thank you. That is good to know. It seems a good amount of efforts may be required to run AM3 with CoMorph-A. If the NRI-team has any ideas to circumvent the problem step-by-step, I am happy to try.
Hi @cbengel Thank you. That sounds interesting. I remember my attempts to run CoMorphA with RNS/RAS also failed. So instead of resorting to rAM3, I may prefer stick to AM3, even if it does not work.
Another option may be to contact someone at the Bureau or Met Office to see if there is a GA8 CoMorph-A climate suite that you could use to attempt to merge the relevant changes into AM3.
I suspect it could be complicated, but it would seem the best way to proceed if you were really keen to do an AM3 CoMorph-A run.
Your error above with a missing input field suggests that even if you did get the changes merged successfully, you might end up needing to run off a Met Office global model start dump as well. I believe that getting hold of one would require talking to Met Office people and going through the relevant license agreement procedures, as well as the actual data access and transfer process.
I’m not sure if that would solve the problem; any start dump from the Met Office will use JULES instead of CABLE. So you may end up with a new problem.