[Yt-dev] [yt-users] Stars on volume rendering

Sam Skillman samskillman at gmail.com
Thu Jan 13 08:00:22 PST 2011


Hi Matt,

This looks great.  I've attached a modification to the amr_kdtree that seems
to work.  As we talked off-list, I'll make some more changes in the near
future to bring the amr_kdtree closer to HV so that these patches won't be
necessary.  I think I'll wait for this all to get pushed first though.  If
you would rather just push your stuff I can immediately follow with this
amr_kdtree patch, just let me know.

+1 to go live.

Sam

On Wed, Jan 12, 2011 at 10:43 PM, Matthew Turk <matthewturk at gmail.com>wrote:

> Hi everyone,
>
> I tracked down the artifact that was cutting across the grids and
> removed it.  The culprit was in the O3 optimization with GCC 4.2;
> specifically, the optimization that (when disabled) fixed it was gcse,
> the "global common subexpression elimination" optimization.  When this
> optimization was disabled at O3, the artifact disappeared.  And, when
> compiled with O2, the artifact never appeared.  It may have been a
> heisenbug; I looked at the disassembled code as well as the symbols
> output by the optimization, but I was unable to identify a definitive
> culprit.  My guess is something related to aliasing.
>
> The bundle I linked to earlier has been updated to include a fix for
> this problem; I'm a little annoyed I had to modify the underlying
> Cython code to fix this, but by removing a potential aliasing issue
> the optimization problem went away, too.  Anyhow.
>
> The bundle also includes colors for stars.  While the stars still
> retain a constant, all-channel emission coefficient and a single
> effective radius, the colors can (and must) now be set.  I've uploaded
> a new test script and put a new set of images on the web (they total
> 250kb so I figured I would refrain from attaching them.)  This just
> takes particle age, gives it a color, and then integrates that -- it's
> not terribly attractive.  There are some obvious next steps for this
> type of rendering.
>
> http://yt.enzotools.org/files/star_rendering.hg  (you still have to
> recythonize in the tip of this bundle)
> http://paste.enzotools.org/show/1482/
> http://yt.enzotools.org/files/stars_orig.png (straight out of the
> renderer)
> http://yt.enzotools.org/files/stars_high.png (with constricted color
> range)
>
> The stars are still actually added to the intensity as the image plane
> evolves across the simulation, so it is conceivable that this could be
> used for some fun things; in these images and scripts I haven't
> included the gas, because of a units mismatch.  However, the stars are
> still only modeled like slightly extended Gaussians; I think this
> could be given a bit of thought before anything serious is done.
>
> Anyhow, if someone wants to test this out, that'd be great.  Once Sam
> has a chance to make the bricks in the brick_kdtree work with it, it
> can go live in the main branch.
>
> Any thoughts on this?
>
> Best,
>
> Matt
>
> On Mon, Jan 10, 2011 at 12:00 PM, Stephen Skory <stephenskory at yahoo.com>
> wrote:
> > Matt,
> >
> >> Unfortunately, we will need to call the kD-tree many, many time in
> >> succession from with a Cython routine, as well as maintain multiple
> >> extant kD-tree objects simultaneously.  My recollection is that you
> >> use Forthon because the first is not possible, and I also seem to
> >> recall the latter is somewhat difficult.  Additionally, the usage of
> >> the kD-tree inside compiled C code would make it a compile-time
> >> dependency...  What do you think -- does this agree with your
> >> understanding?
> >
> >
> > You're pretty much correct. Again, it would be nice if we could find a
> fast, python-friendly C kD-tree. I've never been happy about the Fortran
> tree, but it is the fastest I've come across. We should all stay on the
> lookout for one!
> >
> >  Stephen Skory
> > stephenskory at yahoo.com
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20110113/25c161ba/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kd_mod.hg
Type: application/octet-stream
Size: 667 bytes
Desc: not available
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20110113/25c161ba/attachment-0001.obj>


More information about the yt-dev mailing list