Thank you Matt and Geoffrey for the help.
That cleared things up for now.

Best,
Semyeong


On Tue, Aug 20, 2013 at 11:29 AM, Matthew Turk <matthewturk@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!  :)

> 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,).

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.

> 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?

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.

>
> 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?

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.)

>
> 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?

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

>
> Thanks in advance.
>
> Semyeong
>
> _______________________________________________
> 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