Mailman 3 Fwd: [yt_analysis/yt] Volume Rendering Refactor (pull request #168) - yt-dev

Fwd: [yt_analysis/yt] Volume Rendering Refactor (pull request #168)

Matthew Turk

13 Jun 2012 13 Jun '12

3:12 p.m.

Sam and I chatted, and we'd like to request three people test this and if they all agree, we can accept it. Can three people give it a go? ---------- Forwarded message ---------- From: Matthew Turk Date: Wed, Jun 13, 2012 at 11:12 AM Subject: [yt_analysis/yt] Volume Rendering Refactor (pull request #168) To: yt@enzotools.org A new pull request has been opened by Matthew Turk. MatthewTurk/yt-refactor has changes to be pulled into yt_analysis/yt. https://bitbucket.org/yt_analysis/yt/pull-request/168/volume-rendering-refac... Title: Volume Rendering Refactor This includes all of the changes to the volume rendering system that were discussed here: http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-June/002039.h... The main user-facing changes that could cause problems: 1) Cython 0.16 is now required. 2) Off-axis projections no longer interpolate. Changes to be pulled: -- This is an issue notification from bitbucket.org. You are receiving this either because you are the participating in a pull request, or you are following it.

Show replies by date

Britton Smith

13 Jun 13 Jun

4:18 p.m.

Hi Sam, Matt, Very nice work on this! I'd be glad to test it out. I have largely been skimming most of the discussion of the new rendering. Would it be possible to provide a couple of scripts that I could try out on my own data? I can run them on the PR as well as the current tip and check for changes in results as well as time taken. Maybe one script to test each major upgrade would be helpful. Britton On Wed, Jun 13, 2012 at 11:12 AM, Matthew Turk wrote:

...

Sam and I chatted, and we'd like to request three people test this and if they all agree, we can accept it.

Can three people give it a go?

---------- Forwarded message ---------- From: Matthew Turk Date: Wed, Jun 13, 2012 at 11:12 AM Subject: [yt_analysis/yt] Volume Rendering Refactor (pull request #168) To: yt@enzotools.org

A new pull request has been opened by Matthew Turk.

MatthewTurk/yt-refactor has changes to be pulled into yt_analysis/yt.

https://bitbucket.org/yt_analysis/yt/pull-request/168/volume-rendering-refac...

Title: Volume Rendering Refactor

This includes all of the changes to the volume rendering system that were discussed here:

http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-June/002039.h...

The main user-facing changes that could cause problems:

1) Cython 0.16 is now required. 2) Off-axis projections no longer interpolate.

Changes to be pulled:

-- This is an issue notification from bitbucket.org. You are receiving this either because you are the participating in a pull request, or you are following it. _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

John ZuHone

4:22 p.m.

Matt, I'll give it a whirl... it may take a day or two. John Z On Jun 13, 2012, at 11:12 AM, Matthew Turk wrote:

...

Sam and I chatted, and we'd like to request three people test this and if they all agree, we can accept it.

Can three people give it a go?

---------- Forwarded message ---------- From: Matthew Turk Date: Wed, Jun 13, 2012 at 11:12 AM Subject: [yt_analysis/yt] Volume Rendering Refactor (pull request #168) To: yt@enzotools.org

A new pull request has been opened by Matthew Turk.

MatthewTurk/yt-refactor has changes to be pulled into yt_analysis/yt.

https://bitbucket.org/yt_analysis/yt/pull-request/168/volume-rendering-refac...

Title: Volume Rendering Refactor

This includes all of the changes to the volume rendering system that were discussed here:

http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-June/002039.h...

The main user-facing changes that could cause problems:

1) Cython 0.16 is now required. 2) Off-axis projections no longer interpolate.

Changes to be pulled:

-- This is an issue notification from bitbucket.org. You are receiving this either because you are the participating in a pull request, or you are following it. _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

Sam Skillman

4:34 p.m.

Hi all, Here's a sample script that exposes a few of the new features such as opacity and the map_to_colormap function. http://paste.yt-project.org/show/2458/ I'll see if I can get some more scripts written in a portable way. Cheers, Sam On Wed, Jun 13, 2012 at 10:22 AM, John ZuHone wrote:

...

Matt,

I'll give it a whirl... it may take a day or two.

John Z

On Jun 13, 2012, at 11:12 AM, Matthew Turk wrote:

...
Sam and I chatted, and we'd like to request three people test this and if they all agree, we can accept it.

Can three people give it a go?

---------- Forwarded message ---------- From: Matthew Turk Date: Wed, Jun 13, 2012 at 11:12 AM Subject: [yt_analysis/yt] Volume Rendering Refactor (pull request #168) To: yt@enzotools.org

A new pull request has been opened by Matthew Turk.

MatthewTurk/yt-refactor has changes to be pulled into yt_analysis/yt.

https://bitbucket.org/yt_analysis/yt/pull-request/168/volume-rendering-refac...

...
Title: Volume Rendering Refactor

This includes all of the changes to the volume rendering system that were discussed here:

http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-June/002039.h...

...
The main user-facing changes that could cause problems:

1) Cython 0.16 is now required. 2) Off-axis projections no longer interpolate.

Changes to be pulled:

-- This is an issue notification from bitbucket.org. You are receiving this either because you are the participating in a pull request, or you are following it. _______________________________________________ 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

Matthew Turk

5:45 p.m.

Also, for what it's worth, John, Sam and I have been working on creating a movie sequence with this in HiDef for a display project. Once that's done we're going to be posting the movie, the original scripts, and potentially even a screencast of how one goes about doing a complex volume rendering. On Wed, Jun 13, 2012 at 12:34 PM, Sam Skillman wrote:

...

Hi all,

Here's a sample script that exposes a few of the new features such as opacity and the map_to_colormap function. http://paste.yt-project.org/show/2458/

I'll see if I can get some more scripts written in a portable way.

Cheers, Sam

On Wed, Jun 13, 2012 at 10:22 AM, John ZuHone wrote:

...
Matt,

I'll give it a whirl... it may take a day or two.

John Z

On Jun 13, 2012, at 11:12 AM, Matthew Turk wrote:

...
Sam and I chatted, and we'd like to request three people test this and if they all agree, we can accept it.

Can three people give it a go?

---------- Forwarded message ---------- From: Matthew Turk Date: Wed, Jun 13, 2012 at 11:12 AM Subject: [yt_analysis/yt] Volume Rendering Refactor (pull request #168) To: yt@enzotools.org

A new pull request has been opened by Matthew Turk.

MatthewTurk/yt-refactor has changes to be pulled into yt_analysis/yt.

https://bitbucket.org/yt_analysis/yt/pull-request/168/volume-rendering-refac...

Title: Volume Rendering Refactor

This includes all of the changes to the volume rendering system that were discussed here:

http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-June/002039.h...

The main user-facing changes that could cause problems:

1) Cython 0.16 is now required. 2) Off-axis projections no longer interpolate.

Changes to be pulled:

-- This is an issue notification from bitbucket.org. You are receiving this either because you are the participating in a pull request, or you are following it. _______________________________________________ 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

Christopher Moody

7:47 p.m.

Works for me! On one core, no_ghost=True, kd-Tree took 5 seconds, ray casting 56 seconds. Impressive. chris On Wed, Jun 13, 2012 at 10:45 AM, Matthew Turk wrote:

...

Also, for what it's worth, John, Sam and I have been working on creating a movie sequence with this in HiDef for a display project. Once that's done we're going to be posting the movie, the original scripts, and potentially even a screencast of how one goes about doing a complex volume rendering.

On Wed, Jun 13, 2012 at 12:34 PM, Sam Skillman wrote:

...
Hi all,

Here's a sample script that exposes a few of the new features such as opacity and the map_to_colormap function. http://paste.yt-project.org/show/2458/

I'll see if I can get some more scripts written in a portable way.

Cheers, Sam

On Wed, Jun 13, 2012 at 10:22 AM, John ZuHone wrote:

...
Matt,

I'll give it a whirl... it may take a day or two.

John Z

On Jun 13, 2012, at 11:12 AM, Matthew Turk wrote:

...
Sam and I chatted, and we'd like to request three people test this and if they all agree, we can accept it.

