Forcing ACCESS-OM2 using ESM1.5 data

COSIMA Ocean
, ,
61

Hi @sofarrell, thank you for your input!

did you check all the parameters in the OM2 set up v ESM1.5 set up, particularly mixing parameters.
No I did not, would you happen to know any in particular I should check out?

The OM2 had an updated set up with more resolution near the surface whilst we had more resolution in the thermocline in the ESM1.5 set up.
I have now updated the vertical grid to follow ESM 1.5 and that did not help the differences in thermocline.

In relation to the time stepping the ice-ocean time of 1 hour would be the optimum to use
Yes, I have tried to change this in the &accessom2.nml as the earlier post, but I’m not sure if the structure of accessom2 vs esm means multiple things are being changed at once. The namcouple line has this:

#                      OCEAN --->>> ICE
#                      ----------------
##########
# Field 29 : Sea surface temperature (Celsius in MOM4, Kelvin in MOM5)
##########
t_surf sst_i -1 -1 0 o2i.nc IGNORED
NA NA
##########

so the coupling timestep is defined in OM2 somewhere else and thus not present in the namcouple file, and I’m not sure how OM2 ice_ocean_timestep propagates throughout the model.

I guess the same interpolation as used by OM2 for JRA-55 (3hour forcing) is being applied to your 3 hourly saved ESM forcing when you are using it in on the OM2 fields

Yes that is correct.

There is a lag in the ESM model in how it sees the updated atmospheric forcing but that would pass on to your forced runs as well.

This is what I want to correct. In ESM I notice the namcouple atm–> ice line looks like this:

#                      ATMOSPHERE  --->>>  ICE
#                      -----------------------
# -- 01: 
heatflux thflx_i 5 10800 4 a2i.nc EXPORTED
um1t cice LAG=+1800 SEQ=+1
P 0 P 0
#
LOCTRANS CHECKIN SCRIPR CHECKOUT
INSTANT
INT=0
CONSERV LR SCALAR LATLON 10 FRACNNEI FIRST
INT=0
# -- 02:

while in OM2 it looks like this:

#                      ATMOSPHERE  --->>>  ICE
#                      -----------------------
##########
# Field 01 : swflx down
##########
swfld_ai swfld_i -1 -1 1 NA EXPORTED
NA NA
P  0  P  0
#
MAPPING
../INPUT/rmp_jra55_cice_1st_conserve.nc dst
#########

I would naively add lags to the line in OM2 namcouple with NAs but it doesn’t work so am not sure how to go from here. I found OASIS documentation that lines up with the ESM config but I’m not sure what the OM2 namcouple parameters mean (why it doesn’t need grids/has NAs) or where their docs are. (@dkhutch and @aekiss you might know?)

62

My limited understanding is that libaccessom2/yatm figures out some defaults/values which are manually configured in esm1.5. Although this is all a bit obaque.

I guess the two NA from your quote (which should be prefix of the source/target grid name in grid data files) are actually set in the forcing.json file instead of NAMCOUPLE. Similarly, I think if fields need to be offset in time forwards or backwards, forcing.json should be used - see Tutorials ¡ COSIMA/access-om2 Wiki ¡ GitHub

e.g. in the libaccessom2 readme:

To further simplify things YATM gathers a lot of it’s configuration automatically from the forcing dataset metadata. For example the calendar type and timestep information.

In the normal access-om2 case, jra55do is used as the atmosphere forcing. JRA55do is 3 hourly for atmosphere, and the fluxes are 3 hourly averages and the other fields (temperature, slp, wind, humidity) are instantaneous. The averages have timestamps in the middle of the time interval, and the other fields have timestamps at the time of the measurement. With the esm1.5 forcing, is the forcing data 3-hourly averages for all the fields and fluxes? Is the timestamp at the end of the averaging interval? Checking those details might help figure out what/when an offset is needed?

1 Like
63

Thanks for pointing out the perturbation tutorial @anton. I think that could be super useful later on to. I am not sure if the fields can be offset in time in forcing.json though? From the tutorial is looks like the offset is for constant changes, or those in space and time. It’s not obvious to me how to do a f_applied(t) = f_JRA(t-1) with this?

          "type": "offset",
          "dimension": "constant",
          "value": 5,
          "calendar": "forcing",
          "comment": "Add 5 Wm^2 to SW everywhere at all times"
        },

I will see if I can just change the forcing times to get the lag I want though, we’ll see if it breaks. Thank you!

64

Thanks @Anton, for replying I was going to suggest @aekiss for YATM set up. The input files you are quoting I am for the ESM fluxes are from the payu set up, and I have only run what we call here at CSIRO the “old scripts” where the fields where input was organised differently but they look sensible. @spencerwong is the person to ask about the current set up.

