How to deal with cell-centered and face-centered fields in NetCDF output?

[ali-ramadhan]

All the arrays right now are of size Nx*Ny*Nz but technically there are Nx volumes in the x-direction and Nx+1 faces so the output should match this and make sense. The easiest thing to do with the doubly periodic configuration we have right now is to have row Nx+1 be a repeat of row 1 but writing out the fields at the very bottom (k=Nz+1) might require some extra computation?

[glwagner]

If we are committed to not using ghost cells, then I think the solution will depend on how boundary conditions are implemented. Periodic boundaries are just one of many possible cases we will encounter.

[ali-ramadhan]

Yeah the output writing might get complicated as it could depend on the grid and boundary conditions and #86.

Will also be more complicated when data is spread across multiple cores or GPUs.

[glwagner]

This may be another reason why ghost cells are preferred. A “boundary condition” can then be thought of as a function that fills in missing values on the edges of a field. Currently a “boundary condition” is something that modifies the right hand side of an equation... ?

[ali-ramadhan]

Should we open a new issue to discuss whether or not to use ghost cells? Might be a hot topic and is only a backend issue so it isn't related to #86 either I think.

[jm-c]

I would suggest (if it works with out guys) a short meeting (< 30mn) to refine what we mean by and what we want regarding Bondary-Conditions (including ghost-cell). My view: it could help identify and formulate the right/relevant issues. Today 2.pm ? 3pm ? 4pm?

…

On Thu, Feb 28, 2019 at 02:54:59PM +0000, Ali Ramadhan wrote: Should we open a new issue to discuss whether or not to use ghost cells? Might be a hot topic and is only a backend issue so it isn't related to #86 either I think. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/ali-ramadhan/Oceananigans.jl/issues/92#issuecomment-468302424

[ali-ramadhan]

@jm-c @glwagner I can do 3pm later today.

Scheduling meetings in GitHub issues is awesome!

[glwagner]

3p works for me too.

[glwagner]

Let it be recorded: we discussed ghost cells and decided not to use them.

The main reason for not using ghost cells is that it is not clear whether an algorithm based on ghost cells can be used for irregular boundaries, where a cell point within land may be shared between 2 or more adjacent fluid cells.

We will need to figure out how to include the correct values of FaceFields on the boundary in output, for arbitrary boundary conditions. Perhaps we can implement some kind of pseudo-ghost cell functionality that only affects the calculation of output. Something to stew over.

[ali-ramadhan]

Just noting that whether we should save boundary values (i.e. halo data) to disk is an open issue #92.

The user can choose how to save their data in general, so the point holds regardless of how the 'default' output writer is designed.

Originally posted by @glwagner in #100 (comment)

Good point. A default where halo data is omitted makes the most sense to me, but we can just have a save_boundary_data flag that saves the full offset array to disk in case anyone wants it.

[glwagner]

Just wait until you start trying to calculate fluxes and gradients in post-processing... 😏

[ali-ramadhan]

Ah, fair enough. I still think it would be confusing for most users to have the boundary values in the output by default but a save_boundary_data flag sounds like an important feature now (not just for NetCDF).

[ali-ramadhan]

This has been recently resolved in PR #644.