Can three people give it a go?

---------- Forwarded message ---------- From: Matthew Turk Date: Wed, Jun 13, 2012 at 11:12 AM Subject: [yt_analysis/yt] Volume Rendering Refactor (pull request #168) To: yt@enzotools.org

A new pull request has been opened by Matthew Turk.

MatthewTurk/yt-refactor has changes to be pulled into yt_analysis/yt.

https://bitbucket.org/yt_analysis/yt/pull-request/168/volume-rendering-refac...

Title: Volume Rendering Refactor

This includes all of the changes to the volume rendering system that were discussed here:

http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-June/002039.h...

The main user-facing changes that could cause problems:

1) Cython 0.16 is now required. 2) Off-axis projections no longer interpolate.

Changes to be pulled:

-- This is an issue notification from bitbucket.org. You are receiving this either because you are the participating in a pull request, or you are following it. _______________________________________________ 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

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

Matthew Turk

8:01 p.m.

Chris, is this an ART dataset rendering? I love it. Great work. And, did you note on your machine what the load went up to? Did it scale with the numebr of cores okay? On Wed, Jun 13, 2012 at 3:47 PM, Christopher Moody wrote:

...

Works for me!

On one core, no_ghost=True, kd-Tree took 5 seconds, ray casting 56 seconds. Impressive.

chris

On Wed, Jun 13, 2012 at 10:45 AM, Matthew Turk wrote:

...
Also, for what it's worth, John, Sam and I have been working on creating a movie sequence with this in HiDef for a display project. Once that's done we're going to be posting the movie, the original scripts, and potentially even a screencast of how one goes about doing a complex volume rendering.

On Wed, Jun 13, 2012 at 12:34 PM, Sam Skillman wrote:

...
Hi all,

Here's a sample script that exposes a few of the new features such as opacity and the map_to_colormap function. http://paste.yt-project.org/show/2458/

I'll see if I can get some more scripts written in a portable way.

Cheers, Sam

On Wed, Jun 13, 2012 at 10:22 AM, John ZuHone wrote:

...
Matt,

I'll give it a whirl... it may take a day or two.

John Z

On Jun 13, 2012, at 11:12 AM, Matthew Turk wrote:

...
Sam and I chatted, and we'd like to request three people test this and if they all agree, we can accept it.

Can three people give it a go?

---------- Forwarded message ---------- From: Matthew Turk Date: Wed, Jun 13, 2012 at 11:12 AM Subject: [yt_analysis/yt] Volume Rendering Refactor (pull request #168) To: yt@enzotools.org

A new pull request has been opened by Matthew Turk.

MatthewTurk/yt-refactor has changes to be pulled into yt_analysis/yt.

https://bitbucket.org/yt_analysis/yt/pull-request/168/volume-rendering-refac...

Title: Volume Rendering Refactor

This includes all of the changes to the volume rendering system that were discussed here:

http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-June/002039.h...

The main user-facing changes that could cause problems:

1) Cython 0.16 is now required. 2) Off-axis projections no longer interpolate.

Changes to be pulled:

-- This is an issue notification from bitbucket.org. You are receiving this either because you are the participating in a pull request, or you are following it. _______________________________________________ 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

_______________________________________________ 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

Devin Silvia

14 Jun 14 Jun

1:33 a.m.

Hi All, I've been playing quite a bit with the changes that are in the yt-refactor fork and I've been having a fair bit of success. My most recent success can be seen here: http://casa.colorado.edu/~silvia/enzo_movies/most_opaque_time_series_Density... Overall, I'm a fan and using the new features has been fairly straight forward. -Devin On Wed, Jun 13, 2012 at 2:01 PM, Matthew Turk wrote:

...

Chris, is this an ART dataset rendering? I love it. Great work. And, did you note on your machine what the load went up to? Did it scale with the numebr of cores okay?

On Wed, Jun 13, 2012 at 3:47 PM, Christopher Moody wrote:

...
Works for me!

On one core, no_ghost=True, kd-Tree took 5 seconds, ray casting 56 seconds. Impressive.

chris

On Wed, Jun 13, 2012 at 10:45 AM, Matthew Turk wrote:

...
Also, for what it's worth, John, Sam and I have been working on creating a movie sequence with this in HiDef for a display project. Once that's done we're going to be posting the movie, the original scripts, and potentially even a screencast of how one goes about doing a complex volume rendering.

On Wed, Jun 13, 2012 at 12:34 PM, Sam Skillman wrote:

...
Hi all,

Here's a sample script that exposes a few of the new features such as opacity and the map_to_colormap function. http://paste.yt-project.org/show/2458/

I'll see if I can get some more scripts written in a portable way.

Cheers, Sam

On Wed, Jun 13, 2012 at 10:22 AM, John ZuHone wrote:

...
Matt,

I'll give it a whirl... it may take a day or two.

John Z

On Jun 13, 2012, at 11:12 AM, Matthew Turk wrote:

...
Sam and I chatted, and we'd like to request three people test this and if they all agree, we can accept it.

Can three people give it a go?

---------- Forwarded message ---------- From: Matthew Turk Date: Wed, Jun 13, 2012 at 11:12 AM Subject: [yt_analysis/yt] Volume Rendering Refactor (pull request #168) To: yt@enzotools.org

A new pull request has been opened by Matthew Turk.

MatthewTurk/yt-refactor has changes to be pulled into yt_analysis/yt.

https://bitbucket.org/yt_analysis/yt/pull-request/168/volume-rendering-refac...

Title: Volume Rendering Refactor

This includes all of the changes to the volume rendering system that were discussed here:

http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-June/002039.h...

The main user-facing changes that could cause problems:

1) Cython 0.16 is now required. 2) Off-axis projections no longer interpolate.

Changes to be pulled:

-- This is an issue notification from bitbucket.org. You are receiving this either because you are the participating in a pull request, or you are following it. _______________________________________________ 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

_______________________________________________ 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

-- "I'm here to fight for truth, and justice, and the American way."

Christopher Moody

2:14 a.m.

Hi Matt, Yep, this is an ART dataset. I had a node running with 12 (24 with HT) cores at NASA Pleiades. It didn't go above 4% (=1/24) usage, which indicates means it likely did not use more than one core (but I didn't tell it to). If there's a parallel version of the script I can try it out tonight, and see the scaling. chris On Wed, Jun 13, 2012 at 1:01 PM, Matthew Turk wrote:

...

Chris, is this an ART dataset rendering? I love it. Great work. And, did you note on your machine what the load went up to? Did it scale with the numebr of cores okay?

On Wed, Jun 13, 2012 at 3:47 PM, Christopher Moody wrote:

...
Works for me!

On one core, no_ghost=True, kd-Tree took 5 seconds, ray casting 56 seconds. Impressive.

chris

On Wed, Jun 13, 2012 at 10:45 AM, Matthew Turk wrote:

...
Also, for what it's worth, John, Sam and I have been working on creating a movie sequence with this in HiDef for a display project. Once that's done we're going to be posting the movie, the original scripts, and potentially even a screencast of how one goes about doing a complex volume rendering.

On Wed, Jun 13, 2012 at 12:34 PM, Sam Skillman wrote:

...
Hi all,

Here's a sample script that exposes a few of the new features such as opacity and the map_to_colormap function. http://paste.yt-project.org/show/2458/

I'll see if I can get some more scripts written in a portable way.

Cheers, Sam

On Wed, Jun 13, 2012 at 10:22 AM, John ZuHone wrote:

...
Matt,

I'll give it a whirl... it may take a day or two.

John Z

On Jun 13, 2012, at 11:12 AM, Matthew Turk wrote:

...
Sam and I chatted, and we'd like to request three people test this and if they all agree, we can accept it.

Can three people give it a go?

---------- Forwarded message ---------- From: Matthew Turk Date: Wed, Jun 13, 2012 at 11:12 AM Subject: [yt_analysis/yt] Volume Rendering Refactor (pull request #168) To: yt@enzotools.org

A new pull request has been opened by Matthew Turk.

MatthewTurk/yt-refactor has changes to be pulled into yt_analysis/yt.

https://bitbucket.org/yt_analysis/yt/pull-request/168/volume-rendering-refac...

Title: Volume Rendering Refactor

This includes all of the changes to the volume rendering system that were discussed here:

http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-June/002039.h...

The main user-facing changes that could cause problems:

1) Cython 0.16 is now required. 2) Off-axis projections no longer interpolate.