In relation to ocean parameters, the key ones that could be affecting the tropical thermocline could be things like the KPP vertical set up, the neutral physics parameters and any settings on viscosity, which might effect the undercurrent speed, are the namelists you are using easily accessible.

1 Like
65

You’re right @ongqingyee - forcing perturbations specified in forcing.json don’t provide a way to shift the forcing in time.

2 Likes
66

You may find this useful GitHub - aekiss/nmltab: Python module and command-line tool to semantically tabulate, diff and superset Fortran namelist files.

2 Likes
67

This draft tech report for ACCESS-OM2 may also be useful (though in many places it is referring to old configs, circa 2020) https://cosima.org.au/wp-content/uploads/2025/10/ACCESS-OM2-1-025-010deg-2025-10-02-b2c815b.pdf

1 Like
68

Hi all, thanks again for the input on this so far. I have taken @sofarrell and @aekiss 's input especially and made many changes to the mixing in OM2 so that they are closer to ESM. Deviations between the two include the mixing scheme used (Bryan-Lewis ESM but not OM2), Langmuir mixing and more. Will push a new config to github soon. These unfortunately do not address the biases in the subsurface.

However, I found that the wind stresses are crazy different between ESM1.5 and OM2 forced with ESM1.5 atmospheric variables. The plot below shows the historical period, with 12-month rolling mean tau_x and tau_y averaged over the Eastern Pacific and Western Pacific regions, as defined by here. The tau_x plots in particular show huge differences, and it looks like there is an offset between ESM and OM surface stress. These were plotted by looking at the tau_x and tau_y diagnostics output from the runs, so they should be comparing like with like.

image
image669×473 86.6 KB

It could be that differences in surface ocean currents cause this discrepancy, but the zonal velocities in the same regions (see plot below) don’t show nearly as large a difference between ESM and OM (blue lines are EP for ESM and OM).

image
image602×200 42.4 KB

I’m not sure if there are any differences in how tau is computed in ESM1.5 and OM2. I am only aware of this line in CIC5 here, but can’t find where stair_xocn is explicitly calculated/where the drag coefficients for tau are defined in OM2 or ESM1.5 so a pointer in the right direction would be amazing. Tagging a few people who might know: @anton @spencerwong @dougiesquire

Thanks in advance!

69

The calculation of the stress for OM2 is in the cice5 driver code.

In ACCESS-ESM1.5, it looks like tau is a coupled field from the atmosphere into the ocean

Tau is calculated in the atmosphere model, and then remapped from the atmosphere grid onto the ocean grid. I’m hoping @spencerwong can dig up the code!

1 Like
70

Thank you! I tried to traceback to find the default drag coefficient values - it looks like cd_m is defined at some point before this, and roughness_mom is defined here in OM2. However the input_ice_gfdl.nml file doesn’t exist in the access-esm1.5 config files so I can’t find this code block at all.

&ocean_rough_nml
    charnock          = 0.032
    do_cap40          = .false.
    do_highwind       = .false.
    rough_scheme      = 'beljaars'
    roughness_heat    = 5.8e-05
    roughness_min     = 1e-06
    roughness_moist   = 5.8e-05
    roughness_mom     = 5.8e-05
    zcoh1             = 0.0
    zcoq1             = 0.0

Are these roughness values prescribed anywhere in the esm configs? I struggle with searching in github across different branches as it doesn’t show lines of code that are in the repo in some branches so I feel like I’ve missed something.

1 Like
71

The calculation method might be similar, but will be done in a totally different place and structured differently. It will be within the UM model code somewhere, and then the calculated stress term is a coupled field with the ocean. I am hoping @spencerwong will chip in when he has time to poke around and find it !

1 Like
72

Hi @ongqingyee I was wondering how you were going :slight_smile:

It looks like some of the files you are checking out in the GFDL MOM code on roughness and stresses may be from the ice part of their code so form their SIS2 model so not relevant to this calculation.

The relevant stress from the OM2 set up is the ones that Anton highlighted which look like

rho_drag = drag_m * rho
flux_u = rho_drag * u_dif

where u_dif= vel_scale * u_surf - u_atm so a relative velocity effect over the ocean that feeds into the stress calculation.

The ESM1.5 set up uses U-stress= um_taux * (1. - maice) - mstrocnxT * maice

where the latter terms are allowing an adjustment for stresses in the ice covered ocean but you are working in the tropics so you don’t need to worry about those terms. The um_taux is a more complicated stress term that comes from the UM boundary layer calculation, unless you really need to I wouldn’t advise you to look there its thousands of lines of code and subroutines, just take the stress terms the UM has calculated the atmospheric model has taken into account whether the grid point is over ocean, land, or an ice surface .

