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