Changes to be pulled:

-- This is an issue notification from bitbucket.org. You are receiving this either because you are the participating in a pull request, or you are following it. _______________________________________________ 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

_______________________________________________ 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

Sam Skillman

2:36 a.m.

Hi Chris, Hmm, maybe Pleiades sets OMP_NUM_THREADS=1 by default. Can you check: echo $OMP_NUM_THREADS If it is either unset or set to 1, could you give it a shot with export OMP_NUM_THREADS=12? The HT shouldn't help too much. Best, Sam On Wed, Jun 13, 2012 at 8:14 PM, Christopher Moody wrote:

...

Hi Matt, Yep, this is an ART dataset. I had a node running with 12 (24 with HT) cores at NASA Pleiades. It didn't go above 4% (=1/24) usage, which indicates means it likely did not use more than one core (but I didn't tell it to). If there's a parallel version of the script I can try it out tonight, and see the scaling.

chris

...
Chris, is this an ART dataset rendering? I love it. Great work. And, did you note on your machine what the load went up to? Did it scale with the numebr of cores okay?

On Wed, Jun 13, 2012 at 3:47 PM, Christopher Moody wrote:

...
Works for me!

On one core, no_ghost=True, kd-Tree took 5 seconds, ray casting 56 seconds. Impressive.

chris

On Wed, Jun 13, 2012 at 10:45 AM, Matthew Turk wrote:

...
Also, for what it's worth, John, Sam and I have been working on creating a movie sequence with this in HiDef for a display project. Once that's done we're going to be posting the movie, the original scripts, and potentially even a screencast of how one goes about doing a complex volume rendering.

On Wed, Jun 13, 2012 at 12:34 PM, Sam Skillman wrote:

...
Hi all,

Here's a sample script that exposes a few of the new features such as opacity and the map_to_colormap function. http://paste.yt-project.org/show/2458/

I'll see if I can get some more scripts written in a portable way.

Cheers, Sam

On Wed, Jun 13, 2012 at 10:22 AM, John ZuHone wrote:

...
Matt,

I'll give it a whirl... it may take a day or two.

John Z

On Jun 13, 2012, at 11:12 AM, Matthew Turk wrote:

> Sam and I chatted, and we'd like to request three people test this

and

...
> if they all agree, we can accept it. > > Can three people give it a go? > > > ---------- Forwarded message ---------- > From: Matthew Turk > Date: Wed, Jun 13, 2012 at 11:12 AM > Subject: [yt_analysis/yt] Volume Rendering Refactor (pull request #168) > To: yt@enzotools.org > > > A new pull request has been opened by Matthew Turk. > > MatthewTurk/yt-refactor has changes to be pulled into yt_analysis/yt. > > > https://bitbucket.org/yt_analysis/yt/pull-request/168/volume-rendering-refac... > > Title: Volume Rendering Refactor > > This includes all of the changes to the volume rendering system

On Wed, Jun 13, 2012 at 1:01 PM, Matthew Turk wrote: that

...
...
...
...
...
> were discussed here: > > > http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-June/002039.h... > > The main user-facing changes that could cause problems: > > 1) Cython 0.16 is now required. > 2) Off-axis projections no longer interpolate. > > Changes to be pulled: > > > > -- > This is an issue notification from bitbucket.org. > You are receiving this either because you are the participating > in a pull request, or you are following it. > _______________________________________________ > 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

_______________________________________________ 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

yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

Sam Skillman

3:21 a.m.

Hi all, Earlier today Cameron brought up some concerns about removing the behavior of the off-axis-projection using interpolated data from vertex-centered data. If you recall from earlier discussions on the impact of the new threading + opaque renderings + refactoring, one of the things we've done is switch from the interpolation to using the raw values within each cell a given ray traverses for use in the off-axis-projection. This is mathematically a more accurate representation of the data, but can sometimes lead to blocky looking images. What I've done is go through and add an optional interpolated=(False/True) argument to the off_axis_projection call, where the default is False. Additionally, I've set this up so that it now wraps the ProjectionCamera class, which is derived from the Camera class, so it has things like .rotate, etc. Just for reference, I'm including below both timings, results, and example images, made using this script: http://paste.yt-project.org/show/2462/ Here is the output: Comparison of Raw vs Interpolated Density Raw -- Time: 1.173431e+00 seconds, min: 8.046089e-06, max: 1.177795e-02 Int -- Time: 6.393837e+00 seconds, min: 8.322453e-06, max: 1.113421e-02 Density-weighted Temperature Raw -- Time: 8.513930e-01 seconds, min: 4.681834e+00, max: 1.237399e+07 Int -- Time: 8.450805e+00 seconds, min: 1.105447e+01, max: 1.213922e+07 The main difference that you see here is that the interpolated doesn't capture the minima and maxima as well, which makes sense since it is interpolating the data and smoothing out the peaks. Note that the Interpolated use the no_ghost=False option, which brings it much closer to the Raw values. This highlights the improvement off the off_axis_projection for quantitative results, as it is both more accurate and faster. This is also a fairly small dataset. Improvements for larger simulations are even more impressive. You can see the diff between this changeset and Matt's changeset that is currently the PR changeset here: https://bitbucket.org/samskillman/yt-refactor/compare/..MatthewTurk/yt-refac... Please take a look. I'm hopeful that with these changes pulled into Matt's PR, we should be closer to this being accepted. Along with these changes come some updated docs, as well as getting rid of those pesky print statements that Britton saw. Cheers, Sam On Wed, Jun 13, 2012 at 8:36 PM, Sam Skillman wrote:

...

Hi Chris,

Hmm, maybe Pleiades sets OMP_NUM_THREADS=1 by default. Can you check: echo $OMP_NUM_THREADS

If it is either unset or set to 1, could you give it a shot with export OMP_NUM_THREADS=12? The HT shouldn't help too much.

Best, Sam

On Wed, Jun 13, 2012 at 8:14 PM, Christopher Moody wrote:

...
Hi Matt, Yep, this is an ART dataset. I had a node running with 12 (24 with HT) cores at NASA Pleiades. It didn't go above 4% (=1/24) usage, which indicates means it likely did not use more than one core (but I didn't tell it to). If there's a parallel version of the script I can try it out tonight, and see the scaling.

chris

...
Chris, is this an ART dataset rendering? I love it. Great work. And, did you note on your machine what the load went up to? Did it scale with the numebr of cores okay?

On Wed, Jun 13, 2012 at 3:47 PM, Christopher Moody wrote:

...
Works for me!

On one core, no_ghost=True, kd-Tree took 5 seconds, ray casting 56 seconds. Impressive.

chris

On Wed, Jun 13, 2012 at 10:45 AM, Matthew Turk wrote:

...
Also, for what it's worth, John, Sam and I have been working on creating a movie sequence with this in HiDef for a display project. Once that's done we're going to be posting the movie, the original scripts, and potentially even a screencast of how one goes about doing a complex volume rendering.

On Wed, Jun 13, 2012 at 12:34 PM, Sam Skillman wrote:

...
Hi all,

Here's a sample script that exposes a few of the new features such as opacity and the map_to_colormap function. http://paste.yt-project.org/show/2458/

I'll see if I can get some more scripts written in a portable way.

Cheers, Sam

On Wed, Jun 13, 2012 at 10:22 AM, John ZuHone wrote: > > Matt, > > I'll give it a whirl... it may take a day or two. > > John Z > > On Jun 13, 2012, at 11:12 AM, Matthew Turk wrote: > > > Sam and I chatted, and we'd like to request three people test

