search

COSIMA / access-om2

ACCESS-OM2 global ocean - sea ice coupled model configurations.
21 stars 23 forks source link

Heat flux diagnostics incomplete / incorrect #139

Closed aekiss closed 4 years ago

aekiss commented 5 years ago

@adele157's slack post:

Hi, coming back to the net_sfc_heating diagnostic problem for ACCESS that Ruth brought up earlier and that we mentioned briefly this morning. In summary of what I understand: To accurately calculate the net surface heating, you need 

sfc_hflux_coupler + sfc_hflux_pme + sfc_hflux_from_runoff

(these terms plus frazil_3d balances temp_tendency).

For MOM/SIS, the diagnostic 

net_sfc_heating = sfc_hflux_coupler + sfc_hflux_pme + sfc_hflux_from_runoff

but for ACCESS, there is an additional term associated with the mass flux of sea ice melt/formation (mh_flux) that is included in sfc_hflux_coupler, but not included in net_sfc_heating.

So I recommend that we make the following changes:

  1. Correct the code for the net_sfc_heating diagnostic for ACCESS, so that it includes the melt terms (I think we need to add wfimelt and wfiform to the precip/evap terms as a special case for ACCESS).
  2. Add a diagnostic for mh_flux, so that it is possible to output all of the separate heat flux terms (The surface heat budget then can be separated into (swflx + lw_heat + fprec_melt_heat + sens_heat + evap_heat + mh_flux + sfc_hflux_pme + sfc_hflux_from_runoff + frazil_3d)
  3. I'm not sure what the existing diagnostics for the ACCESS-OM2-01 run are, but if they are the same as Ruth's experiment, then we should replace frazil_2d with frazil_3d, and also output mh_flux.
aekiss commented 5 years ago

re. point 1, if we correct net_sfc_heating we should give it a different name (e.g. net_sfc_heating_access to avoid confusion with previous run output.

russfiedler commented 5 years ago

re. point 1, if we correct net_sfc_heating we should give it a different name (e.g. net_sfc_heating_access to avoid confusion with previous run output.

I'm not sure if I agree with doing it this way. The name of the diagnostic shouldn't be changed in the code just because a bug was found. I think we should calculate net_sfc_heating correctly but also have a version that calculates the term the old way and call it something like net_sfc_heating_access_legacy with it documented in the long_name attribute that mh_flux is missing. Users can change the names in the diag_table if they insist.

AndyHoggANU commented 5 years ago

Hi All, I think we agree that something needs to happen. I am always nervous when legacy code means "incorrect old way of doing things", but I see Russ' point. All of this is a by-product of moving to the access framework - maybe the way we should achieve this is by asking @nichannah to take a look when he has some spare COSIMA hours, and to. propose a way forward? Andy

StephenGriffies commented 5 years ago

For those interested in further details, I wrote notes in 2015 on the topic of heat budget diagnostics as part of a collaboration using ESM2M, which has many of the same elements as ACCESS (yet it uses SIS rather than CICE). I just uploaded these notes to the Github repo at

https://github.com/mom-ocean/mom-ocean.github.io/blob/master/assets/pdfs/ESM2M_heat_budget.pdf

I believe the issue with the non-closure in ACCESS relates to the ice model and its melt. As ESM2M uses the GFDL ice model SIS, the details for ESM2M might be distinct. Even so, the notes offer some insight for those interested in understanding how processes contribute to the heat budget of a grid cell.

adele-morrison commented 5 years ago

Regarding point 3 above, as Andy suggested elsewhere, it might be a bit much saving frazil_3d for ACCESS-OM2-01, so perhaps it would be worth making another new 2d diagnostic, which is the vertical sum of frazil_3d, so that we can still separate out the components of the total surface heat flux. (Note that the current frazil_2d that we are saving is only the surface layer of frazil_3d.)

StephenGriffies commented 5 years ago

Will the diagnostic heat budget close with frazil_3d, or depth summed frazil_2d?

adele-morrison commented 5 years ago

Steve, for an interior grid cell, you need frazil_3d to close the heat budget. However, for ACCESS-OM2-01, we are not saving all of the heat budget terms, so could only hope to close the vertically integrated heat budget, for which the depth summed frazil_3d would be sufficient.

StephenGriffies commented 5 years ago

Yes, I see your point.

It would be useful to run one year with all the right terms at each grid cell are fine, to confirm that all is OK...

fabiobdias commented 5 years ago

Just to add a comment here... the issue with a previously non-closure of the heat budget in ACCESS-OM was related with an inconsistency in the rho_cp parameter between the ocean and sea-ice components (fixed in auscom_ice.f90, July 2017). I can certify that the heat budget is closed in recent ACCESS-OM2 1-degree simulations.

aekiss commented 5 years ago

linking a related issue: https://github.com/OceansAus/access-om2/issues/142

rmholmes commented 5 years ago

I've added the vertically-integrated frazil_3d diagnostic here

aekiss commented 5 years ago

total_net_sfc_heating is calculated the same (incorrect) way as net_sfc_heating. So until we fix this I'll remove both of these from diag_table in the access-om2 control directory repos.

rmholmes commented 4 years ago

I've added an issue and PR on the MOM5 code repository that addresses this issue. Basically I have corrected the net_sfc_heating bug (without retaining a legacy version for now) and added an mh_flux diagnostic. Any comments/further suggestions there would be appreciated. https://github.com/mom-ocean/MOM5/pull/320

aekiss commented 4 years ago

Many thanks @rmholmes - I've merged your PR, so is this issue ok to close now?

rmholmes commented 4 years ago

Yes I think so.

Just for future reference if people are looking at this issue again. The total heat flux into the ocean from surface forcing and ice-ocean exchanges is:

net_sfc_heating + frazil_3d_int_z

where,

net_sfc_heating = sfc_hflux_coupler + sfc_hflux_pme + sfc_hflux_from_runoff + sfc_hflux_from_calving

sfc_hflux_coupler = swflx + lw_heat + fprec_melt_heat + calving_melt_heat + sens_heat + evap_heat + mh_flux + liceht

Note the calving terms and liceht are currently zero in ACCESS-OM.

abhisheksavita commented 4 years ago

Thanks @rmholmes for making this note. Just checking with you that frazil_3d_int_z is a depth integrated. Can we use frazil_2d in place of frail_3d_int_z as others fluxes are just 2D.

aekiss commented 4 years ago

despite the name, frazil_3d_int_z is a 2d field

russfiedler commented 4 years ago

This distinguishes it from frazil_2d which is the frazil contribution in the top layer only.

abhisheksavita commented 4 years ago

Thanks @aekiss and @russfiedler that's reason I am just wondering that we need to include depth integrated flux or just flux at surface due to frazil to calculate total flux into the ocean.

aekiss commented 4 years ago

Frazil can form at deeper depths than just the surface, so we need frazil_3d_int_z

access-hive-bot commented 1 year ago

This issue has been mentioned on ACCESS Hive Community Forum. There might be relevant details there:

https://forum.access-hive.org.au/t/non-closure-of-heat-budget-in-access-cm2-esmf-cmip-output/244/10

access-hive-bot commented 5 months ago

This issue has been mentioned on ACCESS Hive Community Forum. There might be relevant details there:

https://forum.access-hive.org.au/t/net-surface-heat-and-freshwater-flux-variables/993/6