
Hi all, I'm new to yt. I have questions about making projections of certain region, and inspecting the data returned. I made a cube as follows: import pylab as pl center = [0.5, 0.5, 0.5] halfwidth = 0.005 cube = pf.h.region(center, center-pl.ones(3)*halfwidth, center+pl.ones(3)*halfwidth, ['Density']) print min(cube['x']), max(cube['x']) 0.494873046875 0.505126953125 When I print cube['x'].shape, I get (10728,). I tried to make a projection of this cube along z-axis as follows: proj2 = pf.h.proj(2, 'Density', center=center, source=cube) But I could not understand what is returned. print min(proj2['p x']), max(proj2['py']), proj2['px'].shape 0.00390625 0.99609375 (19648,) print proj2['Density'] [ 0. 0. 0. ..., 0. 0. 0.] My questions are: 1. What exactly is returned in proj2? Why does it span from 0. to 1. when I specified source=cube? 2. I also tried 'data_source=cube' instead of 'source=cube'. It did not raise any error, and returned something different: array of same shape, but with different data values. Is this keyword also used for projection object? Is there a consistent difference between the two keywords in yt? 3. I could not find documentation on some fields like 'px', 'py' that seem to be generated for certain data containers (e.g., 't' for ray objects). Is there an exhaustive list of such fields in the documentation? Thanks in advance. Semyeong

Hi, I just tried your script on a small enzo dataset of 64 cube in size " 1. What exactly is returned in proj2? Why does it span from 0. to 1. when I specified source=cube?" - proj2['Density'] got values of a 2D matrix showing the results of the unweighted projection of 'Density' along z in the x,y plane, in my case the projection was 2x2 pixels. I think the reason it span from 0 to 1 is because you ran a simulation with normalized code units the left edge being 0 and right edge being 1. "2. I also tried 'data_source=cube' instead of 'source=cube'. It did not raise any error, and returned something different: array of same shape, but with different data values. Is this keyword also used for projection object? Is there a consistent difference between the two keywords in yt?" - I tried
I'm not familiar with the different versions of yt so if you can reply with the results of
help(proj2) revealed that proj2 is an 'AMRProj' object, putting it into the search in
proj2.fields
"3. I could not find documentation on some fields like 'px', 'py' that seem to be generated for certain data containers (e.g., 't' for ray objects). Is there an exhaustive list of such fields in the documentation?" - You might have gotten different px, py because you were able to do a different data_source, if you left it with source=cube, what I got in return for >proj2['px'] and >proj2['py'], were the x y edges of cells that are in the projection proj2 in the normalized code units. - doing a the documentation revealed the API page for that base object at the following link http://yt-project.org/doc/api/generated/yt.data_objects.data_containers.AMRP... from there I only see 'source' as a kwarg and not data_source, so that's probably why I'm getting an error when I tried it. - doing a lists the different fields, some like x, dx are in cgs, and px and pdx are in your simulation code units, in this case normalized to 1. I believe the x, dx are the cell-center, and cell-center-distance. I'm not sure about px, pdx, but looking at the values (I changed halfwidth=0.05 to have a bigger than 2x2 projection to play with), I'm going to guess px is the distance of each cell to the center of the projection parallel to x, and pdx is the x-spacing between each cell center. Hope this helps. From G.S. PS. The documentation is being actively improved upon by the developers, so I believe feedback are always welcomed. On Mon, Aug 19, 2013 at 9:22 PM, Semyeong Oh <semyeongoh@gmail.com> wrote:

