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

Simplify Meridional Heat Transport notebook #450

Open
adele-morrison opened this issue Aug 30, 2024 · 15 comments
Open

Simplify Meridional Heat Transport notebook #450

adele-morrison opened this issue Aug 30, 2024 · 15 comments
Labels
❓ question Further information is requested 🛸 updating An existing notebook needs to be updated

Comments

@adele-morrison
Copy link
Collaborator

The Meridional_heat_transport.ipynb notebook currently calculates heat transport by 3 methods. Two of those methods are clearly incorrect, as shown in the figure from the notebook, copied here. The blue line is the correct method using the online heat transport diagnostic, and the orange and green are incorrect methods (that are wrong by a factor of ~2 in the Southern Hemisphere!):
download

I suggest we simplify this notebook and delete the incorrect methods 2 and 3, because we don't want to encourage people to compute incorrect metrics. We should encourage people to output the correct diagnostics, not try to hash together incorrect answers after the fact.

Am I missing something obvious about why we need these?

@navidcy navidcy added the ❓ question Further information is requested label Aug 30, 2024
@navidcy
Copy link
Collaborator

navidcy commented Aug 30, 2024

Good point!

If I recall correctly, there are some comments on the utility of each method sprinkled in the recipe. But your question above suggests that either these comments are a bit hidden or perhaps it worths reconsidering about the alternative methods and whether they overall help or confuse?

@dhruvbhagtani may be able to shed some insight?

@adele-morrison
Copy link
Collaborator Author

adele-morrison commented Aug 30, 2024 via email

@dhruvbhagtani
Copy link
Member

Maybe I'm missing something, but I do not completely agree with the other two methods being incorrect. Could you tell me -- Is it just this plot (I agree the orange and green line are far off from observations, but so is the blue), or is there a physical reasoning behind this inference?

The reason I ask is because according to me, all three methods are theoretically correct:
Method 1: Computes using an online diagnostic,
Method 2: Assuming steady state, MHT(y) = surface heat flux integral from y = y_min to y
Method 3: If the difference in temperature between northward and southward flow at a latitude is T and the flow volume is V, then. MHT(y) = \rho Cp multiplied by the zonal integral of VT.

Out of all the three methods, the first one is least prone to errors, since other methods have certain assumptions (steady state, or frequency of outputs of velocity and temperature). Maybe we can jumble the order of these methods to end with the best. Alternatively, we can suggest that methods 2 and 3 are great for when the online MHT diagnostic is not outputted, which is often the case?

@navidcy
Copy link
Collaborator

navidcy commented Aug 30, 2024

From the comment above, I think @adele-morrison is taking as the ground truth or what she refers as "correct" the methods where the heat transport you get from the online diagnostic.

She was not intending to compare them to observations (otherwise we go into discussions whether ocean models are correct etc...)

@navidcy
Copy link
Collaborator

navidcy commented Aug 30, 2024

Alternatively, we can suggest that methods 2 and 3 are great for when the online MHT diagnostic is not outputted, which is often the case?

I think this is the key point why we need the other methods.

Isn't it?

@adele-morrison
Copy link
Collaborator Author

adele-morrison commented Aug 30, 2024 via email

@dhruvbhagtani
Copy link
Member

Ah, I see the point now!

Alternatively, we can suggest that methods 2 and 3 are great for when the online MHT diagnostic is not outputted, which is often the case?

I think this is the key point why we need the other methods.

Isn't it?

Yep, they are less accurate than the first one, and are good alternatives when we don't have the diagnostic handy.

I don’t think they’re great. Method 2 could probably be made exact by including heat content change from restarts snapshots?

Yes, that'll be a great addition! I can try my hand at it (I've never dealt with analysing restart data but hopefully it's not too complicated) next week.

@adele-morrison
Copy link
Collaborator Author

adele-morrison commented Aug 30, 2024 via email

@navidcy
Copy link
Collaborator

navidcy commented Aug 30, 2024

(cc @rmholmes might be interested in this chat)

@dhruvbhagtani
Copy link
Member

Umm, it depends on what we want for others when they read this notebook, and that could be subjective. I see your reasoning to update method 2 and remove 3. In my opinion, missing out on high-frequency oscillations isn't a method problem. For example, if we had daily outputs, then I would expect the errors to go down (see Fig. 2 of Yung and Holmes 2023) that shows a large fraction of 10 day-2 month MHT that we are probably missing. Hence, it's still a useful method. We could maybe recompute using daily outputs to reduce errors.

Before we go down any of these routes we discussed (all of which will anyways improve this example in some respect), I think it's worthwhile to see Ryan's opinion as well, and we can make a decision.

@adele-morrison
Copy link
Collaborator Author

Yes, though even using daily output for method 3 misses a significant fraction of the heat transport across the Antarctic continental slope, where the overflows occur on sub-daily timescales in ACCESS-OM2-01.

@rmholmes
Copy link
Collaborator

rmholmes commented Sep 1, 2024

I would tend to agree with Adele. Method 1 is correct up to numerical precision (+ I think the effect of the SSH smoother, which is not really MHT and is small but would be needed to close the longitudinally-integrated heat budget). If you want to keep the other two I would suggest indicating everywhere in the notebook, including in the figure caption, that they are approximate.

One reason to retain method 2 as is (i.e. without accounting for tendency) is that this is how some of the observational estimates are made and so that comparison is more comparable. This is noted in the notebook, although it would be good to include more detail about which observational estimates use which methods.

Also note that:

  • It looks like Method 2 is missing the contribution of frazil formation. See Heat flux diagnostics incomplete / incorrect access-om2#139 (comment)
  • In addition to missing the contribution of high-frequency variability, Method 3 also neglects heat transport due to parameterized processes (e.g. the submesoscale scheme, as well as GM/Redi in the low-resolution configurations, which will be more of a problem).

@navidcy
Copy link
Collaborator

navidcy commented Sep 3, 2024

OK. From what I see then I think delete method 3 and add a clear(er) caveat for method 2 then. Perhaps don't even call it "method 2" but just "alternative approximate MHT calculation when X diagnostic is not available"?

How does this sound to all?

@adele-morrison
Copy link
Collaborator Author

Sounds good. Plus showing how to add heat content change from snapshots to method 2 to show that method 1 could be reconstructed exactly if that was the aim (in addition to without this to reproduce the obs method).

@navidcy
Copy link
Collaborator

navidcy commented Sep 3, 2024

That also sounds great. We can leave the issue open and see if anybody picks it up.

Even just deleting the Method 3 and adding a clearer caveat for Method 2 is a great contribution; what @adele-morrison suggests above it an even better enhancement but sounds more work.

@navidcy navidcy added the 🛸 updating An existing notebook needs to be updated label Sep 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
❓ question Further information is requested 🛸 updating An existing notebook needs to be updated
Projects
None yet
Development

No branches or pull requests

4 participants