Re: [Yt-dev] [yt-users] Stars on volume rendering
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@yahoo.com http://stephenskory.com/ 510.621.3687 (google voice)
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
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@yahoo.com http://stephenskory.com/ 510.621.3687 (google voice) _______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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
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
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
On Mon, Jan 10, 2011 at 12:00 PM, Stephen Skory
wrote: tree, but it is the fastest I've come across. We should all stay on the lookout for one! Stephen Skory stephenskory@yahoo.com http://stephenskory.com/ 510.621.3687 (google voice) _______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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
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
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
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@yahoo.com http://stephenskory.com/ 510.621.3687 (google voice) _______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ Yt-dev mailing list Yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (3)
-
Matthew Turk
-
Sam Skillman
-
Stephen Skory