ghost zones and non-periodic boundary conditions
Hi all, I have a question which is kind of a yt question and kind of an enzo question, so first off, my apologies to the non-enzo users. I have something that quite clearly appears to be a boundary value problem on a non-periodic boundary condition. My first method of attack is to load the (single) root grid data object with its ghost zones: pf = load(data) gz = pf.h.grids[0].retrieve_ghost_zones(2,'y-velocity') However, when I do this on a sample I believe not to have the bug, it appears that yt is loading periodic boundary conditions in the non-periodic direction: the first ghost zone on the lower y boundary is exactly equal to the second-to-top active zone, and the second lower y ghost zone exactly equals the top active zone. More concretely, gz['y-velocity'][:,0,2] always equals gz['y-velocity'][:,-4,2] and gz['y-velocity'][:,1,2] always equals gz['y-velocity'][:,-3,2] This is very clear in the (2D) case at hand, since the velocity field is a large gradient in the y-direction. Is it possible that enzo is not outputting its ghost zones, and yt is simply filling using a periodic method? Or does enzo always output ghost zones, and this is simply a manifestation of my bug? I realize this is not a very clear question, but I'm a bit confused myself. thanks, j
Hi Jeff, I'm not exactly sure what kind of assumptions the retrieve_ghost_zones() routine makes about the boundary conditions, but I can answer your Enzo question. Enzo never outputs the ghost zones, and they are always recreated when restarting a simulation. By your description, it looks like yt is assuming periodic boundary conditions and filling the ghost zones. I tried to look in the source, but I couldn't find where periodicity is used in the covering_grid, and whether that can be changed to something else. John On 10/23/2010 02:50 AM, j s oishi wrote:
Hi all,
I have a question which is kind of a yt question and kind of an enzo question, so first off, my apologies to the non-enzo users. I have something that quite clearly appears to be a boundary value problem on a non-periodic boundary condition. My first method of attack is to load the (single) root grid data object with its ghost zones:
pf = load(data) gz = pf.h.grids[0].retrieve_ghost_zones(2,'y-velocity')
However, when I do this on a sample I believe not to have the bug, it appears that yt is loading periodic boundary conditions in the non-periodic direction: the first ghost zone on the lower y boundary is exactly equal to the second-to-top active zone, and the second lower y ghost zone exactly equals the top active zone. More concretely,
gz['y-velocity'][:,0,2] always equals gz['y-velocity'][:,-4,2]
and
gz['y-velocity'][:,1,2] always equals gz['y-velocity'][:,-3,2]
This is very clear in the (2D) case at hand, since the velocity field is a large gradient in the y-direction.
Is it possible that enzo is not outputting its ghost zones, and yt is simply filling using a periodic method? Or does enzo always output ghost zones, and this is simply a manifestation of my bug?
I realize this is not a very clear question, but I'm a bit confused myself.
thanks,
j _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
Hi John, Actually, some users have modified Enzo to output ghost zones (e.g., Dave), but it's certainly not the norm. --Rick On Oct 23, 2010, at 9:12 AM, John Wise <jwise@astro.princeton.edu> wrote:
Hi Jeff,
I'm not exactly sure what kind of assumptions the retrieve_ghost_zones() routine makes about the boundary conditions, but I can answer your Enzo question. Enzo never outputs the ghost zones, and they are always recreated when restarting a simulation. By your description, it looks like yt is assuming periodic boundary conditions and filling the ghost zones. I tried to look in the source, but I couldn't find where periodicity is used in the covering_grid, and whether that can be changed to something else.
John
On 10/23/2010 02:50 AM, j s oishi wrote:
Hi all,
I have a question which is kind of a yt question and kind of an enzo question, so first off, my apologies to the non-enzo users. I have something that quite clearly appears to be a boundary value problem on a non-periodic boundary condition. My first method of attack is to load the (single) root grid data object with its ghost zones:
pf = load(data) gz = pf.h.grids[0].retrieve_ghost_zones(2,'y-velocity')
However, when I do this on a sample I believe not to have the bug, it appears that yt is loading periodic boundary conditions in the non-periodic direction: the first ghost zone on the lower y boundary is exactly equal to the second-to-top active zone, and the second lower y ghost zone exactly equals the top active zone. More concretely,
gz['y-velocity'][:,0,2] always equals gz['y-velocity'][:,-4,2]
and
gz['y-velocity'][:,1,2] always equals gz['y-velocity'][:,-3,2]
This is very clear in the (2D) case at hand, since the velocity field is a large gradient in the y-direction.
Is it possible that enzo is not outputting its ghost zones, and yt is simply filling using a periodic method? Or does enzo always output ghost zones, and this is simply a manifestation of my bug?
I realize this is not a very clear question, but I'm a bit confused myself.
thanks,
j _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
Hi Jeff, yt assumed periodicity, simply because that covered the vast majority of the situations that the ghost zones were used in -- it only becomes an issue in the grids that touch the domain edges. You can see this in yt/utilities/data_point_utilities.c around line 1014 where it takes the modulo of the integer location with dw[]. This is something of obtuse code, but I'd be happy to help modify it to meet your needs. Rick -- I think it would be very valuable if you could assist Dave in making this option available in the main Enzo branch. At that point, a simple subclass of the IOHandler would handle obtaining the ghost zones; this would also speed up volume rendering substantially. -Matt On Sat, Oct 23, 2010 at 9:26 AM, Rick Wagner <rwagner@physics.ucsd.edu> wrote:
Hi John,
Actually, some users have modified Enzo to output ghost zones (e.g., Dave), but it's certainly not the norm.
--Rick
On Oct 23, 2010, at 9:12 AM, John Wise <jwise@astro.princeton.edu> wrote:
Hi Jeff,
I'm not exactly sure what kind of assumptions the retrieve_ghost_zones() routine makes about the boundary conditions, but I can answer your Enzo question. Enzo never outputs the ghost zones, and they are always recreated when restarting a simulation. By your description, it looks like yt is assuming periodic boundary conditions and filling the ghost zones. I tried to look in the source, but I couldn't find where periodicity is used in the covering_grid, and whether that can be changed to something else.
John
On 10/23/2010 02:50 AM, j s oishi wrote:
Hi all,
I have a question which is kind of a yt question and kind of an enzo question, so first off, my apologies to the non-enzo users. I have something that quite clearly appears to be a boundary value problem on a non-periodic boundary condition. My first method of attack is to load the (single) root grid data object with its ghost zones:
pf = load(data) gz = pf.h.grids[0].retrieve_ghost_zones(2,'y-velocity')
However, when I do this on a sample I believe not to have the bug, it appears that yt is loading periodic boundary conditions in the non-periodic direction: the first ghost zone on the lower y boundary is exactly equal to the second-to-top active zone, and the second lower y ghost zone exactly equals the top active zone. More concretely,
gz['y-velocity'][:,0,2] always equals gz['y-velocity'][:,-4,2]
and
gz['y-velocity'][:,1,2] always equals gz['y-velocity'][:,-3,2]
This is very clear in the (2D) case at hand, since the velocity field is a large gradient in the y-direction.
Is it possible that enzo is not outputting its ghost zones, and yt is simply filling using a periodic method? Or does enzo always output ghost zones, and this is simply a manifestation of my bug?
I realize this is not a very clear question, but I'm a bit confused myself.
thanks,
j _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
Hi everyone, Thanks! I'm not sure it's really worth it to modify yt in this way until I can figure out how to get enzo to dump ghost zones, and I'm not sure that's necessary either if I can figure out my bug. I appreciate all your help. j On Sat, Oct 23, 2010 at 10:33 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi Jeff,
yt assumed periodicity, simply because that covered the vast majority of the situations that the ghost zones were used in -- it only becomes an issue in the grids that touch the domain edges. You can see this in yt/utilities/data_point_utilities.c around line 1014 where it takes the modulo of the integer location with dw[]. This is something of obtuse code, but I'd be happy to help modify it to meet your needs.
Rick -- I think it would be very valuable if you could assist Dave in making this option available in the main Enzo branch. At that point, a simple subclass of the IOHandler would handle obtaining the ghost zones; this would also speed up volume rendering substantially.
-Matt
On Sat, Oct 23, 2010 at 9:26 AM, Rick Wagner <rwagner@physics.ucsd.edu> wrote:
Hi John,
Actually, some users have modified Enzo to output ghost zones (e.g., Dave), but it's certainly not the norm.
--Rick
On Oct 23, 2010, at 9:12 AM, John Wise <jwise@astro.princeton.edu> wrote:
Hi Jeff,
I'm not exactly sure what kind of assumptions the retrieve_ghost_zones() routine makes about the boundary conditions, but I can answer your Enzo question. Enzo never outputs the ghost zones, and they are always recreated when restarting a simulation. By your description, it looks like yt is assuming periodic boundary conditions and filling the ghost zones. I tried to look in the source, but I couldn't find where periodicity is used in the covering_grid, and whether that can be changed to something else.
John
On 10/23/2010 02:50 AM, j s oishi wrote:
Hi all,
I have a question which is kind of a yt question and kind of an enzo question, so first off, my apologies to the non-enzo users. I have something that quite clearly appears to be a boundary value problem on a non-periodic boundary condition. My first method of attack is to load the (single) root grid data object with its ghost zones:
pf = load(data) gz = pf.h.grids[0].retrieve_ghost_zones(2,'y-velocity')
However, when I do this on a sample I believe not to have the bug, it appears that yt is loading periodic boundary conditions in the non-periodic direction: the first ghost zone on the lower y boundary is exactly equal to the second-to-top active zone, and the second lower y ghost zone exactly equals the top active zone. More concretely,
gz['y-velocity'][:,0,2] always equals gz['y-velocity'][:,-4,2]
and
gz['y-velocity'][:,1,2] always equals gz['y-velocity'][:,-3,2]
This is very clear in the (2D) case at hand, since the velocity field is a large gradient in the y-direction.
Is it possible that enzo is not outputting its ghost zones, and yt is simply filling using a periodic method? Or does enzo always output ghost zones, and this is simply a manifestation of my bug?
I realize this is not a very clear question, but I'm a bit confused myself.
thanks,
j _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
Rick is correct, I do have a version that outputs ghost zones. I can stick that in on Monday, if you think that would help. Does YT know how to read datasets with ghost zones? And will you need to be able to restart from datasets with the ghosts written? (not something I've implemented, but not hard to do) d. On Sat, Oct 23, 2010 at 11:07 AM, j s oishi <jsoishi@gmail.com> wrote:
Hi everyone,
Thanks! I'm not sure it's really worth it to modify yt in this way until I can figure out how to get enzo to dump ghost zones, and I'm not sure that's necessary either if I can figure out my bug.
I appreciate all your help.
j
On Sat, Oct 23, 2010 at 10:33 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi Jeff,
yt assumed periodicity, simply because that covered the vast majority of the situations that the ghost zones were used in -- it only becomes an issue in the grids that touch the domain edges. You can see this in yt/utilities/data_point_utilities.c around line 1014 where it takes the modulo of the integer location with dw[]. This is something of obtuse code, but I'd be happy to help modify it to meet your needs.
Rick -- I think it would be very valuable if you could assist Dave in making this option available in the main Enzo branch. At that point, a simple subclass of the IOHandler would handle obtaining the ghost zones; this would also speed up volume rendering substantially.
-Matt
On Sat, Oct 23, 2010 at 9:26 AM, Rick Wagner <rwagner@physics.ucsd.edu> wrote:
Hi John,
Actually, some users have modified Enzo to output ghost zones (e.g., Dave), but it's certainly not the norm.
--Rick
On Oct 23, 2010, at 9:12 AM, John Wise <jwise@astro.princeton.edu> wrote:
Hi Jeff,
I'm not exactly sure what kind of assumptions the retrieve_ghost_zones() routine makes about the boundary conditions, but I can answer your Enzo question. Enzo never outputs the ghost zones, and they are always recreated when restarting a simulation. By your description, it looks like yt is assuming periodic boundary conditions and filling the ghost zones. I tried to look in the source, but I couldn't find where periodicity is used in the covering_grid, and whether that can be changed to something else.
John
On 10/23/2010 02:50 AM, j s oishi wrote:
Hi all,
I have a question which is kind of a yt question and kind of an enzo question, so first off, my apologies to the non-enzo users. I have something that quite clearly appears to be a boundary value problem on a non-periodic boundary condition. My first method of attack is to load the (single) root grid data object with its ghost zones:
pf = load(data) gz = pf.h.grids[0].retrieve_ghost_zones(2,'y-velocity')
However, when I do this on a sample I believe not to have the bug, it appears that yt is loading periodic boundary conditions in the non-periodic direction: the first ghost zone on the lower y boundary is exactly equal to the second-to-top active zone, and the second lower y ghost zone exactly equals the top active zone. More concretely,
gz['y-velocity'][:,0,2] always equals gz['y-velocity'][:,-4,2]
and
gz['y-velocity'][:,1,2] always equals gz['y-velocity'][:,-3,2]
This is very clear in the (2D) case at hand, since the velocity field is a large gradient in the y-direction.
Is it possible that enzo is not outputting its ghost zones, and yt is simply filling using a periodic method? Or does enzo always output ghost zones, and this is simply a manifestation of my bug?
I realize this is not a very clear question, but I'm a bit confused myself.
thanks,
j _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
-- Sent from my Stone Tablet and carried by my Pterodactyl.
Hi Dave, After talking to Jeff a bit more offline, I think that this can be accomplished using the CopyOnlyActive variable in the New_Grid_WriteGrid.C routine. I believe that this will require a new parameter for the restarts, but that should not be too bad. I think on the whole it should be straightforward to use existing machinery for this. yt will support this with a subclass of the IO Handler; we can detect the state based on the parameter file (like is done for the packed versus unpacked), and simply strip the ghost zones in pop(). We'll then subclass EnzoGrid and only overload retrieve_ghost_zones. -Matt On Sat, Oct 23, 2010 at 3:13 PM, David Collins <dcollins@physics.ucsd.edu> wrote:
Rick is correct, I do have a version that outputs ghost zones. I can stick that in on Monday, if you think that would help. Does YT know how to read datasets with ghost zones? And will you need to be able to restart from datasets with the ghosts written? (not something I've implemented, but not hard to do)
d.
On Sat, Oct 23, 2010 at 11:07 AM, j s oishi <jsoishi@gmail.com> wrote:
Hi everyone,
Thanks! I'm not sure it's really worth it to modify yt in this way until I can figure out how to get enzo to dump ghost zones, and I'm not sure that's necessary either if I can figure out my bug.
I appreciate all your help.
j
On Sat, Oct 23, 2010 at 10:33 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi Jeff,
yt assumed periodicity, simply because that covered the vast majority of the situations that the ghost zones were used in -- it only becomes an issue in the grids that touch the domain edges. You can see this in yt/utilities/data_point_utilities.c around line 1014 where it takes the modulo of the integer location with dw[]. This is something of obtuse code, but I'd be happy to help modify it to meet your needs.
Rick -- I think it would be very valuable if you could assist Dave in making this option available in the main Enzo branch. At that point, a simple subclass of the IOHandler would handle obtaining the ghost zones; this would also speed up volume rendering substantially.
-Matt
On Sat, Oct 23, 2010 at 9:26 AM, Rick Wagner <rwagner@physics.ucsd.edu> wrote:
Hi John,
Actually, some users have modified Enzo to output ghost zones (e.g., Dave), but it's certainly not the norm.
--Rick
On Oct 23, 2010, at 9:12 AM, John Wise <jwise@astro.princeton.edu> wrote:
Hi Jeff,
I'm not exactly sure what kind of assumptions the retrieve_ghost_zones() routine makes about the boundary conditions, but I can answer your Enzo question. Enzo never outputs the ghost zones, and they are always recreated when restarting a simulation. By your description, it looks like yt is assuming periodic boundary conditions and filling the ghost zones. I tried to look in the source, but I couldn't find where periodicity is used in the covering_grid, and whether that can be changed to something else.
John
On 10/23/2010 02:50 AM, j s oishi wrote:
Hi all,
I have a question which is kind of a yt question and kind of an enzo question, so first off, my apologies to the non-enzo users. I have something that quite clearly appears to be a boundary value problem on a non-periodic boundary condition. My first method of attack is to load the (single) root grid data object with its ghost zones:
pf = load(data) gz = pf.h.grids[0].retrieve_ghost_zones(2,'y-velocity')
However, when I do this on a sample I believe not to have the bug, it appears that yt is loading periodic boundary conditions in the non-periodic direction: the first ghost zone on the lower y boundary is exactly equal to the second-to-top active zone, and the second lower y ghost zone exactly equals the top active zone. More concretely,
gz['y-velocity'][:,0,2] always equals gz['y-velocity'][:,-4,2]
and
gz['y-velocity'][:,1,2] always equals gz['y-velocity'][:,-3,2]
This is very clear in the (2D) case at hand, since the velocity field is a large gradient in the y-direction.
Is it possible that enzo is not outputting its ghost zones, and yt is simply filling using a periodic method? Or does enzo always output ghost zones, and this is simply a manifestation of my bug?
I realize this is not a very clear question, but I'm a bit confused myself.
thanks,
j _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
-- Sent from my Stone Tablet and carried by my Pterodactyl. _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
participants (5)
-
David Collins -
j s oishi -
John Wise -
Matthew Turk -
Rick Wagner