On 03/21/2016 06:07 PM, Stuart Levy wrote:

Hello yt people,

I'm trying to use MPI on a simple Enzo volume-rendering script, using the latest yt33 dev from bitbucket, and am getting a puzzling behavior. (MPI so as to reduce the load time.)

Symptom: the datatype of the Scene.last_render field is inconsistent: it's YTImageArray when successful, but just plain YTArray when using MPI on the right (wrong) data, and so sc.save() fails. It's easy to work around and save the image another way, but makes me worried that something else is wrong, or that I'm misusing yt.

It is somehow data-dependent. The error doesn't happen when I use the tiny enzo dataset in .../yt-hg/tests/DD0010/moving7_0010, nor the enzo_tiny_cosmology sample (DD0043). But it *does* happen when I use a somewhat-larger-but-not-huge simulation from John Wise - the low-resolution PopIII-star simulation he'd given us last year. A single timestep from it is ~46MB and has only a few dozen grids.

I could post the data somewhere if John Wise would be OK with that - John?

Demo code in: http://paste.yt-project.org/show/6343/ And its output when run under mpirun: http://paste.yt-project.org/show/6344/

The one change to the yt code from 'tip' (bed01b2c838c) is this diagnostic: diff -r bed01b2c838c yt/visualization/volume_rendering/scene.py --- a/yt/visualization/volume_rendering/scene.py Mon Mar 21 14:15:54 2016 -0700 +++ b/yt/visualization/volume_rendering/scene.py Mon Mar 21 18:01:20 2016 -0500 @@ -284,6 +284,7 @@ self.render()

mylog.info("Saving render %s", fname) + print "about to write_png() - Scene.last_render", type(self.last_render), "shape",self.last_render.shape, " => ", dir(self.last_render) self.last_render.write_png(fname, sigma_clip=sigma_clip)

Hi Stuart, I've issued PR 2066 [1] that should fix this. Cheers, Kacper [1] https://bitbucket.org/yt_analysis/yt/pull-requests/2066/

On 03/22/2016 12:32 PM, Stuart Levy wrote:

Thank you, Kacper - that was fast (!), and it works nicely!

For general information -- here's the procedure I used to apply your PR to my local copy. Is this the straightest path to doing that?

Look at your PR page, go to Commits tab, hover over the " 207f56e https://bitbucket.org/xarthisius/yt/commits/207f56eb6859d529ac4f6170720317c6..." commit link and Copy Link Location =>

https://bitbucket.org/xarthisius/yt/commits/207f56eb6859d529ac4f6170720317c6... edit that URL to identify the source repo - yours: https://bitbucket.org/xarthisius/yt

Then from the command line, in my yt source tree, compare your repo with what I've got: hg incoming -G https://bitbucket.org/xarthisius/yt or better, to see just the changes that are related to your new PR commit, hg incoming -G -r 207f56e https://bitbucket.org/xarthisius/yt and indeed they look reasonable, so: hg pull -r 207f56e https://bitbucket.org/xarthisius/yt hg up

and then from the .../src/yt-hg top of the source tree python setup.py develop

Right? It's simple enough to do it this way - just posting this in case there's some even simpler trick that I'm missing.

Yup that's the canonical way to do it. However, "simple enough" is not the term I'd use. That's why we have hg extension to deal with that. You can install it as follows: cd $HOME hg clone https://bitbucket.org/MatthewTurk/hgbb create or edit your $HOME/.hgrc to contain: [extensions] hgbb = $HOME/hgbb/hgbb.py Then you'll be able to do the following in your local clone of yt repo: hg bbpr # will give you list of PRs hg bbpr -p 2066 # would download incoming changes and suggest rev # to update to Cheers, Kacper

On 3/22/16 11:05 AM, Kacper Kowalik wrote:

...

On 03/21/2016 06:07 PM, Stuart Levy wrote:

...

Hello yt people,

I'm trying to use MPI on a simple Enzo volume-rendering script, using the latest yt33 dev from bitbucket, and am getting a puzzling behavior. (MPI so as to reduce the load time.)

Symptom: the datatype of the Scene.last_render field is inconsistent: it's YTImageArray when successful, but just plain YTArray when using MPI on the right (wrong) data, and so sc.save() fails. It's easy to work around and save the image another way, but makes me worried that something else is wrong, or that I'm misusing yt.

It is somehow data-dependent. The error doesn't happen when I use the tiny enzo dataset in .../yt-hg/tests/DD0010/moving7_0010, nor the enzo_tiny_cosmology sample (DD0043). But it *does* happen when I use a somewhat-larger-but-not-huge simulation from John Wise - the low-resolution PopIII-star simulation he'd given us last year. A single timestep from it is ~46MB and has only a few dozen grids.

I could post the data somewhere if John Wise would be OK with that - John?

Demo code in: http://paste.yt-project.org/show/6343/ And its output when run under mpirun: http://paste.yt-project.org/show/6344/

The one change to the yt code from 'tip' (bed01b2c838c) is this diagnostic: diff -r bed01b2c838c yt/visualization/volume_rendering/scene.py --- a/yt/visualization/volume_rendering/scene.py Mon Mar 21 14:15:54 2016 -0700 +++ b/yt/visualization/volume_rendering/scene.py Mon Mar 21 18:01:20 2016 -0500 @@ -284,6 +284,7 @@ self.render()

mylog.info("Saving render %s", fname) + print "about to write_png() - Scene.last_render", type(self.last_render), "shape",self.last_render.shape, " => ", dir(self.last_render) self.last_render.write_png(fname, sigma_clip=sigma_clip)

Hi Stuart, I've issued PR 2066 [1] that should fix this. Cheers, Kacper

[1] https://bitbucket.org/yt_analysis/yt/pull-requests/2066/ _______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

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