...
...
...
...
> > if they all agree, we can accept it. > > > > Can three people give it a go? > > > > > > ---------- Forwarded message ---------- > > From: Matthew Turk > > Date: Wed, Jun 13, 2012 at 11:12 AM > > Subject: [yt_analysis/yt] Volume Rendering Refactor (pull request #168) > > To: yt@enzotools.org > > > > > > A new pull request has been opened by Matthew Turk. > > > > MatthewTurk/yt-refactor has changes to be pulled into yt_analysis/yt. > > > > > > https://bitbucket.org/yt_analysis/yt/pull-request/168/volume-rendering-refac... > > > > Title: Volume Rendering Refactor > > > > This includes all of the changes to the volume rendering system

On Wed, Jun 13, 2012 at 1:01 PM, Matthew Turk wrote: this and that

...
...
...
...
> > were discussed here: > > > > > > http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-June/002039.h... > > > > The main user-facing changes that could cause problems: > > > > 1) Cython 0.16 is now required. > > 2) Off-axis projections no longer interpolate. > > > > Changes to be pulled: > > > > > > > > -- > > This is an issue notification from bitbucket.org. > > You are receiving this either because you are the participating > > in a pull request, or you are following it. > > _______________________________________________ > > 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

_______________________________________________ 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

yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

Matthew Turk

3:40 a.m.

Hi Sam, Thanks for doing this. I'll update my PR shortly; this needs to be a part of it before it's accepted. This has also highlighted a part of the process that I think we're all trying to do -- peer review not just of the quantitative changes to the code (i.e., breaking tests!) but also qualitative. In this case, Cameron saw something that would change functionality, and he stood up for keeping the ability to retain backwards compatibility. I think this is a valid point and a valuable position; in the case of the off-axis projection, when I initially made this change it was because I felt this was truer to the underlying data. (There are extremely few places in the yt codebase where it interpolates.) However, retaining a solid foundation for users is also extremely important. The growth of yt over the last couple years has put us in a sticky situation; we've developed a community, but it's a community that relies on functionality not changing without good reason, and more importantly that relies on keeping a solid basis for repeatable analysis and consistent results. This change broke that -- even though it's arguably an improvement of the solution -- and the old method was no longer available. I'm really happy that this system has worked; while I was initially -1 on restoring interpolation, Cameron swayed me in IRC by bringing up this remarkably important point. I think turning the default to non-interpolated but retaining the interpolated mode are both the right decisions, and I'm +1. And more than that, I'm glad this all happened before the PR was accepted. So thank you, Sam, and Cameron, for restoring the old functionality. I'm excited about moving forward. The results in this thread have really gotten me excited about the success of this new set of changes. -Matt On Jun 13, 2012 11:26 PM, "Sam Skillman" wrote:

...

Hi all,

Earlier today Cameron brought up some concerns about removing the behavior of the off-axis-projection using interpolated data from vertex-centered data. If you recall from earlier discussions on the impact of the new threading + opaque renderings + refactoring, one of the things we've done is switch from the interpolation to using the raw values within each cell a given ray traverses for use in the off-axis-projection. This is mathematically a more accurate representation of the data, but can sometimes lead to blocky looking images.

What I've done is go through and add an optional interpolated=(False/True) argument to the off_axis_projection call, where the default is False. Additionally, I've set this up so that it now wraps the ProjectionCamera class, which is derived from the Camera class, so it has things like .rotate, etc.

Just for reference, I'm including below both timings, results, and example images, made using this script: http://paste.yt-project.org/show/2462/

Here is the output: Comparison of Raw vs Interpolated Density Raw -- Time: 1.173431e+00 seconds, min: 8.046089e-06, max: 1.177795e-02 Int -- Time: 6.393837e+00 seconds, min: 8.322453e-06, max: 1.113421e-02

Density-weighted Temperature Raw -- Time: 8.513930e-01 seconds, min: 4.681834e+00, max: 1.237399e+07 Int -- Time: 8.450805e+00 seconds, min: 1.105447e+01, max: 1.213922e+07

The main difference that you see here is that the interpolated doesn't capture the minima and maxima as well, which makes sense since it is interpolating the data and smoothing out the peaks. Note that the Interpolated use the no_ghost=False option, which brings it much closer to the Raw values. This highlights the improvement off the off_axis_projection for quantitative results, as it is both more accurate and faster. This is also a fairly small dataset. Improvements for larger simulations are even more impressive.

You can see the diff between this changeset and Matt's changeset that is currently the PR changeset here:

https://bitbucket.org/samskillman/yt-refactor/compare/..MatthewTurk/yt-refac...

Please take a look. I'm hopeful that with these changes pulled into Matt's PR, we should be closer to this being accepted.

Along with these changes come some updated docs, as well as getting rid of those pesky print statements that Britton saw.

Cheers, Sam

On Wed, Jun 13, 2012 at 8:36 PM, Sam Skillman wrote:

...
Hi Chris,

Hmm, maybe Pleiades sets OMP_NUM_THREADS=1 by default. Can you check: echo $OMP_NUM_THREADS

If it is either unset or set to 1, could you give it a shot with export OMP_NUM_THREADS=12? The HT shouldn't help too much.

Best, Sam

On Wed, Jun 13, 2012 at 8:14 PM, Christopher Moody wrote:

...
Hi Matt, Yep, this is an ART dataset. I had a node running with 12 (24 with HT) cores at NASA Pleiades. It didn't go above 4% (=1/24) usage, which indicates means it likely did not use more than one core (but I didn't tell it to). If there's a parallel version of the script I can try it out tonight, and see the scaling.

chris

...
Chris, is this an ART dataset rendering? I love it. Great work. And, did you note on your machine what the load went up to? Did it scale with the numebr of cores okay?

On Wed, Jun 13, 2012 at 3:47 PM, Christopher Moody wrote:

...
Works for me!

On one core, no_ghost=True, kd-Tree took 5 seconds, ray casting 56 seconds. Impressive.

chris

On Wed, Jun 13, 2012 at 10:45 AM, Matthew Turk wrote:

...
Also, for what it's worth, John, Sam and I have been working on creating a movie sequence with this in HiDef for a display project. Once that's done we're going to be posting the movie, the original scripts, and potentially even a screencast of how one goes about doing a complex volume rendering.

On Wed, Jun 13, 2012 at 12:34 PM, Sam Skillman < samskillman@gmail.com> wrote: > Hi all, > > Here's a sample script that exposes a few of the new features such as > opacity and the map_to_colormap function. > http://paste.yt-project.org/show/2458/ > > I'll see if I can get some more scripts written in a portable way. > > Cheers, > Sam > > On Wed, Jun 13, 2012 at 10:22 AM, John ZuHone wrote: >> >> Matt, >> >> I'll give it a whirl... it may take a day or two. >> >> John Z >> >> On Jun 13, 2012, at 11:12 AM, Matthew Turk wrote: >> >> > Sam and I chatted, and we'd like to request three people test

...
...
...
>> > if they all agree, we can accept it. >> > >> > Can three people give it a go? >> > >> > >> > ---------- Forwarded message ---------- >> > From: Matthew Turk >> > Date: Wed, Jun 13, 2012 at 11:12 AM >> > Subject: [yt_analysis/yt] Volume Rendering Refactor (pull request #168) >> > To: yt@enzotools.org >> > >> > >> > A new pull request has been opened by Matthew Turk. >> > >> > MatthewTurk/yt-refactor has changes to be pulled into yt_analysis/yt. >> > >> > >> > https://bitbucket.org/yt_analysis/yt/pull-request/168/volume-rendering-refac... >> > >> > Title: Volume Rendering Refactor >> > >> > This includes all of the changes to the volume rendering system

On Wed, Jun 13, 2012 at 1:01 PM, Matthew Turk wrote: this and that

...
...
...
>> > were discussed here: >> > >> > >> > http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-June/002039.h... >> > >> > The main user-facing changes that could cause problems: >> > >> > 1) Cython 0.16 is now required. >> > 2) Off-axis projections no longer interpolate. >> > >> > Changes to be pulled: >> > >> > >> > >> > -- >> > This is an issue notification from bitbucket.org. >> > You are receiving this either because you are the participating >> > in a pull request, or you are following it. >> > _______________________________________________ >> > 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 > _______________________________________________ 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

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

Elizabeth Tasker

3:57 a.m.

New subject: backwards compatibility issues