The issue I am seeing in your plots, is that in the y direction stress terms are relatively close, with minor offset we have a stretched grid in the y-direction on the equator which may be helping here to hide an offset. In the x-direction there is more sign of a grid offset occurring between the two set ups.

Have you checked the co-ordinates of your measurements that you plotted, you need to check for the U-grid not the T-grid and that they are matching as closely as you think and there is not an offset.

73

Thanks Siobhan!

I will check the grids again. There are however decent difference in wind stress that show up in the spatial plots regardless – these are taken over the 1980-2015 historical period.

Screenshot 2025-11-05 at 10.33.05 am
Screenshot 2025-11-05 at 10.33.05 am1070×758 369 KB

I asked @anton about the surface drag coefficient because the goal for my science question is to get a decoupled ocean model that matches ESM as close as possible - currently I’m not entirely comfortable with the differences. I can’t change ESM anymore, esp since there are 40 ensemble member I could compare my results to. Therefore, I would also like to check where drag_m is defined in OM2 so that this, if anything, could be tweaked to get to something that looks like ESM. Thus, understanding how ESM calculates its stress would be helpful in getting them as close as possible.

Tagging also @MartinDix , @cbull in case they have any opinions/insight?

( I might try is to override OM2 with the wind stress from ESM and see if that fixes the problem. It’s not trivial but I might have to do that to confirm that the wind stress is the primary cause of the discrepancies.)

74

Hi @ongqingyee drag_m is defined in the same cice5 driver code @anton highlighted earlier its a surface not bottom drag

drag_m = cd_m * w_atm

cd_m and w_atm are also defined in the same code.

One issues you have raised is that there are 40 ensemble members of ESM1.5 but you presumably are using the forcing from a single ensemble member that you are trying to reproduce with your forcing of the OM2 model. I didn’t see what terms you pulled from ESM1.5 archive you pulled into OM2 but I guess it was forcing fields similar to what JRA55 would use.

Because ESM1.5 has the UM boundary layer, and OM2 has its simpler boundary layer, then yes you are going to get subtle differences in the surface stress terms arising from taking this approach.
I was also a little puzzled in why the OM2 field has a title of “OM vert_tidal tauu_t “ do you have tides switched on in your OM2 run. I should go and check myself in standard output.

75

Thanks for the correction, yes surface is what i meant.

I see these lines but I don’t see a number where the parameters cd_m/rough_mom are prescribed? I was hoping to find where the parameter is prescribed either in the config or in the source code, so the exact dimensionless number.

I didn’t see what terms you pulled from ESM1.5 archive you pulled into OM2 but I guess it was forcing fields similar to what JRA55 would use.

Yes that is correct.

do you have tides switched on in your OM2 run.

No. It was from when I made changes to &ocean_vert_tidal_nml in input.nml, because they are different between ESM and the NRI OM2 config release.

76

Hi @ongqingyee rough_mom is defined in cice5/drivers/auscom/ocean_rough_mod.F90 but there are a few options which are controlled by switches so that may depend on what is on in OM2.

1 Like
77

Hi @ongqingyee I realise your namelist above in the black box is probably feeding into this ocean_rough_mod.F90 routine so in effect you have answered your own question on how to OM2 calculated the cd_m drag coefficient. It doesn’t answer whether it will adequately represent the UM stress terms to the accuracy you need in your off-line experiments though?

78

My understanding from what you said above is that those namelists don’t apply, but I did a run where I changed roughness_mom by +20% and got the almost same results in temperature in the tropics. There are some surface stress changes in the time-mean but I guess the most important next step is understanding how the UM calculates their surface stress. Apologies, I was confusing myself too.

79

I think the namelist you highlighted was ocean_rough_nml and the reason I thought it would be linked to this module and subroutines without lining them up is that it was called ocean_rough_mod.F90 the setting charnock, was noticeable as a setting. I knew Prof Charnock when I was doing “your age” doing a post doc he was wonderful to get advice from, he was an Emeritus professor by then.
As you say its possible your run may not be that sensitive to changes in the settings. I need to go back and look at your ppt slides, and work out the context you are doing these runs, we could perhaps chat off line.

1 Like
80

HI @ongqingyee Just gone back to one of your initial posts to see what data you are feeding in to the OM2 YATM, In relation to the missing river inputs It will be in the ocean output data but at monthly frequency, which may be all you really had from the JRA55 data, the solid runoff from Antarctic is also added to friver in this version of ESM1.5.
I see that you were advised to convert the 2m temperatures to 10m temperature in a similar way to what was done with the ERA5 data that they put through YATM, Though if you are expecting to get accurate matches with ESM1.5 latent and sensible fluxes like we are discussing below with the stresses, then it will not be perfect as the boundary layer formulations in YATM and in the UM are different.