issue_comments

The issue is that certain types of gridded data (such as output from numerical models) should actually not be integrated with the trapezoidal rule but rather should use the native finite volume discretization for their computational grid.

• We are aiming for the 20% of functionality that covers 80% of use cases, not the long tail.
• We don't want implementations of any complex numerical methods in xarray (like NumPy rather than SciPy).

I can see the problems down the road that @rabernat brings up. Say you have a high-order finite volume discretization and some numerical implementation of high-order integration for that gridding. What would your interface be? You could write it as new_integrate(da, dim, domain) but then it may be confusing to have da.integrate be different (and less accurate).

That might bring us back to the algorithmically descriptive name trapz, but then what about @shoyer's point that given a fixed gridding, da.integrate is the most readable choice of name? Perhaps allow generic extension of da.integrate by letting the method keyword of da.integrate accept a function as an argument that performs the actual integration?

An integrate method is probably better for the reason you describe---it's more obvious. I believe the name trapz came from Matlab originally.

With a general integrate, it's probably also useful to allow optional input arguments for lower_bound and upper_bound as a convenience for integrating over a subset of the data instead of the user doing that in a slice. If those arguments aren't given, they would default to all of the data.

I don't at the moment see a reason to use a different API than DataArray.mean or DataArray.sum. DataArrays assume a default spacing of 1 if coordinates are not given, which is exactly what np.trapz does. So the API for trapz might look like:

DataArray.trapz(dim=None, axis=None, skipna=None, keep_attrs=False, **kwargs)