Experiment proposal: AMIP-style ACCESS-AM3 N96 1982-2025, with prognostic aerosol and COSP1

Atmosphere Experiments
1

Experiment title :bell:: AMIP-style ACCESS-AM3 N96 44-year simulation 1982-2025, with prognostic aerosol and COSP1

Summary :bell:: It is an extension of the previous experiment proposal. I have run the control simulation AM3-N96 (access-am3-configs), an amip+4K simulation (am3-plus4k), a climatological-aerosol simulation (am3-climaerosol), and a climatological-aerosol+4k simulation (am3-climaerop4k), each for 6 six years here: /home/563/qg8515/cylc-run. I have thoroughly checked all model output variables including diagnostics from the satellite simulator COSP1 here: /home/563/qg8515/figures/4_um/4.2_access_am3/4.2.0_sim_obs. I plan to extend the simulation from 1982 to 2025, for better comparisons with recent observations.

It is very closely related to the high-res N512 AM3 simulation of the Centre and their N96 counterpart. Given there will be many differences in configuration (e.g. land setup and boundary conditions), it may be interesting to do a cross-comparison later together.

It could also be interesting for anyone who is interested in cloud feedbacks, aerosol-cloud interactions etc. For my six-year tests, the cloud and radiation output from the climatological-aerosol simulation is very close to the output from the prognostics-aerosol simulation.

Scientific motivation: Cloud feedback remains the leading source of uncertainty in estimating equilibrium climate sensitivity (ECS). Given large ECS in ACCESS-CM3 and UK models employing the latest UM, it is instrumental to investigate cloud responses to evolving environmental conditions in these models. Here we choose to focus on ACCESS-AM3, the atmospheric component of these model, to elucidate the role of clouds in the model responses to radiative forcing.

Experiment Name :bell:: am3-control
People :bell:: Qinggang Gao, Yi Huang
Model: ACCESS-AM3
Configuration: https://github.com/ACCESS-NRI/access-am3-configs
Initial conditions: Default
Run plan: 1 simulation, 44-year, N96 resolution
Simulation details: 1982, global
Total KSUs required :bell:: 15 KSU / year * 44 years = 660 KSU
Total storage required :bell:: 34 GB / year * 44 years = 1.5TB
Outputs:/g/data/gx60/experiments/2026-01-21_am3-climaerop4k/cylc-run/
Restarts: Default
Related articles:
Analysis:

Conclusion:

2

Hi Quinggang, This would be of intererest to our work as a launch point for our future plans to add dynamic INP into the global model - we could use a run like this as our control! @ZhangchengPei I also have a masters project that is hoping to asses how best to evaluate a GCM to point obs at Kennaook Cape Grim, so a long run like this may also be quite useful for that !

3

Before running, Sonya and I could have a look over the output requests to make sure all the necessary aerosol diagnostics are included?

4

Hi @sonyafiddes and @Matt_Woodhouse. Thank you for your interests in this experiment. We would be very happy if this experiment could be more broadly used as a control simulation for your research.

The experimet will be accessible once finished (in weeks). And I am happy to provide more information for the community to access or visualise the output.

I was also going to suggest that you could look into the current output, which is configured for my research purpose. I could add any output that you are interested in. I will also discuss with the Centre high-res team to configure a common output, so it can also be directly comparable with their N96 and N512 simulations.

I am not allowed to make the Github repository public, could you let me know your github username so I could invite you as a collaborator of the project? I used a branch n96e-vn13.1 in the repository ‘am3-control’. A 2-year output could be found on gadi under /home/563/qg8515/cylc-run . You can also check visualization of more than 100 variables from previous trials here ‘/home/563/qg8515/figures/4_um/4.2_access_am3/4.2.0_sim_obs’.

I output three netcdf files, ‘a’ denotes monthly data, ‘b’ denotes hourly data, and ‘c’ is only for instanteneous daily cloud droplet number concentation.

5

Quingang - I might send you a stash pack, that hopefully you could just copy-past into your app/um/rose-app.conf file - it will have everything Matt and I usually require.. Alternativly - if you look at my old AM2 suite in the rose GUI (u-dg657), then you can see everything there too a bit more easily :slight_smile: There are a lof output fields listed, but at monthly resolution should not be too much more of an overhead I hope! I’ll try to get you the stash pack later today.

6

I can check how easy it is to integrate your stash pack. Please only include necessary output, as storage can be an issue.

7

Hi Qinggang - here are the aerosol fields that are standard. I have them output just for the troposphere (‘DALLTH_TR’) to save space. Let me know if you have any issues :slight_smile:

aerosol_stashpack.txt (5.1 KB)

8

These stash requests are not compatible with AM3. A copy-paste of any element crashes rose with wrong syntax. And there is also no TDMPMN time profile in the default AM3 configuration.

Would it be possible for you to work with AM3? add variables and profiles as requested and then let me know the track changes so I can implement?

9

If working with AM3 is too time-consuming for you, you can maybe also just tell me the specific time and domain profiles details you need, and confirm the section and item are right for each variable, I can try to compile them.

For now I am only working with monthly and hourly time frequency, and single level or all model levels.

10

Hi @sonyafiddes and @Matt_Woodhouse, I created a post to gather community research interests in this control simulation and requested output variables here. You can check the current output variables here.

Please let me know the details about the additional output variables you request there before 6 pm this Thursday, 12 Mar.

11

Ah sorry to hear that they don’t transfer. Could you send me the error file to check if there is a simple thing I could do to fix? It would be easy enough for me to send you the TMDMPMN profile too.

