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

[Matthew Turk]

Hi Sam,

Awesome!  I've unbundled your patch and pushed it to the main trunk.
I have *not* re-cythonized, so this change is not "live" for anyone
that chooses not to re-Cythonize.

On that note, I updated the installation script a while back to
install Cython.  Pushing around amr_utils.c all the time seems to me
to be a mistake -- the changesets keep getting bigger and bigger, and
it's eventually going to get to the point that it's not feasible
anymore.

Does anyone have any feelings on making Cython mandatory for
installation?  It has already been included in the install script for
a little while.  We can also try providing a fallback option, in the
event that Cython is not installed, that will require network access.
+1/-1 to Cython being required and handled by the installation script?

-Matt

On Thu, Jan 13, 2011 at 11:00 AM, Sam Skillman <samskillman at gmail.com> wrote:
> 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
>
>
> _______________________________________________
> Yt-dev mailing list
> Yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>