Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Heat flux diagnostics incomplete / incorrect #139

Closed
aekiss opened this issue Mar 7, 2019 · 22 comments
Closed

Heat flux diagnostics incomplete / incorrect #139

aekiss opened this issue Mar 7, 2019 · 22 comments

Comments

@aekiss
Copy link
Contributor

aekiss commented Mar 7, 2019

@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
Copy link
Contributor Author

aekiss commented Mar 7, 2019

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.

@aekiss aekiss moved this from To Do to Do some other time in Creating an updated ACCESS-OM2-01 RYF Configuration Mar 7, 2019
@russfiedler
Copy link

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
Copy link
Contributor

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
Copy link

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
Copy link

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
Copy link

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

@adele-morrison
Copy link

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
Copy link

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
Copy link

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
Copy link
Contributor Author

aekiss commented Apr 10, 2019

linking a related issue: #142

@rmholmes
Copy link
Collaborator

I've added the vertically-integrated frazil_3d diagnostic here

@aekiss
Copy link
Contributor Author

aekiss commented Aug 6, 2019

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.

aekiss added a commit to COSIMA/01deg_jra55_iaf that referenced this issue Aug 6, 2019
aekiss added a commit to COSIMA/01deg_jra55_iaf that referenced this issue Aug 6, 2019
aekiss added a commit to COSIMA/025deg_core2_nyf that referenced this issue Aug 6, 2019
aekiss added a commit to COSIMA/025deg_jra55_iaf that referenced this issue Aug 6, 2019
aekiss added a commit to COSIMA/025deg_jra55_ryf that referenced this issue Aug 6, 2019
aekiss added a commit to COSIMA/1deg_core_nyf that referenced this issue Aug 6, 2019
aekiss added a commit to COSIMA/1deg_jra55_iaf that referenced this issue Aug 6, 2019
aekiss added a commit to COSIMA/1deg_jra55_ryf that referenced this issue Aug 6, 2019
aekiss added a commit to COSIMA/minimal_01deg_jra55_iaf that referenced this issue Aug 6, 2019
aekiss added a commit to COSIMA/minimal_01deg_jra55_iaf that referenced this issue Aug 6, 2019
aekiss added a commit to COSIMA/minimal_01deg_jra55_iaf that referenced this issue Aug 6, 2019
aekiss added a commit to COSIMA/minimal_01deg_jra55_ryf that referenced this issue Aug 6, 2019
aekiss added a commit to COSIMA/minimal_01deg_jra55_ryf that referenced this issue Aug 6, 2019
aekiss added a commit to COSIMA/minimal_01deg_jra55_ryf that referenced this issue Aug 6, 2019
@rmholmes
Copy link
Collaborator

rmholmes commented Jun 2, 2020

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. mom-ocean/MOM5#320

@aekiss
Copy link
Contributor Author

aekiss commented Jun 5, 2020

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

@rmholmes
Copy link
Collaborator

rmholmes commented Jun 5, 2020

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
Copy link

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
Copy link
Contributor Author

aekiss commented Jun 5, 2020

despite the name, frazil_3d_int_z is a 2d field

@russfiedler
Copy link

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

@abhisheksavita
Copy link

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
Copy link
Contributor Author

aekiss commented Jun 5, 2020

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

@access-hive-bot
Copy link

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

9 participants