Hi Eric, On Tue, Oct 25, 2011 at 11:26 AM, Eric Hallman <hallman13@gmail.com> wrote:
Matt and everyone, I'm also interested in a tool of this type. Stephen has a particular use in mind, but also, one could imagine calculating an "all-sky" light-cone type of thing using the similar code tool. Does the HEALPIX stuff do that?
Yes, the existing HEALpix will do this; what I believe Stephen is addressing is the deposition of column density back in the grids. The existing HEALpix will calculate column density (and can also calculate star particle contributions) between two radii and return that to the user.
We had discussed in the past doing a projection outward from a point, then stacking the higher z outputs in shells around the z=0 set, to make a spherical lightcone projection.
I believe this is possible with existing infrastructure, but keep in mind that it will only currently work with a static-resolution HEALpix pixelization. Stephen's will deposit column density back on the grid so that it can then be treated as any other field in yt. -Matt
Not sure if the current tools are capable of the individual pieces of such an operation, but what Stephen's describing would certainly do part of it. Eric
On Tue, Oct 25, 2011 at 11:22 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi Stephen,
For what it's worth, I also agree with Cameron that calling it "ColumnDensity" is a bit too broad, and maybe it should be called something like "RadialColumnDensity" or something similarly indicative of its nature to indicate it's not the same as a projection.
Can you also maybe take a minute to outline a couple use cases?
-Matt
On Tue, Oct 25, 2011 at 9:23 AM, Stephen Skory <s@skory.us> wrote:
Cameron & Matt,
What it's called isn't a big concern to me, but I see what you're saying, Cameron.
The issue about field detector is an interesting one. I guess I don't understand why asking for 'x' is a problem. Your solution sounds good to me.
When I wasn't looking for the field detector as I am now, what was happening is data['x' or 'y' or 'z'] would return some values that weren't cell centers, which when passed to the interpolation stuff would not work. So asking for 'x' wasn't a problem, but the values it returned were not what I wanted.
How fast is the code? It looks to me like it probably does quite a few expensive operations
Running on a 40^3 dataset on my 2.0Ghz i7 lappy on battery power gives about 300,000 cells/second for the whole process (HEALPix with 5 surfaces + interpolation). I think I'm close to making it parallel, but some weird stuff is popping up that I don't quite understand just yet.
... would you be willing at some point in the future to explore replacing it with an actual adaptive healpix operation?
Perhaps. It seems to me before you said that that would be quite a bit more difficult, which looking at the source is true. Everything in this current attempt is using numpy vectorization, so I don't know how much more speed can be squeezed out of this method.
-- Stephen Skory s@skory.us http://stephenskory.com/ 510.621.3687 (google voice) _______________________________________________ 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
_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org