Hi Matt, I'm springing off this email, but it's a separate point, so I gave it a new heading. Regarding breaking of backwards compatibility, I'm definitely +1 for avoiding it. That said, I also appreciate that changes are necessary to make yt more flexible to its ever expanding user base. A few of my scripts do use some of the lower functionality of yt (e.g. accessing an the parents of an individual cell etc) that I could see might change with an overhaul of structure, invisible to most cookbook-usage. I actually wouldn't issue more than a passing grumble, providing it was super clear how to fix my code for the new set-up. (So easy that I don't need to re-understand my long and (undoubtedly) poorly annotated script to do it). How about a spin-off page from the FAQ for "I updated and my code no longer works, WTH?". This could show an example of new call *and* the old call (so it's easy to see how to update your script). An example of what might be in there would be the call to EnzoSimulation which has undergone a number of revisions over the years. I don't think this would address Cameron's issue, which I think it about the change in the result rather than the usage, but it might be good for the above related problem. Elizabeth On Jun 14, 2012, at 12:40 PM, Matthew Turk wrote:

...

Hi Sam,

Thanks for doing this.

I'll update my PR shortly; this needs to be a part of it before it's accepted.

This has also highlighted a part of the process that I think we're all trying to do -- peer review not just of the quantitative changes to the code (i.e., breaking tests!) but also qualitative. In this case, Cameron saw something that would change functionality, and he stood up for keeping the ability to retain backwards compatibility. I think this is a valid point and a valuable position; in the case of the off-axis projection, when I initially made this change it was because I felt this was truer to the underlying data. (There are extremely few places in the yt codebase where it interpolates.)

However, retaining a solid foundation for users is also extremely important. The growth of yt over the last couple years has put us in a sticky situation; we've developed a community, but it's a community that relies on functionality not changing without good reason, and more importantly that relies on keeping a solid basis for repeatable analysis and consistent results. This change broke that -- even though it's arguably an improvement of the solution -- and the old method was no longer available.

I'm really happy that this system has worked; while I was initially -1 on restoring interpolation, Cameron swayed me in IRC by bringing up this remarkably important point. I think turning the default to non-interpolated but retaining the interpolated mode are both the right decisions, and I'm +1. And more than that, I'm glad this all happened before the PR was accepted.

So thank you, Sam, and Cameron, for restoring the old functionality. I'm excited about moving forward. The results in this thread have really gotten me excited about the success of this new set of changes.

-Matt

On Jun 13, 2012 11:26 PM, "Sam Skillman" wrote: Hi all,

Earlier today Cameron brought up some concerns about removing the behavior of the off-axis-projection using interpolated data from vertex-centered data. If you recall from earlier discussions on the impact of the new threading + opaque renderings + refactoring, one of the things we've done is switch from the interpolation to using the raw values within each cell a given ray traverses for use in the off-axis-projection. This is mathematically a more accurate representation of the data, but can sometimes lead to blocky looking images.

What I've done is go through and add an optional interpolated=(False/True) argument to the off_axis_projection call, where the default is False. Additionally, I've set this up so that it now wraps the ProjectionCamera class, which is derived from the Camera class, so it has things like .rotate, etc.

Just for reference, I'm including below both timings, results, and example images, made using this script: http://paste.yt-project.org/show/2462/

Here is the output: Comparison of Raw vs Interpolated Density Raw -- Time: 1.173431e+00 seconds, min: 8.046089e-06, max: 1.177795e-02 Int -- Time: 6.393837e+00 seconds, min: 8.322453e-06, max: 1.113421e-02

Density-weighted Temperature Raw -- Time: 8.513930e-01 seconds, min: 4.681834e+00, max: 1.237399e+07 Int -- Time: 8.450805e+00 seconds, min: 1.105447e+01, max: 1.213922e+07

The main difference that you see here is that the interpolated doesn't capture the minima and maxima as well, which makes sense since it is interpolating the data and smoothing out the peaks. Note that the Interpolated use the no_ghost=False option, which brings it much closer to the Raw values. This highlights the improvement off the off_axis_projection for quantitative results, as it is both more accurate and faster. This is also a fairly small dataset. Improvements for larger simulations are even more impressive.

You can see the diff between this changeset and Matt's changeset that is currently the PR changeset here: https://bitbucket.org/samskillman/yt-refactor/compare/..MatthewTurk/yt-refac...

Please take a look. I'm hopeful that with these changes pulled into Matt's PR, we should be closer to this being accepted.

Along with these changes come some updated docs, as well as getting rid of those pesky print statements that Britton saw.

Cheers, Sam

On Wed, Jun 13, 2012 at 8:36 PM, Sam Skillman wrote: Hi Chris,

Hmm, maybe Pleiades sets OMP_NUM_THREADS=1 by default. Can you check: echo $OMP_NUM_THREADS

If it is either unset or set to 1, could you give it a shot with export OMP_NUM_THREADS=12? The HT shouldn't help too much.

Best, Sam

On Wed, Jun 13, 2012 at 8:14 PM, Christopher Moody wrote: Hi Matt, Yep, this is an ART dataset. I had a node running with 12 (24 with HT) cores at NASA Pleiades. It didn't go above 4% (=1/24) usage, which indicates means it likely did not use more than one core (but I didn't tell it to). If there's a parallel version of the script I can try it out tonight, and see the scaling.

chris

On Wed, Jun 13, 2012 at 1:01 PM, Matthew Turk wrote:

...
Chris, is this an ART dataset rendering? I love it. Great work. And, did you note on your machine what the load went up to? Did it scale with the numebr of cores okay?

On Wed, Jun 13, 2012 at 3:47 PM, Christopher Moody wrote:

...
Works for me!

On one core, no_ghost=True, kd-Tree took 5 seconds, ray casting 56 seconds. Impressive.

chris

On Wed, Jun 13, 2012 at 10:45 AM, Matthew Turk wrote:

...
Also, for what it's worth, John, Sam and I have been working on creating a movie sequence with this in HiDef for a display project. Once that's done we're going to be posting the movie, the original scripts, and potentially even a screencast of how one goes about doing a complex volume rendering.

On Wed, Jun 13, 2012 at 12:34 PM, Sam Skillman wrote:

...
Hi all,

Here's a sample script that exposes a few of the new features such as opacity and the map_to_colormap function. http://paste.yt-project.org/show/2458/

I'll see if I can get some more scripts written in a portable way.

Cheers, Sam

On Wed, Jun 13, 2012 at 10:22 AM, John ZuHone wrote:

...
Matt,

I'll give it a whirl... it may take a day or two.

John Z

On Jun 13, 2012, at 11:12 AM, Matthew Turk wrote:

> Sam and I chatted, and we'd like to request three people test this and > if they all agree, we can accept it. > > Can three people give it a go? > > > ---------- Forwarded message ---------- > From: Matthew Turk > Date: Wed, Jun 13, 2012 at 11:12 AM > Subject: [yt_analysis/yt] Volume Rendering Refactor (pull request #168) > To: yt@enzotools.org > > > A new pull request has been opened by Matthew Turk. > > MatthewTurk/yt-refactor has changes to be pulled into yt_analysis/yt. > > > https://bitbucket.org/yt_analysis/yt/pull-request/168/volume-rendering-refac... > > Title: Volume Rendering Refactor > > This includes all of the changes to the volume rendering system that > were discussed here: > > > http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-June/002039.h... > > The main user-facing changes that could cause problems: > > 1) Cython 0.16 is now required. > 2) Off-axis projections no longer interpolate. > > Changes to be pulled: > > > > -- > This is an issue notification from bitbucket.org. > You are receiving this either because you are the participating > in a pull request, or you are following it. > _______________________________________________ > 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

_______________________________________________ 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

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

Matthew Turk

9:24 p.m.

New subject: backwards compatibility issues

