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

Matthew Turk matthewturk at gmail.com
Wed Jan 12 21:43:44 PST 2011


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
>



More information about the yt-dev mailing list