On Tue, Nov 1, 2011 at 2:53 PM, Matthew Turk <matthewturk@gmail.com> wrote:

Hi Sam and Britton,

This is likely due to the initialization of parallelism. If you
import from mods, the communicator stack sets itself up correctly
initially, which creates the ParallelAnalysisInterface class. At
binding time of methods => class, the parallel state is read from, in
order to do things like calculate which processors execute which task.

This sounds like a bug, though. If there are "works" and "doesn't
work" scripts I can take a look at it; file it on the issue tracker?

-Matt

On Tue, Nov 1, 2011 at 1:29 PM, Britton Smith <brittonsmith@gmail.com> wrote:
> Just to put some sort of resolution to this, I removed this import line:
> import yt.visualization.volume_rendering.api as vr
> as Sam suggested, allowing the yt.mods line to import the volume renderer
> and such. I then removed all the vr. instances from the script and now
> everything seems to work. It is not clear why, but that seems to have done
> it.
>
> On Tue, Nov 1, 2011 at 1:10 PM, Britton Smith <brittonsmith@gmail.com>
> wrote:
>>
>> Hi Sam,
>>
>> Here is the script I'm using for the render:
>> http://paste.yt-project.org/show/1899/
>>
>> The command I'm using is:
>> mpirun -np 2 python render_Z.py --parallel
>>
>> Also, I seem to be having trouble reading today. Processor zero does have
>> the right number of nonzero pixels, but the image still comes out all black.
>>
>> Britton
>>
>> On Tue, Nov 1, 2011 at 12:42 PM, Sam Skillman <samskillman@gmail.com>
>> wrote:
>>>
>>> Hi Britton,
>>> Would you mind pasting your script and mpirun command line? Processor 0
>>> should be the only processor that has the entire image at the end. If
>>> anything processor 1 would have half an image, which is why this confuses
>>> me.
>>> Thanks,
>>> Sam
>>> On Tue, Nov 1, 2011 at 10:07 AM, Britton Smith <brittonsmith@gmail.com>
>>> wrote:
>>>>
>>>> Hi again,
>>>>
>>>> Just an update on this. I was incorrect when I stated that the image
>>>> arrays were all zeros in parallel. What actually seems to be the case is
>>>> that with two processors, processor 0 which does the image writing, only has
>>>> a fraction of the total image, which to me looked like all zeros. Processor
>>>> 1 seems to have the entire image, though. It has the same number of
>>>> non-zero cells as the image array does in serial mode.
>>>>
>>>> I still don't know what's happening, but I'm looking at it.
>>>>
>>>> Britton
>>>>
>>>> On Tue, Nov 1, 2011 at 11:55 AM, Britton Smith <brittonsmith@gmail.com>
>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I'm doing a pretty simple volume render that uses the Camera.snapshot
>>>>> function. In serial, everything seems to be working fine, but when I run in
>>>>> parallel, the image comes out completely blank. I have gone into the
>>>>> snapshot routine and verified that the image array is all zeros for every
>>>>> processor after the loop:
>>>>> for brick in self.volume.traverse(self.back_center, self.front_center,
>>>>> image):
>>>>>
>>>>> This is in the tip of the development version of yt.
>>>>>
>>>>> Does anyone know what the issue is here?
>>>>>
>>>>> Thanks,
>>>>> Britton
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>
>
>
> _______________________________________________
> 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