Hi Elizabeth, (I've snipped the previous conversation out of this.) Thanks for your thoughtful email. I'm pleased we have a community large enough now that we have to think about these things, and also pleased that the community is engaged enough that talking about them isn't so bad. On Wed, Jun 13, 2012 at 11:57 PM, Elizabeth Tasker wrote:

...

Hi Matt,

I'm springing off this email, but it's a separate point, so I gave it a new heading.

Regarding breaking of backwards compatibility, I'm definitely +1 for avoiding it. That said, I also appreciate that changes are necessary to make yt more flexible to its ever expanding user base.

A few of my scripts do use some of the lower functionality of yt (e.g. accessing an the parents of an individual cell etc) that I could see might change with an overhaul of structure, invisible to most cookbook-usage. I actually wouldn't issue more than a passing grumble, providing it was super clear how to fix my code for the new set-up. (So easy that I don't need to re-understand my long and (undoubtedly) poorly annotated script to do it).

I suppose this is an interesting point. There are the obvious high-level routines in yt -- plot collection stuff, data objects, derived quantities -- and then the low-level access, which ti sounds like you've been using. Changing high-level functionality should be done very carefully with ample warning. (And I think that's where the interpolation thing went awry, because it did change high-level functionality, but where the volume rendering went okay because it's low-level and preserving high-level access.) What we don't have right now is a process for deprecating, and notifying.

...

How about a spin-off page from the FAQ for "I updated and my code no longer works, WTH?". This could show an example of new call *and* the old call (so it's easy to see how to update your script). An example of what might be in there would be the call to EnzoSimulation which has undergone a number of revisions over the years.

This is a very good point. In fact, having a deprecation page is extremely useful, and something we haven't done a very good job of in the past; mailing list messages have largely served this purpose. This should be a mandated part of any release. Do you think we need to notify between releases?

...

I don't think this would address Cameron's issue, which I think it about the change in the result rather than the usage, but it might be good for the above related problem.

We could also make it a part of it -- there could be two sections. Changes in functionality and changes in interface. -Matt

...

Elizabeth

Sam Skillman

4 a.m.

Hi Matt, Thanks for the kind words. I'm glad that I'm in a community of developers who 1) care about results, 2) Have buy-in because it's what we use to get work done, 3) are cool people! Chris -- I think the delay between the building and the casting is when the data is loaded into the kdtree bricks. Both the building of the kdtree and the reading of the data are serial processes. So the relavent speedup is the one during the ray-casting. One other thing to note is that if you are doing camera movements, the data should all stay in memory so these serial costs should go away. Anyways, thanks for testing! That's some great performance! Cheers, Sam On Wed, Jun 13, 2012 at 9:40 PM, Matthew Turk wrote:

...

Hi Sam,

Thanks for doing this.

I'll update my PR shortly; this needs to be a part of it before it's accepted.

This has also highlighted a part of the process that I think we're all trying to do -- peer review not just of the quantitative changes to the code (i.e., breaking tests!) but also qualitative. In this case, Cameron saw something that would change functionality, and he stood up for keeping the ability to retain backwards compatibility. I think this is a valid point and a valuable position; in the case of the off-axis projection, when I initially made this change it was because I felt this was truer to the underlying data. (There are extremely few places in the yt codebase where it interpolates.)

However, retaining a solid foundation for users is also extremely important. The growth of yt over the last couple years has put us in a sticky situation; we've developed a community, but it's a community that relies on functionality not changing without good reason, and more importantly that relies on keeping a solid basis for repeatable analysis and consistent results. This change broke that -- even though it's arguably an improvement of the solution -- and the old method was no longer available.

I'm really happy that this system has worked; while I was initially -1 on restoring interpolation, Cameron swayed me in IRC by bringing up this remarkably important point. I think turning the default to non-interpolated but retaining the interpolated mode are both the right decisions, and I'm +1. And more than that, I'm glad this all happened before the PR was accepted.

So thank you, Sam, and Cameron, for restoring the old functionality. I'm excited about moving forward. The results in this thread have really gotten me excited about the success of this new set of changes.

-Matt On Jun 13, 2012 11:26 PM, "Sam Skillman" wrote:

...
Hi all,

Earlier today Cameron brought up some concerns about removing the behavior of the off-axis-projection using interpolated data from vertex-centered data. If you recall from earlier discussions on the impact of the new threading + opaque renderings + refactoring, one of the things we've done is switch from the interpolation to using the raw values within each cell a given ray traverses for use in the off-axis-projection. This is mathematically a more accurate representation of the data, but can sometimes lead to blocky looking images.

What I've done is go through and add an optional interpolated=(False/True) argument to the off_axis_projection call, where the default is False. Additionally, I've set this up so that it now wraps the ProjectionCamera class, which is derived from the Camera class, so it has things like .rotate, etc.

Just for reference, I'm including below both timings, results, and example images, made using this script: http://paste.yt-project.org/show/2462/

Here is the output: Comparison of Raw vs Interpolated Density Raw -- Time: 1.173431e+00 seconds, min: 8.046089e-06, max: 1.177795e-02 Int -- Time: 6.393837e+00 seconds, min: 8.322453e-06, max: 1.113421e-02

Density-weighted Temperature Raw -- Time: 8.513930e-01 seconds, min: 4.681834e+00, max: 1.237399e+07 Int -- Time: 8.450805e+00 seconds, min: 1.105447e+01, max: 1.213922e+07

The main difference that you see here is that the interpolated doesn't capture the minima and maxima as well, which makes sense since it is interpolating the data and smoothing out the peaks. Note that the Interpolated use the no_ghost=False option, which brings it much closer to the Raw values. This highlights the improvement off the off_axis_projection for quantitative results, as it is both more accurate and faster. This is also a fairly small dataset. Improvements for larger simulations are even more impressive.

You can see the diff between this changeset and Matt's changeset that is currently the PR changeset here:

https://bitbucket.org/samskillman/yt-refactor/compare/..MatthewTurk/yt-refac...

Please take a look. I'm hopeful that with these changes pulled into Matt's PR, we should be closer to this being accepted.

Along with these changes come some updated docs, as well as getting rid of those pesky print statements that Britton saw.

Cheers, Sam

On Wed, Jun 13, 2012 at 8:36 PM, Sam Skillman wrote:

...
Hi Chris,

Hmm, maybe Pleiades sets OMP_NUM_THREADS=1 by default. Can you check: echo $OMP_NUM_THREADS

If it is either unset or set to 1, could you give it a shot with export OMP_NUM_THREADS=12? The HT shouldn't help too much.

Best, Sam

On Wed, Jun 13, 2012 at 8:14 PM, Christopher Moody wrote:

...
Hi Matt, Yep, this is an ART dataset. I had a node running with 12 (24 with HT) cores at NASA Pleiades. It didn't go above 4% (=1/24) usage, which indicates means it likely did not use more than one core (but I didn't tell it to). If there's a parallel version of the script I can try it out tonight, and see the scaling.

chris

...
Chris, is this an ART dataset rendering? I love it. Great work. And, did you note on your machine what the load went up to? Did it scale with the numebr of cores okay?

On Wed, Jun 13, 2012 at 3:47 PM, Christopher Moody wrote:

...
Works for me!

On one core, no_ghost=True, kd-Tree took 5 seconds, ray casting 56 seconds. Impressive.

chris

On Wed, Jun 13, 2012 at 10:45 AM, Matthew Turk < matthewturk@gmail.com> wrote: > Also, for what it's worth, John, Sam and I have been working on > creating a movie sequence with this in HiDef for a display project. > Once that's done we're going to be posting the movie, the original > scripts, and potentially even a screencast of how one goes about doing > a complex volume rendering. > > On Wed, Jun 13, 2012 at 12:34 PM, Sam Skillman < samskillman@gmail.com> wrote: >> Hi all, >> >> Here's a sample script that exposes a few of the new features such as >> opacity and the map_to_colormap function. >> http://paste.yt-project.org/show/2458/ >> >> I'll see if I can get some more scripts written in a portable way. >> >> Cheers, >> Sam >> >> On Wed, Jun 13, 2012 at 10:22 AM, John ZuHone wrote: >>> >>> Matt, >>> >>> I'll give it a whirl... it may take a day or two. >>> >>> John Z >>> >>> On Jun 13, 2012, at 11:12 AM, Matthew Turk wrote: >>> >>> > Sam and I chatted, and we'd like to request three people test

