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