Hi Matt,<br><br>I just filed this as a bug and included links to nearly identical working and non-working test cases. Let me know if I can help out in any way.<br><br>Britton<br><br><div class="gmail_quote">On Tue, Nov 1, 2011 at 2:53 PM, Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi Sam and Britton,<br>
<br>
This is likely due to the initialization of parallelism. If you<br>
import from mods, the communicator stack sets itself up correctly<br>
initially, which creates the ParallelAnalysisInterface class. At<br>
binding time of methods => class, the parallel state is read from, in<br>
order to do things like calculate which processors execute which task.<br>
<br>
This sounds like a bug, though. If there are "works" and "doesn't<br>
work" scripts I can take a look at it; file it on the issue tracker?<br>
<br>
-Matt<br>
<div><div></div><div class="h5"><br>
On Tue, Nov 1, 2011 at 1:29 PM, Britton Smith <<a href="mailto:brittonsmith@gmail.com">brittonsmith@gmail.com</a>> wrote:<br>
> Just to put some sort of resolution to this, I removed this import line:<br>
> import yt.visualization.volume_rendering.api as vr<br>
> as Sam suggested, allowing the yt.mods line to import the volume renderer<br>
> and such. I then removed all the vr. instances from the script and now<br>
> everything seems to work. It is not clear why, but that seems to have done<br>
> it.<br>
><br>
> On Tue, Nov 1, 2011 at 1:10 PM, Britton Smith <<a href="mailto:brittonsmith@gmail.com">brittonsmith@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Hi Sam,<br>
>><br>
>> Here is the script I'm using for the render:<br>
>> <a href="http://paste.yt-project.org/show/1899/" target="_blank">http://paste.yt-project.org/show/1899/</a><br>
>><br>
>> The command I'm using is:<br>
>> mpirun -np 2 python render_Z.py --parallel<br>
>><br>
>> Also, I seem to be having trouble reading today. Processor zero does have<br>
>> the right number of nonzero pixels, but the image still comes out all black.<br>
>><br>
>> Britton<br>
>><br>
>> On Tue, Nov 1, 2011 at 12:42 PM, Sam Skillman <<a href="mailto:samskillman@gmail.com">samskillman@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> Hi Britton,<br>
>>> Would you mind pasting your script and mpirun command line? Processor 0<br>
>>> should be the only processor that has the entire image at the end. If<br>
>>> anything processor 1 would have half an image, which is why this confuses<br>
>>> me.<br>
>>> Thanks,<br>
>>> Sam<br>
>>> On Tue, Nov 1, 2011 at 10:07 AM, Britton Smith <<a href="mailto:brittonsmith@gmail.com">brittonsmith@gmail.com</a>><br>
>>> wrote:<br>
>>>><br>
>>>> Hi again,<br>
>>>><br>
>>>> Just an update on this. I was incorrect when I stated that the image<br>
>>>> arrays were all zeros in parallel. What actually seems to be the case is<br>
>>>> that with two processors, processor 0 which does the image writing, only has<br>
>>>> a fraction of the total image, which to me looked like all zeros. Processor<br>
>>>> 1 seems to have the entire image, though. It has the same number of<br>
>>>> non-zero cells as the image array does in serial mode.<br>
>>>><br>
>>>> I still don't know what's happening, but I'm looking at it.<br>
>>>><br>
>>>> Britton<br>
>>>><br>
>>>> On Tue, Nov 1, 2011 at 11:55 AM, Britton Smith <<a href="mailto:brittonsmith@gmail.com">brittonsmith@gmail.com</a>><br>
>>>> wrote:<br>
>>>>><br>
>>>>> Hi,<br>
>>>>><br>
>>>>> I'm doing a pretty simple volume render that uses the Camera.snapshot<br>
>>>>> function. In serial, everything seems to be working fine, but when I run in<br>
>>>>> parallel, the image comes out completely blank. I have gone into the<br>
>>>>> snapshot routine and verified that the image array is all zeros for every<br>
>>>>> processor after the loop:<br>
>>>>> for brick in self.volume.traverse(self.back_center, self.front_center,<br>
>>>>> image):<br>
>>>>><br>
>>>>> This is in the tip of the development version of yt.<br>
>>>>><br>
>>>>> Does anyone know what the issue is here?<br>
>>>>><br>
>>>>> Thanks,<br>
>>>>> Britton<br>
>>>><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> yt-users mailing list<br>
>>>> <a href="mailto:yt-users@lists.spacepope.org">yt-users@lists.spacepope.org</a><br>
>>>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
>>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> yt-users mailing list<br>
>>> <a href="mailto:yt-users@lists.spacepope.org">yt-users@lists.spacepope.org</a><br>
>>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
>>><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> yt-users mailing list<br>
> <a href="mailto:yt-users@lists.spacepope.org">yt-users@lists.spacepope.org</a><br>
> <a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
><br>
><br>
_______________________________________________<br>
yt-users mailing list<br>
<a href="mailto:yt-users@lists.spacepope.org">yt-users@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
</div></div></blockquote></div><br>