...
...
>>> > if they all agree, we can accept it. >>> > >>> > Can three people give it a go? >>> > >>> > >>> > ---------- Forwarded message ---------- >>> > From: Matthew Turk >>> > Date: Wed, Jun 13, 2012 at 11:12 AM >>> > Subject: [yt_analysis/yt] Volume Rendering Refactor (pull request #168) >>> > To: yt@enzotools.org >>> > >>> > >>> > A new pull request has been opened by Matthew Turk. >>> > >>> > MatthewTurk/yt-refactor has changes to be pulled into yt_analysis/yt. >>> > >>> > >>> > https://bitbucket.org/yt_analysis/yt/pull-request/168/volume-rendering-refac... >>> > >>> > Title: Volume Rendering Refactor >>> > >>> > This includes all of the changes to the volume rendering system

On Wed, Jun 13, 2012 at 1:01 PM, Matthew Turk wrote: this and that

...
...
>>> > were discussed here: >>> > >>> > >>> > http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-June/002039.h... >>> > >>> > The main user-facing changes that could cause problems: >>> > >>> > 1) Cython 0.16 is now required. >>> > 2) Off-axis projections no longer interpolate. >>> > >>> > Changes to be pulled: >>> > >>> > >>> > >>> > -- >>> > This is an issue notification from bitbucket.org. >>> > You are receiving this either because you are the participating >>> > in a pull request, or you are following it. >>> > _______________________________________________ >>> > 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 >> > _______________________________________________ > 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

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

Matthew Turk

15 Jun 15 Jun

3:43 p.m.

Hi all, So we've updated the PR a couple times now, and I think we're about set. Does anyone have any other comments? -Matt On Thu, Jun 14, 2012 at 12:00 AM, Sam Skillman wrote:

...

Hi Matt,

Thanks for the kind words. I'm glad that I'm in a community of developers who 1) care about results, 2) Have buy-in because it's what we use to get work done, 3) are cool people!

Chris -- I think the delay between the building and the casting is when the data is loaded into the kdtree bricks. Both the building of the kdtree and the reading of the data are serial processes. So the relavent speedup is the one during the ray-casting. One other thing to note is that if you are doing camera movements, the data should all stay in memory so these serial costs should go away. Anyways, thanks for testing! That's some great performance!

Cheers, Sam

On Wed, Jun 13, 2012 at 9:40 PM, Matthew Turk wrote:

...
Hi Sam,

Thanks for doing this.

I'll update my PR shortly; this needs to be a part of it before it's accepted.

This has also highlighted a part of the process that I think we're all trying to do -- peer review not just of the quantitative changes to the code (i.e., breaking tests!) but also qualitative. In this case, Cameron saw something that would change functionality, and he stood up for keeping the ability to retain backwards compatibility. I think this is a valid point and a valuable position; in the case of the off-axis projection, when I initially made this change it was because I felt this was truer to the underlying data. (There are extremely few places in the yt codebase where it interpolates.)

However, retaining a solid foundation for users is also extremely important. The growth of yt over the last couple years has put us in a sticky situation; we've developed a community, but it's a community that relies on functionality not changing without good reason, and more importantly that relies on keeping a solid basis for repeatable analysis and consistent results. This change broke that -- even though it's arguably an improvement of the solution -- and the old method was no longer available.

I'm really happy that this system has worked; while I was initially -1 on restoring interpolation, Cameron swayed me in IRC by bringing up this remarkably important point. I think turning the default to non-interpolated but retaining the interpolated mode are both the right decisions, and I'm +1. And more than that, I'm glad this all happened before the PR was accepted.

So thank you, Sam, and Cameron, for restoring the old functionality. I'm excited about moving forward. The results in this thread have really gotten me excited about the success of this new set of changes.

-Matt

On Jun 13, 2012 11:26 PM, "Sam Skillman" wrote:

...
Hi all,

Earlier today Cameron brought up some concerns about removing the behavior of the off-axis-projection using interpolated data from vertex-centered data. If you recall from earlier discussions on the impact of the new threading + opaque renderings + refactoring, one of the things we've done is switch from the interpolation to using the raw values within each cell a given ray traverses for use in the off-axis-projection. This is mathematically a more accurate representation of the data, but can sometimes lead to blocky looking images.

What I've done is go through and add an optional interpolated=(False/True) argument to the off_axis_projection call, where the default is False. Additionally, I've set this up so that it now wraps the ProjectionCamera class, which is derived from the Camera class, so it has things like .rotate, etc.

Just for reference, I'm including below both timings, results, and example images, made using this script: http://paste.yt-project.org/show/2462/

Here is the output: Comparison of Raw vs Interpolated Density Raw -- Time: 1.173431e+00 seconds, min: 8.046089e-06, max: 1.177795e-02 Int -- Time: 6.393837e+00 seconds, min: 8.322453e-06, max: 1.113421e-02

Density-weighted Temperature Raw -- Time: 8.513930e-01 seconds, min: 4.681834e+00, max: 1.237399e+07 Int -- Time: 8.450805e+00 seconds, min: 1.105447e+01, max: 1.213922e+07

The main difference that you see here is that the interpolated doesn't capture the minima and maxima as well, which makes sense since it is interpolating the data and smoothing out the peaks. Note that the Interpolated use the no_ghost=False option, which brings it much closer to the Raw values. This highlights the improvement off the off_axis_projection for quantitative results, as it is both more accurate and faster. This is also a fairly small dataset. Improvements for larger simulations are even more impressive.

You can see the diff between this changeset and Matt's changeset that is currently the PR changeset here:

https://bitbucket.org/samskillman/yt-refactor/compare/..MatthewTurk/yt-refac...

Please take a look. I'm hopeful that with these changes pulled into Matt's PR, we should be closer to this being accepted.

Along with these changes come some updated docs, as well as getting rid of those pesky print statements that Britton saw.

Cheers, Sam

On Wed, Jun 13, 2012 at 8:36 PM, Sam Skillman wrote:

...
Hi Chris,

Hmm, maybe Pleiades sets OMP_NUM_THREADS=1 by default. Can you check: echo $OMP_NUM_THREADS

If it is either unset or set to 1, could you give it a shot with export OMP_NUM_THREADS=12? The HT shouldn't help too much.

Best, Sam

On Wed, Jun 13, 2012 at 8:14 PM, Christopher Moody wrote:

...
Hi Matt, Yep, this is an ART dataset. I had a node running with 12 (24 with HT) cores at NASA Pleiades. It didn't go above 4% (=1/24) usage, which indicates means it likely did not use more than one core (but I didn't tell it to). If there's a parallel version of the script I can try it out tonight, and see the scaling.

chris

On Wed, Jun 13, 2012 at 1:01 PM, Matthew Turk wrote:

...
Chris, is this an ART dataset rendering? I love it. Great work. And, did you note on your machine what the load went up to? Did it scale with the numebr of cores okay?

