[yt-users] yt3.3dev MPI puzzle

Stuart Levy salevy at illinois.edu
Tue Mar 22 10:32:17 PDT 2016


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/207f56eb6859d529ac4f6170720317c69ebdfad7?at=yt>"
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 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/20160322/10e971ac/attachment.html>


More information about the yt-users mailing list