[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