[Yt-dev] Column Density derived field

[Matthew Turk]

On Tue, Oct 25, 2011 at 9:23 AM, Stephen Skory <s at 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.

I have reconsidered my position.  I wrote a set of adaptive healpix
routines last Spring that I wasn't able to get to work.  Here's where
I was at, last Spring.

1) I created an "AdaptiveRaySource" which emanated "AdaptiveRayPackets"
2) Each ray packet walked a given grid.  At the entry to a grid, it
was checked to see if it needed to be refined.  If so, it was.
3) At the end, they were collected into an array of value, pixel id, and NSide.

There were a couple problems with this.  The first is that rays got
lost once in a while; this may be either because of a bug in my
implementation or because they get refined to a grid that's previous
in the kD-tree traversal.  It should be fixable.  There are two
additional problems: the first is that step #2 is not correct.  The
rays should be checked at every single cell traversal to see if they
need to be refined.  The second problem is that right now it would be
difficult to deposit the column density, although this is readily
fixed.  I think the entire thing is tractable, and I think it should
coincide with a refactoring of the current volume rendering.

As it stands, volume rendering in yt right now uses the
PartitionedGrid class, which walks rays and calls sample_values.  I
think it would be more efficient for what we're talking about doing to
re-use this implementation of Amanatides & Woo but supply a function
pointer and a void* struct of data to the function pointer, which
would allow us to use the same "cast_ray" function for both adaptive
ray packets and normal packets.  This would also allow us to refine
rays mid-grid.

Anyway, if you're interested in this, let me know.

-Matt

>
> --
> Stephen Skory
> s at skory.us
> http://stephenskory.com/
> 510.621.3687 (google voice)
> _______________________________________________
> Yt-dev mailing list
> Yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>