Hi all,
Has anyone ever attempted to compute the heatbudget offline from T, u,v and w? Is there a standard approach to this in MOM when the individual heat budget terms haven’t been saved?
Specifically, I’m looking to compute the mixed layer heat budget (as is done in many marine heatwave studies). I’ve done this before but there is a fairly large residual.
Any advice gratefully received!
Do you mean just the advection terms? We’ve successfully reproduced those offline from 5-day average (or daily) outputs of T, u, v, w.
@ChrisC28 Did you get anywhere with this?
I haven’t done it. However, I am currently working on doing the mixed layer temperature budget properly using online binning of the MOM5 heat budget diagnostics into the mixed layer (code is working, I’m slowly writing it up…). For comparison purposes, I have code to do offline binning, but it still uses the MOM5 heat budget diagnostics. Given my results so far, I’m not surprised to hear that you get a large residual (whether this matters depends on your application).
Hi @adele-morrison and @rmholmes
Apologies for my slow response. Long story…
Essentially I’m trying to do a mixed layer heat budget from the BRAN2020.
I have u,v,T, w and mld at daily output intervals.
I’ve very, very carefully tried to calculated the advective terms following a finite-volume approach, but that’s no better than naively using xgcm, and my residual is of the same order of magnitude as the dTdt term.
@adele-morrison if you’ve done this offline before, any tips? Starting to pull out hair.
How are you computing surface fluxes, SW penetration, vertical mixing and entrainment? Depending on your application, these could be just as large or larger than advection and thus be causing you issues.
Thanks Ryan,
I should have been more clear in exactly what I’m trying to accomplish.
I’m trying to compute the mixed layer heat budget point-wise offline from daily average output.
The output I have is MLD, total surface heat flux, u,v,w, and T. BRAN2020 is based on MOM5 on a 0.1x0.1 degree B-grid that differs slightly from the ACCESS-OM-01 grid.
I’ve made two serious attempts, both of which don’t really come close to closing:
advective term: 1/(cell area) * [vT (northern edge) * dx(northern_dege) - vT (southern_edge) * dx(southern_edge) + uT(eastern edge) * dy(eastern_edge)-uT(western edge)*dy_(western edge) ]
The grid terms (area, dx, dy) I get from the grid-spec file.
I then mask all points below the mixed layer, and integrate vertically.
In the region I working in (the EAC) I expect the advective terms to dominate.
The first implementation is very noisy, but at least dT/dt and the advective term are of the same order of magnitude. The second approach, even though I’ve tried to be very careful, gives me results that are an order of magnitude greater than dT/dt, so clearly I’ve made an error.
Any advice on how you’ve computed the advective terms?
I’m not convinced by this. Here is an example for a single month in the North Atlantic from a precise (online) computation in ACCESS-OM2-025. Advection is not obviously dominant in the Gulf Stream. For a single day average advection may be more dominant, but I don’t think you can assume that apriori. [I can make this plot for the EAC from this run later this week, just in the middle of testing…]
@adele-morrison can probably help here more than me. In my ACCESS-OM2 work I use the model diagnostics. My only suggestion would be that, if you can, call the actual model routines in your analysis. I’ve done this for ROMS in the past (e.g. called the ROMS Fortran advection scripts from python using f2py, in which case the main errors you end up with reduce pretty much to missing time-correlations).
Sorry for the incredibly slow reply on this, but seems there’s still some interest (@sb4233 just poked me).
I dug up what I did on this 10 years ago. This is the depth-integrated meridional heat flux averaged over one year in CM2.6 (whose ocean component is fairly equivalent to ACCESS-OM2-01), comparing the online calculated heat flux (black) to my various attempts to compute it offline from 5 day averages of temp, vhrho_nt and dzt. The ‘mdppm’ one (cyan) is using the same algorithm as the MOM5 fortran code that I translated into python. So the difference there I think is just due to the fact the offline method is using 5 day averages and is missing higher frequency variability.
Happy to share code if you want, but it’s 10 year old code, so not pretty. 
Or I think @angus-g may have a wrapper to easily run bits of MOM code in python without having to rewrite it like I did.
That said, I was only ever trying to recreate fluxes, I’m guessing these errors could add up to something considerably larger when trying to close a budget.
I also recall not having much luck using u and v. Much better to use uhrho_et and vhrho_nt, which are on the mid-edges of the tracer cells rather than the corners.
Thanks for sharing @adele-morrison !
uhrho_et , vhrho_nt , and wrho_bt ?ppm_hlimiter you used in your code ?Okay let me put my use case here -
I’m working on performing a Reynolds decomposition of the advective tendency, aiming to isolate terms such as ū ∂T′/∂x, u′ ∂T̄/∂x etc where the overbar denotes the mean and the prime denotes the deviation from the mean.
In the model, advective tendencies are computed using the MD-PPM (multi-dimensional piecewise parabolic method), which reconstructs unique parabolic profiles within each grid cell. Because of this, applying standard finite difference schemes to compute gradients or tendencies leads to significant residuals when compared to the model’s online advection outputs.
Also, one important thing to note that the model computes the advective tendency in a conservative form which includes the mass continuity separated in each component.
I’d appreciate your insights on how best to approach this decomposition in a way that remains faithful to the model’s high-order advection scheme.