[yt-users] parallel volume render returns blank image

Britton Smith brittonsmith at gmail.com
Tue Nov 1 12:38:59 PDT 2011


Hi Matt,

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.

Britton

On Tue, Nov 1, 2011 at 2:53 PM, Matthew Turk <matthewturk at 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 at 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 at 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 at 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 at 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 at 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 at lists.spacepope.org
> >>>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
> >>>>
> >>>
> >>>
> >>> _______________________________________________
> >>> yt-users mailing list
> >>> yt-users at lists.spacepope.org
> >>> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
> >>>
> >>
> >
> >
> > _______________________________________________
> > yt-users mailing list
> > yt-users at lists.spacepope.org
> > http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
> >
> >
> _______________________________________________
> 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/20111101/0a582bcb/attachment.html>


More information about the yt-users mailing list