Hi Semyeong, On Tue, Aug 20, 2013 at 12:22 AM, Semyeong Oh <semyeongoh@gmail.com> wrote:
Hi all,
I'm new to yt.
Welcome to yt! :)
Yup -- so this is because what you're getting isn't actually a cube, but a rectangular prism that (potentially) covers multiple levels of resolution. There are essentially three main types of data objects in yt: 1) Non-spatial data sources (this is unfortunately named, since they are "spatial", they are just not 3D-ordered) which return all the data points inside a region, in essentially unsorted fashion. This would be things like spheres, regions, disks, etc. This also includes things like slices and projections, as they are essentially unordered collections of data. 2) 2D objects that are 2D ordered. The primary type of this object is a FixedResolutionBuffer, which can be created from a projection or a slice. 3) 3D objects that are 3D ordered. This would be a "covering grid", a "smoothed covering grid" or a "grid" object. (More along these lines can be found here: http://yt-project.org/doc/orientation/index.html including in the "How yt thinks about data" section, but there is some discussion in the bootcamp materials as well.) There are a few reasons for this, the main one of which is that *many* but not *all* operations don't require spatial ordering. As an example, often we want to find out the mean value in a region, or the center of mass, or something like that, we don't typically need to know the 3D ordering (as long as we can also have the 3D positions, which we can through the 'x' 'y' 'z' fields). So to get an actual 3D ordering -- which sometimes we need when doing FFTs or whatever -- you can use a covering grid. I'll talk below a bit about getting 2D orderings.
a) proj2 is the "projection" but it's a data source like any other. The special fields, "px", "py" are the "pixel" centers, in the x/y plane of the projection. Typically, to convert this below b) It runs from 0 .. 1 (but with zero as the value outside the cube) because the projection algorithm utilizes a quadtree that is initialized to the dimensions of the domain in the image plane. So if you have pf.domain_dimensions = [256, 256, 256] the quadtree will initialize with [256, 256] root nodes. But, none of those outside the cube will have non-zero values.
This is a weak point in yt we have corrected in the (backwards-incompatible) yt-3.0. I am upset that this distinction has persisted, as "data_source", which is used almost everywhere, is then passed through as a "field_parameter" rathert than anything else. This is something I am embarrassed about and we have changed it for the future, but right now it's an ugly point. (Perhaps for our final 2.x release we should fix this.)
There is an exhaustive list for derived fields, but these are what would be considered "field container" fields and are only documented as needed in the docs, i.e., as related to other concepts. These are px, py, pdx, pdy, which are the pixel centers and half-widths (not full-widths) in the image plane. For rays, t is the integration parameter, such that "t * vec + start_position = final_position" normalized such that t = 1.0 gives final_position. As I mentioned above, to convert projections and slices (and cutting planes) into 2D arrays, you can use either the .to_frb() function (see help(proj2.to_frb) for more info) or the .to_pw() function. These two functions take the variable-resolution data sources and turns them into 2D arrays. The second one, to_pw, turns into a plot window suitable for easy plotting. The first one, to_frb, turns it into a FixedResolutionBuffer which can be queried to return any field in the bounds specified. Hope that helps, and please write back with any further questions! -Matt

Hi, I just tried your script on a small enzo dataset of 64 cube in size " 1. What exactly is returned in proj2? Why does it span from 0. to 1. when I specified source=cube?" - proj2['Density'] got values of a 2D matrix showing the results of the unweighted projection of 'Density' along z in the x,y plane, in my case the projection was 2x2 pixels. I think the reason it span from 0 to 1 is because you ran a simulation with normalized code units the left edge being 0 and right edge being 1. "2. I also tried 'data_source=cube' instead of 'source=cube'. It did not raise any error, and returned something different: array of same shape, but with different data values. Is this keyword also used for projection object? Is there a consistent difference between the two keywords in yt?" - I tried
I'm not familiar with the different versions of yt so if you can reply with the results of
help(proj2) revealed that proj2 is an 'AMRProj' object, putting it into the search in
proj2.fields
"3. I could not find documentation on some fields like 'px', 'py' that seem to be generated for certain data containers (e.g., 't' for ray objects). Is there an exhaustive list of such fields in the documentation?" - You might have gotten different px, py because you were able to do a different data_source, if you left it with source=cube, what I got in return for >proj2['px'] and >proj2['py'], were the x y edges of cells that are in the projection proj2 in the normalized code units. - doing a the documentation revealed the API page for that base object at the following link http://yt-project.org/doc/api/generated/yt.data_objects.data_containers.AMRP... from there I only see 'source' as a kwarg and not data_source, so that's probably why I'm getting an error when I tried it. - doing a lists the different fields, some like x, dx are in cgs, and px and pdx are in your simulation code units, in this case normalized to 1. I believe the x, dx are the cell-center, and cell-center-distance. I'm not sure about px, pdx, but looking at the values (I changed halfwidth=0.05 to have a bigger than 2x2 projection to play with), I'm going to guess px is the distance of each cell to the center of the projection parallel to x, and pdx is the x-spacing between each cell center. Hope this helps. From G.S. PS. The documentation is being actively improved upon by the developers, so I believe feedback are always welcomed. On Mon, Aug 19, 2013 at 9:22 PM, Semyeong Oh <semyeongoh@gmail.com> wrote:

