[Yt-dev] Density Column calculation

Matthew Turk matthewturk at gmail.com
Fri Oct 7 16:12:06 PDT 2011


Hi Stephen,

On Fri, Oct 7, 2011 at 7:03 PM, Stephen Skory <s at skory.us> wrote:
> Hi all,
>
> I'd like to be able to calculate the column density around a point
> similar to the example in the docs
>
> http://yt-project.org/doc/visualizing/volume_rendering.html#healpix-volume-rendering
>
> but instead of a single surface, I'd like to generate as something
> close to a derived field as I can, where the cell values are the
> column density from the specified point. I've never worked with the
> internals of ray casting in yt, but it seems that it may be possible
> to use this interface to accomplish this. Instead of integrating and
> stopping the calculation of column density at a surface, I'd like to
> be able to get the value of that integral as it goes along all the way
> to the surface (or to the edge of the volume), preferably in
> cell-centered fashion. Does this make sense?

Yes -- you want to deposit in the cell the value that each ray has
accumulated.  In the ray casting terminology, this means setting the
underlying data through with rays are being cast to the value of the
'image plane' when using a projection transfer function.

>
> My specific question is to those who understand ray casting better
> than I do. Can you please give me some hints as to where to look so I
> can apply this modification? And any thoughts or comments would be
> appreciated!

Sure: my first thought is that this is going to be difficult.  It
would be much, much easier (although possibly much slower, once you
get to high values of Nside) to use the healpix wrappers to get back
vectors, then using non-orthogonal rays between the final surface and
the centroid, and integrating the value of density along each.  I'd
recommend doing this, and manually parallelizing the computation by
distributing rays to different processors.

If you want to use the internal functionality of the ray tracing,
you'll need to turn off ray casting, add an additional field to each
PartitionedGrid object, and then change the eval_transfer function to
a new function of your design that deposits a value back in
partitioned_grid_instance.my_data[index_of_new_field].  Then you'll
have to stitch these back into their original grids.  Then you'll need
to pull out the interpolation code so that it samples only once and
doesn't use vertex-centered data.

You may instead want to look at how non-ortho rays are "walked" across
a grid, and put into Cython the necessary items to simply walk each
and every single one of the rays simultaneously; call this a "ray
group" or something, and just walk one after the other in lockstep
over a (standard, non-"partitioned") grid, recording the values the
same way that the non-orthogonal rays do.

Good luck, and please write back with more questions/ideas/problems!
This could be very cool functionality, as it would be useful in many
cases to see the column density wrt a given source at a second point.

-Matt

>
> Thanks!
>
> --
> 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
>



More information about the yt-dev mailing list