Hi Matt,<div><br></div><div>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.</div>
<div><br></div><div>+1 to go live.</div><div><br></div><div>Sam<br><br><div class="gmail_quote">On Wed, Jan 12, 2011 at 10:43 PM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi everyone,<br>
<br>
I tracked down the artifact that was cutting across the grids and<br>
removed it. The culprit was in the O3 optimization with GCC 4.2;<br>
specifically, the optimization that (when disabled) fixed it was gcse,<br>
the "global common subexpression elimination" optimization. When this<br>
optimization was disabled at O3, the artifact disappeared. And, when<br>
compiled with O2, the artifact never appeared. It may have been a<br>
heisenbug; I looked at the disassembled code as well as the symbols<br>
output by the optimization, but I was unable to identify a definitive<br>
culprit. My guess is something related to aliasing.<br>
<br>
The bundle I linked to earlier has been updated to include a fix for<br>
this problem; I'm a little annoyed I had to modify the underlying<br>
Cython code to fix this, but by removing a potential aliasing issue<br>
the optimization problem went away, too. Anyhow.<br>
<br>
The bundle also includes colors for stars. While the stars still<br>
retain a constant, all-channel emission coefficient and a single<br>
effective radius, the colors can (and must) now be set. I've uploaded<br>
a new test script and put a new set of images on the web (they total<br>
250kb so I figured I would refrain from attaching them.) This just<br>
takes particle age, gives it a color, and then integrates that -- it's<br>
not terribly attractive. There are some obvious next steps for this<br>
type of rendering.<br>
<br>
<a href="http://yt.enzotools.org/files/star_rendering.hg" target="_blank">http://yt.enzotools.org/files/star_rendering.hg</a> (you still have to<br>
recythonize in the tip of this bundle)<br>
<a href="http://paste.enzotools.org/show/1482/" target="_blank">http://paste.enzotools.org/show/1482/</a><br>
<a href="http://yt.enzotools.org/files/stars_orig.png" target="_blank">http://yt.enzotools.org/files/stars_orig.png</a> (straight out of the renderer)<br>
<a href="http://yt.enzotools.org/files/stars_high.png" target="_blank">http://yt.enzotools.org/files/stars_high.png</a> (with constricted color range)<br>
<br>
The stars are still actually added to the intensity as the image plane<br>
evolves across the simulation, so it is conceivable that this could be<br>
used for some fun things; in these images and scripts I haven't<br>
included the gas, because of a units mismatch. However, the stars are<br>
still only modeled like slightly extended Gaussians; I think this<br>
could be given a bit of thought before anything serious is done.<br>
<br>
Anyhow, if someone wants to test this out, that'd be great. Once Sam<br>
has a chance to make the bricks in the brick_kdtree work with it, it<br>
can go live in the main branch.<br>
<br>
Any thoughts on this?<br>
<br>
Best,<br>
<br>
Matt<br>
<div><div></div><div class="h5"><br>
On Mon, Jan 10, 2011 at 12:00 PM, Stephen Skory <<a href="mailto:stephenskory@yahoo.com">stephenskory@yahoo.com</a>> wrote:<br>
> Matt,<br>
><br>
>> Unfortunately, we will need to call the kD-tree many, many time in<br>
>> succession from with a Cython routine, as well as maintain multiple<br>
>> extant kD-tree objects simultaneously. My recollection is that you<br>
>> use Forthon because the first is not possible, and I also seem to<br>
>> recall the latter is somewhat difficult. Additionally, the usage of<br>
>> the kD-tree inside compiled C code would make it a compile-time<br>
>> dependency... What do you think -- does this agree with your<br>
>> understanding?<br>
><br>
><br>
> 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!<br>
><br>
> Stephen Skory<br>
> <a href="mailto:stephenskory@yahoo.com">stephenskory@yahoo.com</a><br>
> <a href="http://stephenskory.com/" target="_blank">http://stephenskory.com/</a><br>
> 510.621.3687 (google voice)<br>
> _______________________________________________<br>
> Yt-dev mailing list<br>
> <a href="mailto:Yt-dev@lists.spacepope.org">Yt-dev@lists.spacepope.org</a><br>
> <a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
><br>
_______________________________________________<br>
Yt-dev mailing list<br>
<a href="mailto:Yt-dev@lists.spacepope.org">Yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
</div></div></blockquote></div><br></div>