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" commit link and Copy Link Location =>
        https://bitbucket.org/xarthisius/yt/commits/207f56eb6859d529ac4f6170720317c69ebdfad7?at=yt
    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.


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