Simplifying da.map_overlap's boundary padding

[jakirkham]

Currently da.map_overlap supports edge paddings of different kinds along different dimensions. This complicates things like using da.pad within da.map_overlap.

AFAIK there are no use cases for different edge paddings on different dimensions. The closest thing that I know of is to pad some dimensions and not others (i.e. having different depths per dimension), which can still be cast in terms of having the same padding for all dimensions (just some are trivial). Given this, I'd like to propose deprecating boundary arguments that are anything other than simple values (e.g. padding mode or constant for all dimensions).

[mrocklin]

One hypothetical case that comes to mind is solving PDEs, where having different boundary conditions on different edges is quite common. I know people that have tried using Dask for this, but given up due to poor performance. I don't have a good way to determine how important this feature is.

…

On Tue, Nov 27, 2018 at 2:36 PM jakirkham ***@***.***> wrote: Currently da.map_overlap supports edge paddings of different kinds along different dimensions. This complicates things like using da.pad within da.map_overlap <#3641>. AFAIK there are no use cases for different edge paddings on different dimensions. The closest thing that I know of is to pad some dimensions and not others (i.e. having different depths per dimension), which can still be cast in terms of having the same padding for all dimensions (just some are trivial). Given this, I'd like to propose deprecating boundary arguments <http://docs.dask.org/en/latest/array-overlap.html#dask.array.map_overlap> that are anything other than simple values (e.g. padding mode or constant for all dimensions). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#4252>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AASszNZ9w9hd5TyKpOxAkqGUSEGVDkTIks5uzZRAgaJpZM4Y2Mas> .

[jakirkham]

Good point. Though these would still be possible by applying da.pad repeatedly with the intended padding before calling da.map_overlap.

Should add that my general inclination is actually to push all users looking for explicit padding from Dask to use da.pad instead of relying on da.map_overlap to support this behavior directly. Often functions (at least in the image processing domain) do some implicit padding internally anyways.

[jakirkham]

Thoughts on handling this in 2.0?

xref: #4973

[mrocklin]

I think I prefer to have a convenience keyword argument in map_overlap. I'd be more than happy if that called pad. I don't care strongly about different edge paddings on different dimensions.

In terms of handling this before 2.0 I don't have strong thoughts. To me this doesn't seem to be a large priority to me personally (I haven't heard anyone complain) and so I don't think that it should block release.