Hi, I have a smoothed covering grid object: In [2]: print scg AMRSmoothedCoveringGrid (GR_Enzo2_128amr5_zeus_turb_psupp_rr_0001): level=3, left_edge=[ 0. 31. 0.], right_edge=[ 64. 33. 64.], ActiveDimensions=[2048 64 2048] which should have dims [2048, 64, 2048] as it claims above. Yet: In [5]: print scg["Density"].shape (256, 8, 256) Any idea why it's downsized? Oddly, this code (that creates the above) worked fine on a different machine but unfortunately, I inadvertently trashed it's OS earlier in the week. Both systems (i.e. this system that did the above and the one that is now a deadman) are linux. Any ideas? Elizabeth
Hi Elizabeth, What is the shape of the Ones field? Matt On Jun 1, 2012 10:26 AM, "Elizabeth Tasker" <tasker@astro1.sci.hokudai.ac.jp> wrote:
Hi,
I have a smoothed covering grid object:
In [2]: print scg AMRSmoothedCoveringGrid (GR_Enzo2_128amr5_zeus_turb_psupp_rr_0001): level=3, left_edge=[ 0. 31. 0.], right_edge=[ 64. 33. 64.], ActiveDimensions=[2048 64 2048]
which should have dims [2048, 64, 2048] as it claims above. Yet:
In [5]: print scg["Density"].shape (256, 8, 256)
Any idea why it's downsized?
Oddly, this code (that creates the above) worked fine on a different machine but unfortunately, I inadvertently trashed it's OS earlier in the week. Both systems (i.e. this system that did the above and the one that is now a deadman) are linux.
Any ideas?
Elizabeth _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
Hi Matt, It's the same: In [3]: print scg["Ones"].shape (256, 8, 256) I should add, this machine is running the latest yt: a437280f3cef (yt) tip whereas my old dead machine probably wasn't. I'm not sure if there might have been a recent error added that produced this? Elizabeth Elizabeth On 2012-06-02, at 12:06 AM, Matthew Turk wrote:
Hi Elizabeth,
What is the shape of the Ones field?
Matt
On Jun 1, 2012 10:26 AM, "Elizabeth Tasker" <tasker@astro1.sci.hokudai.ac.jp> wrote: Hi,
I have a smoothed covering grid object:
In [2]: print scg AMRSmoothedCoveringGrid (GR_Enzo2_128amr5_zeus_turb_psupp_rr_0001): level=3, left_edge=[ 0. 31. 0.], right_edge=[ 64. 33. 64.], ActiveDimensions=[2048 64 2048]
which should have dims [2048, 64, 2048] as it claims above. Yet:
In [5]: print scg["Density"].shape (256, 8, 256)
Any idea why it's downsized?
Oddly, this code (that creates the above) worked fine on a different machine but unfortunately, I inadvertently trashed it's OS earlier in the week. Both systems (i.e. this system that did the above and the one that is now a deadman) are linux.
Any ideas?
Elizabeth _______________________________________________ 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 Elizabeth, On Fri, Jun 1, 2012 at 7:34 PM, Elizabeth Tasker <tasker@astro1.sci.hokudai.ac.jp> wrote:
Hi Matt,
It's the same:
In [3]: print scg["Ones"].shape (256, 8, 256)
I should add, this machine is running the latest yt:
a437280f3cef (yt) tip
whereas my old dead machine probably wasn't. I'm not sure if there might have been a recent error added that produced this?
It's a possiblity; John reverted some changes several weeks ago, but I thought that restored it to the previous operations. None of the answer tests have thrown anything, and they do test this functionality. Can you provide a script (pastebinned) that I can run? And, what's the size of your domain? 32, 32, 32 for extent, and dims of ... 128^3? -Matt
Elizabeth
Elizabeth On 2012-06-02, at 12:06 AM, Matthew Turk wrote:
Hi Elizabeth,
What is the shape of the Ones field?
Matt
On Jun 1, 2012 10:26 AM, "Elizabeth Tasker" <tasker@astro1.sci.hokudai.ac.jp> wrote:
Hi,
I have a smoothed covering grid object:
In [2]: print scg AMRSmoothedCoveringGrid (GR_Enzo2_128amr5_zeus_turb_psupp_rr_0001): level=3, left_edge=[ 0. 31. 0.], right_edge=[ 64. 33. 64.], ActiveDimensions=[2048 64 2048]
which should have dims [2048, 64, 2048] as it claims above. Yet:
In [5]: print scg["Density"].shape (256, 8, 256)
Any idea why it's downsized?
Oddly, this code (that creates the above) worked fine on a different machine but unfortunately, I inadvertently trashed it's OS earlier in the week. Both systems (i.e. this system that did the above and the one that is now a deadman) are linux.
Any ideas?
Elizabeth _______________________________________________ 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 Matt,
It's a possiblity; John reverted some changes several weeks ago, but I thought that restored it to the previous operations. None of the answer tests have thrown anything, and they do test this functionality.
Can you provide a script (pastebinned) that I can run? And, what's the size of your domain? 32, 32, 32 for extent, and dims of ... 128^3?
Actually, double my usual: 64 x 64 x 64 kpc boxsize 256 root 3 AMR (static grids) This script produces nothing good: http://paste.yt-project.org/show/2414/ Elizabeth
Hi Elizabeth, Sorry for the delay. I have identified the problem. Your covering grid was only selecting level 0 grids. This resulted in the smoothed covering grid making an early exit. I've added additional steps to produce grid-free refinement/interpolation to higher-levels in changeset 2cd5fa6d84ae. -Matt On Fri, Jun 1, 2012 at 9:40 PM, Elizabeth Tasker <tasker@astro1.sci.hokudai.ac.jp> wrote:
Hi Matt,
It's a possiblity; John reverted some changes several weeks ago, but I thought that restored it to the previous operations. None of the answer tests have thrown anything, and they do test this functionality.
Can you provide a script (pastebinned) that I can run? And, what's the size of your domain? 32, 32, 32 for extent, and dims of ... 128^3?
Actually, double my usual:
64 x 64 x 64 kpc boxsize 256 root 3 AMR (static grids)
This script produces nothing good:
http://paste.yt-project.org/show/2414/
Elizabeth
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
Hi Matt, Sorry to re-visit this issue but while your fix totally solved the previous problem, I have unearthed a second. If I create a scg, the "z" position is correct up to the first & last handful of cells. At this point, is mysteriously starts to decrease along with associate changes in density and acceleration fields. e.g. scg details: AMRSmoothedCoveringGrid (GR_Enzo2_128amr5_zeus_turb_psupp_rr_0001): level=3, left_edge=[ 0. 31. 0.], right_edge=[ 64. 33. 64.], ActiveDimensions=[2048 64 2048] z position for z-index 2035-2047: [ 63.609375 63.640625 63.671875 63.703125 63.734375 63.765625 62.796875 60.828125 57.859375 53.890625 48.921875 42.953125] z position for z-index 0-20: [ 28.015625 21.046875 15.078125 10.109375 6.140625 3.171875 1.203125 0.234375 0.265625 0.296875 0.328125 0.359375 0.390625 0.421875 0.453125 0.484375 0.515625 0.546875 0.578125 0.609375] The same is true in the x direction but the (smaller) y direction is fine: y position for y-index 40-63: [ 32.265625 32.296875 32.328125 32.359375 32.390625 32.421875 32.453125 32.484375 32.515625 32.546875 32.578125 32.609375 32.640625 32.671875 32.703125 32.734375 32.765625 32.796875 32.828125 32.859375 32.890625 32.921875 32.953125] y position for y-index 0-20: [ 31.015625 31.046875 31.078125 31.109375 31.140625 31.171875 31.203125 31.234375 31.265625 31.296875 31.328125 31.359375 31.390625 31.421875 31.453125 31.484375 31.515625 31.546875 31.578125 31.609375] The script that generates that output is here: http://paste.yt-project.org/show/2454/ I actually end up chopping out the middle of my data and using it someplace else, so it's maybe not a problem but it is a bit worrying. Elizabeth On 5 June 2012 23:37, Matthew Turk <matthewturk@gmail.com> wrote:
Hi Elizabeth,
Sorry for the delay. I have identified the problem.
Your covering grid was only selecting level 0 grids. This resulted in the smoothed covering grid making an early exit. I've added additional steps to produce grid-free refinement/interpolation to higher-levels in changeset 2cd5fa6d84ae.
-Matt
On Fri, Jun 1, 2012 at 9:40 PM, Elizabeth Tasker <tasker@astro1.sci.hokudai.ac.jp> wrote:
Hi Matt,
It's a possiblity; John reverted some changes several weeks ago, but I thought that restored it to the previous operations. None of the answer tests have thrown anything, and they do test this functionality.
Can you provide a script (pastebinned) that I can run? And, what's the size of your domain? 32, 32, 32 for extent, and dims of ... 128^3?
Actually, double my usual:
64 x 64 x 64 kpc boxsize 256 root 3 AMR (static grids)
This script produces nothing good:
http://paste.yt-project.org/show/2414/
Elizabeth
_______________________________________________ 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 Elizabeth, There are two ways that the covering grid (not the smoothed covering grid) functions. One is that if the data exists on disk, it fills each zone from that. If it's a derived field (as, for instance, 'x','y','z' are) it will calculate it locally. *However*, this can be overridden by the validator NeedsOriginalGrid, which is good for things like "GridIndices" and whatnot. Okay, so all of that out of the way, the smoothed covering grid does *not* operate like this. All fields, even if htye are derived fields created in grids, are interpolated downward as needed. I remember making this decision, but for the life of me I cannot think why I would; your field is the most obvious, but it seems to me that CellMassMsun would also be incorrect if CellVolume varies between cells. Normally, I would consider this to be a bug and would fix it right out; however, I think this deserves a bit more thought before I just make this change. The change is between: 1) Always interpolating all fields from lower resolution grids 2) Always generating (unless mandated not!) fields that can be generated *from* the interpolated fields. I'm in agreement with point #2. Hearing no objections, I'll make this change. For what it's worth, this should affect a small minority of users, potentially only those already involved in this thread. :) -Matt On Wed, Jun 13, 2012 at 3:36 AM, Elizabeth Tasker <tasker@astro1.sci.hokudai.ac.jp> wrote:
Hi Matt,
Sorry to re-visit this issue but while your fix totally solved the previous problem, I have unearthed a second.
If I create a scg, the "z" position is correct up to the first & last handful of cells. At this point, is mysteriously starts to decrease along with associate changes in density and acceleration fields.
e.g.
scg details: AMRSmoothedCoveringGrid (GR_Enzo2_128amr5_zeus_turb_psupp_rr_0001): level=3, left_edge=[ 0. 31. 0.], right_edge=[ 64. 33. 64.], ActiveDimensions=[2048 64 2048]
z position for z-index 2035-2047: [ 63.609375 63.640625 63.671875 63.703125 63.734375 63.765625 62.796875 60.828125 57.859375 53.890625 48.921875 42.953125]
z position for z-index 0-20: [ 28.015625 21.046875 15.078125 10.109375 6.140625 3.171875 1.203125 0.234375 0.265625 0.296875 0.328125 0.359375 0.390625 0.421875 0.453125 0.484375 0.515625 0.546875 0.578125 0.609375]
The same is true in the x direction but the (smaller) y direction is fine:
y position for y-index 40-63: [ 32.265625 32.296875 32.328125 32.359375 32.390625 32.421875 32.453125 32.484375 32.515625 32.546875 32.578125 32.609375 32.640625 32.671875 32.703125 32.734375 32.765625 32.796875 32.828125 32.859375 32.890625 32.921875 32.953125] y position for y-index 0-20: [ 31.015625 31.046875 31.078125 31.109375 31.140625 31.171875 31.203125 31.234375 31.265625 31.296875 31.328125 31.359375 31.390625 31.421875 31.453125 31.484375 31.515625 31.546875 31.578125 31.609375]
The script that generates that output is here:
http://paste.yt-project.org/show/2454/
I actually end up chopping out the middle of my data and using it someplace else, so it's maybe not a problem but it is a bit worrying.
Elizabeth
On 5 June 2012 23:37, Matthew Turk <matthewturk@gmail.com> wrote:
Hi Elizabeth,
Sorry for the delay. I have identified the problem.
Your covering grid was only selecting level 0 grids. This resulted in the smoothed covering grid making an early exit. I've added additional steps to produce grid-free refinement/interpolation to higher-levels in changeset 2cd5fa6d84ae.
-Matt
On Fri, Jun 1, 2012 at 9:40 PM, Elizabeth Tasker <tasker@astro1.sci.hokudai.ac.jp> wrote:
Hi Matt,
It's a possiblity; John reverted some changes several weeks ago, but I thought that restored it to the previous operations. None of the answer tests have thrown anything, and they do test this functionality.
Can you provide a script (pastebinned) that I can run? And, what's the size of your domain? 32, 32, 32 for extent, and dims of ... 128^3?
Actually, double my usual:
64 x 64 x 64 kpc boxsize 256 root 3 AMR (static grids)
This script produces nothing good:
http://paste.yt-project.org/show/2414/
Elizabeth
_______________________________________________ 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
participants (2)
-
Elizabeth Tasker -
Matthew Turk