Non-periodic datasets and ghost zones
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 simple_slice_with_multiple_fields.py 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. -Matt
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 <matthewturk@gmail.com> 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 simple_slice_with_multiple_fields.py 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.
-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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 <nathan12343@gmail.com> 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 <matthewturk@gmail.com> 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 simple_slice_with_multiple_fields.py 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.
-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Michael Zingale Associate Professor Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
Is it clear why this issue cropped up in 3.0, but not in 2.x? I don't remember the vorticity_squared field being a problem in this cookbook recipe in the 2.x docs. What change broke this functionality? Cameron On Wed, Jun 25, 2014 at 3:49 PM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
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 <nathan12343@gmail.com> 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 <matthewturk@gmail.com> 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 simple_slice_with_multiple_fields.py 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.
-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org
On Thu, Jun 26, 2014 at 8:22 AM, Cameron Hummels <chummels@gmail.com> wrote:
Is it clear why this issue cropped up in 3.0, but not in 2.x? I don't remember the vorticity_squared field being a problem in this cookbook recipe in the 2.x docs. What change broke this functionality?
I'll reply to Mike's email later, but the issue here is that we now no longer assume periodicity. So if you ask for a region that extends off the edge of the domain, and your data is not periodict, it won't wrap around.
Cameron
On Wed, Jun 25, 2014 at 3:49 PM, Michael Zingale <michael.zingale@stonybrook.edu> wrote:
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 <nathan12343@gmail.com> 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 <matthewturk@gmail.com> 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 simple_slice_with_multiple_fields.py 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.
-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 phone: 631-632-8225 e-mail: Michael.Zingale@stonybrook.edu web: http://www.astro.sunysb.edu/mzingale
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
I gotcha. And even though the dataset used in the 2.x docs was non-periodic, yt assumed it was periodic and all the ghost-zones were defined. I see. To address this, I like the idea of either including an extra layer of ghost-zone cells around non-periodic datasets, so that fields like vorticity, shear, etc. *are* defined for these datasets, but at the very least, if we don't do this, could we have an error message describing that such a field is not defined for non-periodic datasets? On Thu, Jun 26, 2014 at 6:23 AM, Matthew Turk <matthewturk@gmail.com> wrote:
On Thu, Jun 26, 2014 at 8:22 AM, Cameron Hummels <chummels@gmail.com> wrote:
Is it clear why this issue cropped up in 3.0, but not in 2.x? I don't remember the vorticity_squared field being a problem in this cookbook recipe in the 2.x docs. What change broke this functionality?
I'll reply to Mike's email later, but the issue here is that we now no longer assume periodicity. So if you ask for a region that extends off the edge of the domain, and your data is not periodict, it won't wrap around.
Cameron
On Wed, Jun 25, 2014 at 3:49 PM, Michael Zingale <michael.zingale@stonybrook.edu> wrote:
There are a lot of different types of boundary conditions, and some
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
codes 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 <nathan12343@gmail.com
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 <matthewturk@gmail.com> 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 simple_slice_with_multiple_fields.py 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.
-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 phone: 631-632-8225 e-mail: Michael.Zingale@stonybrook.edu web: http://www.astro.sunysb.edu/mzingale
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org
participants (4)
-
Cameron Hummels
-
Matthew Turk
-
Michael Zingale
-
Nathan Goldbaum