There are a lot of different types of boundary conditions, and some codes take different actions depending on the variable, so it would be difficult to support everything.  I have the Maestro front-end reading in the boundary type, but I usually have to override it to periodic to get yt to work.  

One option is to provide just the minimum types of boundaries, a zero-gradient/Neumann/outflow, and a reflection (perhaps that does odd-reflection for vectors normal to the interface).  This should cover most of the standard use cases (maybe a survey of what types of boundaries people use would help?).  To close the remaining gap, there could be a standard function interface that a user or frontend writer could provide to handle "custom" BCs.

It would also be useful to know what routines need boundary conditions and how many ghost cells are needed.

On Wed, Jun 25, 2014 at 6:33 PM, Nathan Goldbaum <> wrote:
Maybe just fill the ghost zones with zeros?  If we're feeling really ambitious we could read in the boundary conditions for the simulation and do whatever is appropriate for those BCs.

On Wed, Jun 25, 2014 at 3:25 PM, Matthew Turk <> wrote:
Hi all,

What should we do (in general) about non-periodic datasets and getting
ghost zones for the domain edges?

This is the reason that the cookbook recipe fails -- it's trying to get
vorticity (needs GZs) for a non-periodic dataset.

Fixing the cookbook only requires swapping out the dataset, but I
thought we should probably open this discussion up a bit too.

yt-dev mailing list

yt-dev mailing list

Michael Zingale
Associate Professor

Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800
phone:  631-632-8225