Behavior of data is inconsistent with behavior of Base.parent

[glwagner]

Julia's Base.parent(a) has the behavior that it returns either a.parent where applicable, or just a in the case that a is an unwrapped array.

Our data(f::Field) function has a different behavior: while f does have a field data, the function data(f) actually returns a view into data at interior grid points, rather than data itself.

It might be a good idea to make the behavior of data consistent with that of Base.parent. One way to do this is to change the definition of data to

data(f::Field) = f.data
data(f::AbstractArray) = f

To capture the existing functionality of data, we might define a new function (perhaps interiordata? that returns a view over 'interior' points:

interiordata(f::Field) = view(data(f), 1:f.grid.Nx, 1:f.grid.Ny, 1:f.grid.Nz)

The terminology is not perfect because of our convention for fields stored on faces (we store these fields asymmetrically: one boundary would be included in 'interior', but the other is not). However, this problem also plagues the current definition of data (and our notion of Field in general).

We can then also rename parentdata(f) to interiorparent(f), which returns a reference to the interior points of f.data.parent.

[ali-ramadhan]

Hmmm, yeah I agree it would be good to be consistent with Base.parent.

I guess these aren't user-facing functions so they don't super memorable names. I like defining data to be consistent with parent and defining other functions for views, e.g. interiordata is nice.

I don't know if it makes sense to define data(f::AbstractArray) = f though.

[glwagner]

data is very much a user facing function at the moment.

Note that parent(a::Array) = a.

[glwagner]

Just to be clear, the point of doing this is because you want to use dispatch to write flexible array operations that are agnostic to whether the array is a 'raw' array (like an Array or CuArray), or some kind of wrapper like an OffsetArray. By writing parent(a), you ensure correct behavior on a in both cases; you don't need to write new high-level functions for wrappers versus arrays because dispatch is performed at the lower level, where it belongs. With data we can use the same logic --- this concept is deployed extensively in PR #463.