Matt,
  OK, thanks for clearing that up.  The deposition of that quantity (or others like it) could be useful in a number of ways.  It is a very specific type of need, but I think there could be others.  For instance, one could use this to post-process simulations with rad transport. One could have a collection of points and construct a radiation field quantity on the grid for instance in yt based on distance from the points and assumed luminosity.  That is, if one did not do active rad transport in a run.  

Anyway, interesting.

Thanks.

Eric

On Tue, Oct 25, 2011 at 11:30 AM, Matthew Turk <matthewturk@gmail.com> wrote:
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
>
>
_______________________________________________
Yt-dev mailing list
Yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org