Non-closure of heat budget in ACCESS-CM2 ESMF/CMIP output

Earth System
1

Hi everyone,

Now that this forum exists, I was hoping I could flag an issue that was uncovered a couple years ago but was languishing in my to-do list regarding the ACCESS-CM2 runs.

It looks like the time-integrated heat flux into the ocean (‘hfds’ variable) does not equal the time-integrated ocean heat content (calculated using the ‘thetao’ variable), in both the historical and piControl runs. I should note that this is NOT an issue in the raw outputs, just in the published CMIP data. Here’s the mismatch in the historical runs:

hfds_nonclosure

In the piControl runs, @rmholmes found that the non-closure is because some terms are neglected in the ‘hfds’ calculation:

access_heat_budget_closure
access_heat_budget_closure2400×1500 190 KB

where

cube_dict['ryan-hfds'] = cube_dict['sfc-hflux-from-runoff'] + \
                         cube_dict['sfc-hflux-coupler'] + \
                         cube_dict['sfc-hflux-pme'] + \
                         cube_dict['frazil-3d']
cube_dict['abhi-hfds'] = cube_dict['sfc-hflux-from-runoff'] + \
                         cube_dict['sfc-hflux-coupler'] + \
                         cube_dict['sfc-hflux-from-water-evap'] + \
                         cube_dict['sfc-hflux-from-water-prec'] + \
                         cube_dict['frazil-2d']

It would be great if this issue could be identified and resolved – closure of the heat budget is necessary for any model validation use-cases!

1 Like
2

Thanks @taimoorsohail.

Just to clarify for others - the problem is with the pre-processing that computes the ESMF/CMIP output variable hfds from the raw MOM5 output diagnostics. The old calculation (“abhi-hfds” above) did not include frazil formation below the surface layer (frazil-2d vs. frazil-3d) or some components of the heat flux associated with surface volume fluxes (a few terms to do with ice-ocean fluxes). The “ryan-hfds” calculation above correctly includes all of these terms.

Technical note: To close the heat budget exactly you should technically also be comparing the time integral of area-integrated hfds to snapshots of the global OHC, not time-averages of OHC. This point is minor compared to the difference that Taimoor is showing above in the first plot, as shown by the second plot.

1 Like
3

@MartinDix I assumed the “pre-processing” referred here was Chloe’s ACCESS-Archiver, but I can’t find any mention of it in the gitlab repo. Where is this calculation done? It seems like a bug which should be fixed.

4

This is actually quite easy to fix, as the calculation is defined in a mapping file.

hfds,yes,sfc_hflux_from_runoff sfc_hflux_coupler sfc_hflux_from_water_evap sfc_hflux_from_water_prec frazil_2d,var[0]+var[1]+var[2]+var[3]+var[4],W m-2,both,ocean

just need to update this line, I’ve asked @sam.green to do it and do a pull_request.

hfds,yes,sfc_hflux_from_runoff sfc_hflux_coupler sfc_hflux_from_water_evap sfc_hflux_from_water_prec frazil_2d,var[0]+var[1]+var[2]+var[3],W m-2,both,ocean

5

Awesome!

To be clear, it is this line in APP4?

Also the tool would need to be re-run for this field and the ESGF data updated. @chloemackallah is this still your area of responsibility, or does this need to be directed to someone else?

6

That’s a line in a configuration file of the APP4.

7

Hi @Paola-CMS thank you for working on this issue! Just to clarify, I think the variable that should be used is frazil-3d not frazil-2d as the -3d file includes subsurface frazil formation.

1 Like
8

Note that frazil_3d is a 3d variable and has to be summed in the vertical. Note also the change from sfc-hflux-from-water-evap+sfc-hflux-from-prec to sfc-hflux-pme

2 Likes
9

I spotted the different variables, about the 3d-frazil we might need to add the calculation as a pre-defined function, but again, it shouldn’t be complicated

1 Like
10

Note that if the same fix is done for the ACCESS-OM2 OMIP-2 runs, there is an extra diagnostic available in the raw output, frazil_3d_int_z, that is frazil_3d already summed in the vertical.

For ACCESS-OM2, I’m also just referencing this issue on how to close the heat budget with surface fluxes: Heat flux diagnostics incomplete / incorrect · Issue #139 · COSIMA/access-om2 · GitHub

11

Just adding one more bit of relevant information here: @DamienIrving wrote a J Climate paper on this issue, among others, with the ACCESS-CM2 PI control being a focus of the paper. This was added in the conclusion section:

“The second category has nothing to do with deficiencies of the model itself and instead relates to potential issues with the data that are archived and made available to the research community. For example, in discussions about ocean heat budget closure with people familiar with the ACCESS-CM2 model (R. Holmes 2020, personal communication), it was discovered that the discrepancy between the OHC temperature component anomaly (Fig. 1a, red curve) and time integrated ocean surface heat flux (Fig. 1a, orange curve) could be explained by a minor mistake in the construction of the ocean surface heat flux CMIP diagnostic (hfds; Table 2). In particular, the hfds diagnostic was missing contributions from the heat flux into the ocean associated with sea ice–ocean volume exchanges and frozen precipitation as well as the effects of frazil ice formation below the surface layer of the model. When these terms are correctly included in hfds, there is closure between the OHC temperature component and time integrated ocean surface heat flux. Given the high level of model-specific knowledge (and access to data) required to precisely diagnose the cause of an apparent energy leak like this, a detailed examination of the underlying causes of nonconservation across the CMIP6 ensemble would be a difficult undertaking (and is beyond the scope of this study). A detailed assessment of energy and mass conservation is therefore best undertaken by the relevant modeling groups.”

2 Likes