Fields with arbitrary dimensions

[albert-de-montserrat]

Is it possible to make Fields with arbitrary dimensions? let's say for example that I have a n X n grid object but I also need a n-2 X n-2 array.

[luraess]

Right now, we only allow to construct fields on either center() or vertex() locations, or any combinations of those as these should cover most of the use cases we encounter(ed) for FD computations on staggered grids. On a n X n grid, an array of size n-2 X n-2 would be located on cell center. The "inner points" (skipping the entries at/close to the boundaries) use case may arise depending on the strategy that is chosen to apply boundary conditions. In Chmy, fields have halo (memory being reserved to account for 2 cells in each dimension) in order to handle boundary conditions, if needed. The result is that there shouldn't be the need for arrays of "inner points only". (There is the halo kwarg you may set to 0 if you are sure that the field you need won't need it).

If you have a clear use case in mind, we may have a look.

[utkinis]

@albert-de-montserrat The underlying reason for not allowing totally arbitrary underlying array sizes is the need for consistent finite differences. In Chmy, there is a convention that every axis has N cell centres and N+1 vertices. This way, computing the derivatives becomes an easy task as we need to dispatch only on the type of the source and the destination field. For example, if we take the x-derivative of Vx field, it will be Vx[ix+1, iy] - Vx[ix, iy], and if we compute Darcy flux, it will be Pf[ix, iy] - Pf[ix-1, iy]. If we allow different configurations, we need to also dispatch on the meta information of whether the corner vertices are included or not, i.e., if the field is N+1 or N-1, or N or N-2 etc.

The added value of having all this variability is IMO very marginal, and the code needed to maintain this will be complex. Thus, the convention is:

1. All fields have the halo of size O, where O is the order of the scheme. By default O is 1, and is defined per-field basis. In the future, I'd make it rather the property of the grid only.
2. Vertex axis include the corner points, making the number of points to be N+1.

This means that actual size of underlying usable data is N+2 for cell centres and N+3 for vertices by default. There is also additional padding memory to fuse field accesses without having to do bounds checking, but the user shouldn't use this explicitly.

Hope this helps, and I'm open to discussions on how to make Chmy better =)

[albert-de-montserrat]

Thanks for all the info :)

[luraess]

I am closing this for now, but feel free to open a specific issue or submit a PR for additional functionality!