The time profile is just the monthly mean. The domain profile is global, and to reduce storage, I limited the verticle output to just the troposphere, but you could just keep at the default to use all the verticle levels too. individual item/section are in the text file, and they should be right. It includes the mass and number of each aerosol mode, including composition breakdowns for the mass. It also includes the dry diameters needed to calcualte size distributions and then some of the gas phase fields (eg. DMS, H2SO4), and then some of the bulk CCN/N3/CDN fields! I can try to take a look, but probably not until thursday.

12

@sonyafiddes I just found the problem lies with indentation and incompatible syntax. I will change it and share it for check this afternoon.

13

@sonyafiddes I added all the 38 variables as attached with package name ‘AEROSOL’. I also attached the modified file compatible with AM3. Could you please double check whether these 38 variables are what you want?
I simplified the timestep to either monthly, daily or hourly, and either single-level or all-model-level. For the hourly variables I made it instanteneous.
aerosol_stashpack copy.txt (4.6 KB)

Screenshot 2026-03-10 at 13.45.08
Screenshot 2026-03-10 at 13.45.081920×1050 274 KB

Screenshot 2026-03-10 at 13.45.25
Screenshot 2026-03-10 at 13.45.251920×1052 278 KB

14

Amazing - that looks great to me. I didn’t realise I had some hourly outputs in there - I don’t think I need them, so feel free to remove them. The DMS flux and concentrations in sea water (sec 0, items 132, 133) for example should be moved to the monthly means instead of 1HR :slight_smile: and it looks like you have a double up of item 71, sec 34 (DMS mass mixing ratio). @Matt_Woodhouse or @ZhangchengPei would you like to do a sanity check of anything else we might need?

15

Thanks @qinggangg and @sonyafiddes!

From my end, could you please add one more variable - “area cloud fraction in each layer” (Section: 0, Item: 265). It will be a 3D variable and ideally with daily output just like the COSP effective radius.

Combining this with the hydrometeor mass mixing ratios and thermodynamic variables you’ve already included will allow for apple-to-apple evaluations of the model against satellite and ground-based radar/lidar observations using simulators like EMC² or ALCF.

Cheers,
Zhangcheng

16

Hi @ZhangchengPei. Sure, based on my experience with rAM3, Area/Bulk/Total cloud fractioin in each layer are equivalent, so I only output ‘TOTAL CLOUD AMOUNT AT EACH LAYER’ as monthly hourly mean.

For the obserational products, is it Level 2 (instanteneous) or 3 (gridded)? Would you prefer instanteneous output or time average? In case of time average, would you think only output monthly means at each UTC hour is more efficient?

Just FYI, for 3D daily values (85 levels * 30 days), it would cost 10GB/44 years. So it means 240 GB/44years for hourly values. Please let me know your preference.

17

@ZhangchengPei. I just confirmed that for AM3 as well, a monthly mean absolute difference between area and total cloud area at each level for Jan 1982 is below 0.1%. Zonal mean plots of them are also quite similar as attached. So I will stick to total cloud amount.

Currently I have monthly and monthly hourly mean values. If you do need higher temporal resolution data, please let me know whether it should be instanteneous.

4.2.0.1 TCF am3-control global original 1982-1982
4.2.0.1 TCF am3-control global original 1982-19822031×2244 163 KB

4.2.0.1 ACF am3-control global original 1982-1982
4.2.0.1 ACF am3-control global original 1982-19822031×2244 164 KB

18

Thanks @qinggangg for the details! The total cloud amount should be good to use :slight_smile:.

Regarding the observational products, we will primarily be evaluating against instantaneous data from various lidar networks for cloud fraction, cloud base height, cloud occurrence… As the ALCF lidar simulator relies on highly non-linear optical calculations, it would requires instantaneous outputs rather than time-averaged to ensure an apple-to-apple comparison.

I checked the documentation of ALCF (https://alcf.peterkuma.net/), and here is the wrap-up of the STASH variables the simulator needs:

  • TOTAL CLOUD AMOUNT (m01s02i261) - 3D

  • QCL AFTER TIMESTEP (m01s00i254) - 3D

  • QCF AFTER TIMESTEP (m01s00i012) - 3D

  • TEMPERATURE ON THETA LEVELS (m01s16i004) - 3D

  • PRESSURE AT THETA LEVELS (m01s00i408) - 3D

  • SURFACE PRESSURE (m01s00i409) - 2D

  • OROGRAPHY (m01s00i033) - 2D (Static) (the only new variable)

Could you please output these as 6-hourly instantaneous (00, 06, 12, 18 UTC)?

Based on your previous estimate, outputting these five 3D variables at a 6-hourly frequency should take around 200 GB for the entire 44-year run. This frequency will be good for capturing the diurnal cycle of cloud properties.

Let me know if this setup works for you!

Cheers, Zhangcheng

19

Hi @ZhangchengPei and @sonyafiddes I just run the simulation for Jan 1982 and the output is here /g/data/gx60/experiments/2026-03-04_am3-control/cylc-run/am3-control-test. I know it is a bit harsh, but would you have time to check briefly your required output this afternooon under share/data/History_Data/netCDF.
contra.pa1982jan.nc contains monthly data; contra.pb1982jan.nc contains hourly data; and contra.pc1982jan.nc contains 6-hourly data.

I will also have a check this afternoon and if no issue is found, I will run it for 31 years from 1982-2012 tonight.

20

Thanks a lot @qinggangg! The 6-hourly output looks good to me.