Hi again everyone,<br><br>For those who are interested, I just finished the final version of the movie I referred to in my post to this thread. I have uploaded it to the yt group on vimeo, and it will be available shortly here:<br>
<a href="http://vimeo.com/groups/ytgallery/videos/17095494">http://vimeo.com/groups/ytgallery/videos/17095494</a><br>If you can't wait, I put it here as well:<br><a href="http://www.pa.msu.edu/people/britton/whim_movies/evolve_assemble.mp4">http://www.pa.msu.edu/people/britton/whim_movies/evolve_assemble.mp4</a><br>
<br>Thanks again to Matt and Sam for making this whole thing possible.<br><br>Britton<br><br><div class="gmail_quote">On Fri, Nov 19, 2010 at 11:27 AM, Britton Smith <span dir="ltr"><<a href="mailto:brittonsmith@gmail.com">brittonsmith@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi all,<br><br>I recently did some volume renders of a 50 Mpc box unigrid simulation with 1024^3 grid cells on kraken. I used exactly 64 cores and did not have to use less than the full number of cores available per node. I was making 1024^2 images that took roughly between 5-10 seconds to render. I tried some 2048 that took around 30-40 seconds. I was rendering baryon overdensity with a transfer function that had 2000 narrow gaussians. The number was high because I am combining this with a movie in which I render only one of those guassians at a time and build the box up from low overdensity up to high. I didn't go to lower number of processors, so I'm not exactly sure at what point this would have run out of ram. I consider this an overwhelming success. I've attached some sample images, one with the full transfer function and a sample frame from the movie where I do them one at a time while spinning. Very very nice job!<br>
<font color="#888888">
<br>Britton</font><div><div></div><div class="h5"><br><br><div class="gmail_quote">On Wed, Nov 10, 2010 at 11:46 AM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi Sam,<br>
<br>
Great work! I'm really happy to see this make it into the primary trunk.<br>
<br>
I'd like to encourage people to try this out, particularly on large<br>
datasets, and write to the list or Sam if you run into problems. This<br>
is a big increase in functionality, and everyone wants to make sure it<br>
works out alright.<br>
<br>
I've been using the volume rendering capabilities of yt quite<br>
extensively, in kind of an unconventional way, to calculate off-axis<br>
average values, and I'm very excited about the performance<br>
improvements that this new subsystem will bring.<br>
<br>
Congrats, Sam!<br>
<br>
-Matt<br>
<div><div></div><div><br>
On Tue, Nov 9, 2010 at 5:12 PM, Sam Skillman <<a href="mailto:samskillman@gmail.com" target="_blank">samskillman@gmail.com</a>> wrote:<br>
> Hi all,<br>
> I just wanted to announce that the new kd-Tree rendering framework is now in<br>
> the 'yt' branch of the repository. There are a couple things I wanted to<br>
> point to if you are interested.<br>
> The changeset itself:<br>
> <a href="http://yt.enzotools.org/changeset/c7947fef16ac/" target="_blank">http://yt.enzotools.org/changeset/c7947fef16ac/</a><br>
> A post on <a href="http://blog.enzotools.org" target="_blank">blog.enzotools.org</a> highlighting some recent successes:<br>
> <a href="http://blog.enzotools.org/amr-kd-tree-rendering-added-to-yt" target="_blank">http://blog.enzotools.org/amr-kd-tree-rendering-added-to-yt</a><br>
> A simple script, where you should just have to change the parameter file<br>
> name:<br>
> <a href="http://paste.enzotools.org/show/1367/" target="_blank">http://paste.enzotools.org/show/1367/</a><br>
> A more advanced script that exposes a few new options:<br>
> <a href="http://paste.enzotools.org/show/1368/" target="_blank">http://paste.enzotools.org/show/1368/</a><br>
> Both of these scripts should be able to be run in parallel (as long as N is<br>
> a power of 2 for now) transparently as:<br>
> mpirun -np N python script.py --parallel<br>
> Parallel performance will depend on the structure of your data, but the docs<br>
> for the Camera object have some suggestions.<br>
> If you find any problems or have any thoughts, let me know!<br>
> Best,<br>
> Sam<br>
><br>
</div></div>> _______________________________________________<br>
> yt-users mailing list<br>
> <a href="mailto:yt-users@lists.spacepope.org" target="_blank">yt-users@lists.spacepope.org</a><br>
> <a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
><br>
><br>
_______________________________________________<br>
yt-users mailing list<br>
<a href="mailto:yt-users@lists.spacepope.org" target="_blank">yt-users@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
</blockquote></div><br>
</div></div></blockquote></div><br>