-
Notifications
You must be signed in to change notification settings - Fork 413
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
Inconsistent arguments for gradient and advection #896
Comments
Upon further reflection, I think the cleanest, most intuitive API for these functions would include the following constraints:
I think these constraints would provide the cleanest interface in a typical workflow where the user reads in some netCDF data, computes some of these diagnostics, and makes some plots. The user would not even need to worry about Given these criteria, the interface for |
Thank you for the thoughtful comments digging into this, it really helps laying it all out like that. Responses to the list:
From my perspective, the fundamental difference between I agree that the semantic differences between A lot of this will hopefully get simpler when we completely support xarray, so that dx, etc. arguments can go away. I am 100% in favor of making sure MetPy is consistent and as easy to use as possible. FYI, one work-around to the gradient confusion is to use |
I am confused by your reponse to point 3, since in my example the call to Regarding point 4, maybe |
Sorry, for (3), deltas are x-first, except for gradient and laplacian. Yes, xarray should make all of this moot in general, though I'd like things to function even if you're not using it. So we may want to make some changes in the future. Thanks for all of the thoughtful feedback! |
An added note that
just aren't intuitive. |
The following code:
accurately computes the temperature gradient and temperature advection corresponding to the sample data provided in 'yx' order.
However, notice that doing this calculation properly requires providing the deltas as
(dy, dx)
in thegradient
call, but(dx, dy)
in theadvection
call. I would have expected the order to be the same for both calls. In particular, since the data is in yx order, I would expect the correct call toadvection
would includedeltas=(dy, dx)
, but currently that is not the case.A second inconsistency involves the
dim_order
argument: Thegradient
function doesn't use it, but omitting it fromadvection
results in a stern warning from MetPy. I would expect:dim_order
is omitted in theadvection
call, and/orgradient
to allow for the dim_order to be specified as well, interpreted the same way as inadvection
.Version Info
Python 3.6.5
0.8.0+32.gb19c052
The text was updated successfully, but these errors were encountered: