[Yt-dev] Column Density derived field

Eric Hallman hallman13 at gmail.com
Tue Oct 25 08:35:17 PDT 2011


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 at gmail.com>wrote:

> Hi Eric,
>
> On Tue, Oct 25, 2011 at 11:26 AM, Eric Hallman <hallman13 at 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 at 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 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.
> >> >
> >> > --
> >> > 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
> >> >
> >> _______________________________________________
> >> Yt-dev mailing list
> >> Yt-dev at lists.spacepope.org
> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >
> >
> > _______________________________________________
> > Yt-dev mailing list
> > Yt-dev at lists.spacepope.org
> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >
> >
> _______________________________________________
> Yt-dev mailing list
> Yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20111025/8a1ad864/attachment.html>


More information about the yt-dev mailing list