On Wed, Jun 13, 2012 at 3:47 PM, Christopher Moody wrote: > Works for me! > > On one core, no_ghost=True, kd-Tree took 5 seconds, ray casting 56 > seconds. Impressive. > > chris > > On Wed, Jun 13, 2012 at 10:45 AM, Matthew Turk > wrote: >> Also, for what it's worth, John, Sam and I have been working on >> creating a movie sequence with this in HiDef for a display project. >> Once that's done we're going to be posting the movie, the original >> scripts, and potentially even a screencast of how one goes about >> doing >> a complex volume rendering. >> >> On Wed, Jun 13, 2012 at 12:34 PM, Sam Skillman >> wrote: >>> Hi all, >>> >>> Here's a sample script that exposes a few of the new features such >>> as >>> opacity and the map_to_colormap function. >>> http://paste.yt-project.org/show/2458/ >>> >>> I'll see if I can get some more scripts written in a portable way. >>> >>> Cheers, >>> Sam >>> >>> On Wed, Jun 13, 2012 at 10:22 AM, John ZuHone >>> wrote: >>>> >>>> Matt, >>>> >>>> I'll give it a whirl... it may take a day or two. >>>> >>>> John Z >>>> >>>> On Jun 13, 2012, at 11:12 AM, Matthew Turk wrote: >>>> >>>> > Sam and I chatted, and we'd like to request three people test >>>> > this and >>>> > if they all agree, we can accept it. >>>> > >>>> > Can three people give it a go? >>>> > >>>> > >>>> > ---------- Forwarded message ---------- >>>> > From: Matthew Turk >>>> > Date: Wed, Jun 13, 2012 at 11:12 AM >>>> > Subject: [yt_analysis/yt] Volume Rendering Refactor (pull >>>> > request #168) >>>> > To: yt@enzotools.org >>>> > >>>> > >>>> > A new pull request has been opened by Matthew Turk. >>>> > >>>> > MatthewTurk/yt-refactor has changes to be pulled into >>>> > yt_analysis/yt. >>>> > >>>> > >>>> > >>>> > https://bitbucket.org/yt_analysis/yt/pull-request/168/volume-rendering-refac... >>>> > >>>> > Title: Volume Rendering Refactor >>>> > >>>> > This includes all of the changes to the volume rendering system >>>> > that >>>> > were discussed here: >>>> > >>>> > >>>> > >>>> > http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-June/002039.h... >>>> > >>>> > The main user-facing changes that could cause problems: >>>> > >>>> > 1) Cython 0.16 is now required. >>>> > 2) Off-axis projections no longer interpolate. >>>> > >>>> > Changes to be pulled: >>>> > >>>> > >>>> > >>>> > -- >>>> > This is an issue notification from bitbucket.org. >>>> > You are receiving this either because you are the participating >>>> > in a pull request, or you are following it. >>>> > _______________________________________________ >>>> > 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 >>> >> _______________________________________________ >> 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

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

_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org

Christopher Moody

14 Jun 14 Jun

3:37 a.m.

Hi Sam, Pleiades had set OMP_NUM_THREADS=1, despite having specifically requested a node with 12 OMP cores (ie, no HT). Nevertheless, the overall efficiency is 14% having run projections continuously for 30 minutes. The kd-tree building doesn't scale, just stays a fixed 5-second cost, but the ray casting goes from ~60s to 8-9 seconds in informal testing, so that part looks like it scales nicely on 12 cores. It looks like there's a lot of deadtime beween the kdtree and ray-casting, and that that eats up most of wall clock time? chris On Wed, Jun 13, 2012 at 7:36 PM, Sam Skillman wrote:

...

Hi Chris,

Hmm, maybe Pleiades sets OMP_NUM_THREADS=1 by default. Can you check: echo $OMP_NUM_THREADS

If it is either unset or set to 1, could you give it a shot with export OMP_NUM_THREADS=12? The HT shouldn't help too much.

Best, Sam

On Wed, Jun 13, 2012 at 8:14 PM, Christopher Moody wrote:

...
Hi Matt, Yep, this is an ART dataset. I had a node running with 12 (24 with HT) cores at NASA Pleiades. It didn't go above 4% (=1/24) usage, which indicates means it likely did not use more than one core (but I didn't tell it to). If there's a parallel version of the script I can try it out tonight, and see the scaling.

chris

On Wed, Jun 13, 2012 at 1:01 PM, Matthew Turk wrote:

...
Chris, is this an ART dataset rendering? I love it. Great work. And, did you note on your machine what the load went up to? Did it scale with the numebr of cores okay?

On Wed, Jun 13, 2012 at 3:47 PM, Christopher Moody wrote:

...
Works for me!

On one core, no_ghost=True, kd-Tree took 5 seconds, ray casting 56 seconds. Impressive.

chris

On Wed, Jun 13, 2012 at 10:45 AM, Matthew Turk wrote:

...
Also, for what it's worth, John, Sam and I have been working on creating a movie sequence with this in HiDef for a display project. Once that's done we're going to be posting the movie, the original scripts, and potentially even a screencast of how one goes about doing a complex volume rendering.

On Wed, Jun 13, 2012 at 12:34 PM, Sam Skillman wrote:

...
Hi all,

Here's a sample script that exposes a few of the new features such as opacity and the map_to_colormap function. http://paste.yt-project.org/show/2458/

I'll see if I can get some more scripts written in a portable way.

Cheers, Sam

On Wed, Jun 13, 2012 at 10:22 AM, John ZuHone wrote: > > Matt, > > I'll give it a whirl... it may take a day or two. > > John Z > > On Jun 13, 2012, at 11:12 AM, Matthew Turk wrote: > > > Sam and I chatted, and we'd like to request three people test this > > and > > if they all agree, we can accept it. > > > > Can three people give it a go? > > > > > > ---------- Forwarded message ---------- > > From: Matthew Turk > > Date: Wed, Jun 13, 2012 at 11:12 AM > > Subject: [yt_analysis/yt] Volume Rendering Refactor (pull request > > #168) > > To: yt@enzotools.org > > > > > > A new pull request has been opened by Matthew Turk. > > > > MatthewTurk/yt-refactor has changes to be pulled into > > yt_analysis/yt. > > > > > > > > https://bitbucket.org/yt_analysis/yt/pull-request/168/volume-rendering-refac... > > > > Title: Volume Rendering Refactor > > > > This includes all of the changes to the volume rendering system > > that > > were discussed here: > > > > > > > > http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-June/002039.h... > > > > The main user-facing changes that could cause problems: > > > > 1) Cython 0.16 is now required. > > 2) Off-axis projections no longer interpolate. > > > > Changes to be pulled: > > > > > > > > -- > > This is an issue notification from bitbucket.org. > > You are receiving this either because you are the participating > > in a pull request, or you are following it. > > _______________________________________________ > > 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

_______________________________________________ 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

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

Sam Skillman

13 Jun 13 Jun

8:03 p.m.

Chris, Wow, that's fantastic. Thanks for sharing! Good to see that everything goes according to plan with presumably an ART dataset. Sam On Wed, Jun 13, 2012 at 1:47 PM, Christopher Moody wrote:

...

Works for me!

On one core, no_ghost=True, kd-Tree took 5 seconds, ray casting 56 seconds. Impressive.

chris

On Wed, Jun 13, 2012 at 10:45 AM, Matthew Turk wrote:

...
Also, for what it's worth, John, Sam and I have been working on creating a movie sequence with this in HiDef for a display project. Once that's done we're going to be posting the movie, the original scripts, and potentially even a screencast of how one goes about doing a complex volume rendering.

On Wed, Jun 13, 2012 at 12:34 PM, Sam Skillman wrote:

...
Hi all,

Here's a sample script that exposes a few of the new features such as opacity and the map_to_colormap function. http://paste.yt-project.org/show/2458/

I'll see if I can get some more scripts written in a portable way.

Cheers, Sam

On Wed, Jun 13, 2012 at 10:22 AM, John ZuHone wrote:

...
Matt,

I'll give it a whirl... it may take a day or two.

John Z

On Jun 13, 2012, at 11:12 AM, Matthew Turk wrote:

...
Sam and I chatted, and we'd like to request three people test this

and

...
...
if they all agree, we can accept it.

Can three people give it a go?

---------- Forwarded message ---------- From: Matthew Turk Date: Wed, Jun 13, 2012 at 11:12 AM Subject: [yt_analysis/yt] Volume Rendering Refactor (pull request #168) To: yt@enzotools.org

A new pull request has been opened by Matthew Turk.

MatthewTurk/yt-refactor has changes to be pulled into yt_analysis/yt.

https://bitbucket.org/yt_analysis/yt/pull-request/168/volume-rendering-refac...

...
Title: Volume Rendering Refactor

This includes all of the changes to the volume rendering system that were discussed here:

http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-June/002039.h...

...
The main user-facing changes that could cause problems:

1) Cython 0.16 is now required. 2) Off-axis projections no longer interpolate.

Changes to be pulled:

-- This is an issue notification from bitbucket.org. You are receiving this either because you are the participating in a pull request, or you are following it. _______________________________________________ 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

_______________________________________________ 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

4332

Age (days ago)

4334

Last active (days ago)

List overview

Download

17 comments

7 participants

participants (7)

Britton Smith
Christopher Moody
Devin Silvia
Elizabeth Tasker
John ZuHone
Matthew Turk
Sam Skillman

Fwd: [yt_analysis/yt] Volume Rendering Refactor (pull request #168)

Christopher Moody

Christopher Moody

Christopher Moody

tags

participants (7)