[yt-users] kd-Tree rendering

Britton Smith brittonsmith at gmail.com
Mon Nov 22 15:31:04 PST 2010


Pardon my insanity, everyone.  I just uploaded a slightly better version of
this movie to vimeo.  It's here:
http://vimeo.com/17100442
You can get it here as well:
http://www.pa.msu.edu/people/britton/whim_movies/evolve_assemble.mp4
or here for a higher resolution version:
http://www.pa.msu.edu/people/britton/whim_movies/evolve_assemble_hd.mp4<http://www.pa.msu.edu/people/britton/whim_movies/evolve_assemble.mp4>

Britton

On Mon, Nov 22, 2010 at 4:18 PM, Britton Smith <brittonsmith at gmail.com>wrote:

> Hi again everyone,
>
> 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:
> http://vimeo.com/groups/ytgallery/videos/17095494
> If you can't wait, I put it here as well:
> http://www.pa.msu.edu/people/britton/whim_movies/evolve_assemble.mp4
>
> Thanks again to Matt and Sam for making this whole thing possible.
>
> Britton
>
>
> On Fri, Nov 19, 2010 at 11:27 AM, Britton Smith <brittonsmith at gmail.com>wrote:
>
>> Hi all,
>>
>> 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!
>>
>> Britton
>>
>>
>> On Wed, Nov 10, 2010 at 11:46 AM, Matthew Turk <matthewturk at gmail.com>wrote:
>>
>>> Hi Sam,
>>>
>>> Great work!  I'm really happy to see this make it into the primary trunk.
>>>
>>> I'd like to encourage people to try this out, particularly on large
>>> datasets, and write to the list or Sam if you run into problems.  This
>>> is a big increase in functionality, and everyone wants to make sure it
>>> works out alright.
>>>
>>> I've been using the volume rendering capabilities of yt quite
>>> extensively, in kind of an unconventional way, to calculate off-axis
>>> average values, and I'm very excited about the performance
>>> improvements that this new subsystem will bring.
>>>
>>> Congrats, Sam!
>>>
>>> -Matt
>>>
>>> On Tue, Nov 9, 2010 at 5:12 PM, Sam Skillman <samskillman at gmail.com>
>>> wrote:
>>> > Hi all,
>>> > I just wanted to announce that the new kd-Tree rendering framework is
>>> now in
>>> > the 'yt' branch of the repository.  There are a couple things I wanted
>>> to
>>> > point to if you are interested.
>>> > The changeset itself:
>>> > http://yt.enzotools.org/changeset/c7947fef16ac/
>>> > A post on blog.enzotools.org highlighting some recent successes:
>>> > http://blog.enzotools.org/amr-kd-tree-rendering-added-to-yt
>>> > A simple script, where you should just have to change the parameter
>>> file
>>> > name:
>>> > http://paste.enzotools.org/show/1367/
>>> > A more advanced script that exposes a few new options:
>>> > http://paste.enzotools.org/show/1368/
>>> > Both of these scripts should be able to be run in parallel (as long as
>>> N is
>>> > a power of 2 for now) transparently as:
>>> > mpirun -np N python script.py --parallel
>>> > Parallel performance will depend on the structure of your data, but the
>>> docs
>>> > for the Camera object have some suggestions.
>>> > If you find any problems or have any thoughts, let me know!
>>> > Best,
>>> > Sam
>>> >
>>> > _______________________________________________
>>> > yt-users mailing list
>>> > yt-users at lists.spacepope.org
>>> > http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>> >
>>> >
>>> _______________________________________________
>>> yt-users mailing list
>>> yt-users at lists.spacepope.org
>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-users-spacepope.org/attachments/20101122/04ec3122/attachment.html>


More information about the yt-users mailing list