-
Notifications
You must be signed in to change notification settings - Fork 11
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
Use horizontal averages to compute Richardson number profile #113
Conversation
Do we need to launch a 3D kernel for this? I think this is a 1D quantity, eg the ratio between the gradient of the horizontally-averaged buoyancy, and the horizontally averaged shear squared. The local, 3D Richardson number is also a useful quantity; it's just different from the horizontally-averaged Richardson number that often enters into our parameterizations. Both are useful. |
Hmmm, I guess it will launch a 3D kernel and repeat the same computation for each column. Is there an easy way to launch a 1D kernel? If not we could merge this PR since the output will now be closer to what is expected without introducing any slowdowns. We would save some computations by launching a 1D kernel but with 50+ diagnostics already being computed I suspect the effect of this one 3D kernel is not large.
True that both are useful, but sounds like you don't want to output spatial averages of the local Richardson number? 3D and slice outputs could output the (unaveraged) local Richard number while averages could output the "coarse-grained" Richardson number? |
I think for this to do the right thing we have to keep the background fields as is but set |
Oh nevermind, I see how it works in Oceanostics. This might work. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should add a comment so that users don't get confused --- this object computes an identical quantity at every i, j
, and then takes the horizontal average of that quantity. So there's a lot of wasteful computation but in the end it should return that quantity as a function of k
only.
It probably would be nice to raise an issue about this if we do merge it so that we don't forget that it's something we still have to fix. |
I opened a new issue to track this and added a comment to the script. |
Resolves #112