Hi Semyeong, On Tue, Aug 20, 2013 at 12:22 AM, Semyeong Oh <semyeongoh@gmail.com> wrote:
Hi all,
I'm new to yt.
Welcome to yt! :)
Yup -- so this is because what you're getting isn't actually a cube, but a rectangular prism that (potentially) covers multiple levels of resolution. There are essentially three main types of data objects in yt: 1) Non-spatial data sources (this is unfortunately named, since they are "spatial", they are just not 3D-ordered) which return all the data points inside a region, in essentially unsorted fashion. This would be things like spheres, regions, disks, etc. This also includes things like slices and projections, as they are essentially unordered collections of data. 2) 2D objects that are 2D ordered. The primary type of this object is a FixedResolutionBuffer, which can be created from a projection or a slice. 3) 3D objects that are 3D ordered. This would be a "covering grid", a "smoothed covering grid" or a "grid" object. (More along these lines can be found here: http://yt-project.org/doc/orientation/index.html including in the "How yt thinks about data" section, but there is some discussion in the bootcamp materials as well.) There are a few reasons for this, the main one of which is that *many* but not *all* operations don't require spatial ordering. As an example, often we want to find out the mean value in a region, or the center of mass, or something like that, we don't typically need to know the 3D ordering (as long as we can also have the 3D positions, which we can through the 'x' 'y' 'z' fields). So to get an actual 3D ordering -- which sometimes we need when doing FFTs or whatever -- you can use a covering grid. I'll talk below a bit about getting 2D orderings.
a) proj2 is the "projection" but it's a data source like any other. The special fields, "px", "py" are the "pixel" centers, in the x/y plane of the projection. Typically, to convert this below b) It runs from 0 .. 1 (but with zero as the value outside the cube) because the projection algorithm utilizes a quadtree that is initialized to the dimensions of the domain in the image plane. So if you have pf.domain_dimensions = [256, 256, 256] the quadtree will initialize with [256, 256] root nodes. But, none of those outside the cube will have non-zero values.
This is a weak point in yt we have corrected in the (backwards-incompatible) yt-3.0. I am upset that this distinction has persisted, as "data_source", which is used almost everywhere, is then passed through as a "field_parameter" rathert than anything else. This is something I am embarrassed about and we have changed it for the future, but right now it's an ugly point. (Perhaps for our final 2.x release we should fix this.)
There is an exhaustive list for derived fields, but these are what would be considered "field container" fields and are only documented as needed in the docs, i.e., as related to other concepts. These are px, py, pdx, pdy, which are the pixel centers and half-widths (not full-widths) in the image plane. For rays, t is the integration parameter, such that "t * vec + start_position = final_position" normalized such that t = 1.0 gives final_position. As I mentioned above, to convert projections and slices (and cutting planes) into 2D arrays, you can use either the .to_frb() function (see help(proj2.to_frb) for more info) or the .to_pw() function. These two functions take the variable-resolution data sources and turns them into 2D arrays. The second one, to_pw, turns into a plot window suitable for easy plotting. The first one, to_frb, turns it into a FixedResolutionBuffer which can be queried to return any field in the bounds specified. Hope that helps, and please write back with any further questions! -Matt
participants (3)
-
Geoffrey So
-
Matthew Turk
-
Semyeong Oh