[Paraview] Parallel ParaView: inexplicable results.

Mon Sep 28 10:52:37 EDT 2009

(Replying back to ParaView list).

I was not suggesting that your file system has anything to do with D3.  D3 never accesses your file system.  What I was saying was that the only thing I can think of that might be wrong is that perhaps there is something wrong with the reader.  Perhaps the reader is reading the same data on every processes instead of reading a piece of the data on each process.  Then, perhaps, D3 is having trouble realizing that all the data is replicated.  This is just speculation, though.

What does it look like when you run the Process Id filter before D3?

-Ken

On 9/25/09 6:28 AM, "Martin Aunskjær" <maaudk at yahoo.dk> wrote:

Thank you for your reply.

We did build PV 3.6.1 with OSMesa using Mesa-7.5.1 but were unable to make it work. As far as I remember PV would not launch on remote nodes, and we gave up on figuring out why. I do not recall the specifics of the problem. Also, since every node in the cluster does have rendering hardware, OSMesa should be a last resort anyway.

The data is initially replicated everywhere in that it is present in a folder on the node where the client runs and this folder is exported via NFS to all other nodes. I do not understand why this should confuse D3, at least I would expect any confusion to be the same in either case ?

Martin Ausnkjaer

--- Den tors 24/9/09 skrev Moreland, Kenneth <kmorel at sandia.gov>:

> Fra: Moreland, Kenneth <kmorel at sandia.gov>
> Emne: Re: [Paraview] Parallel ParaView: inexplicable results.
> Til: "Martin Aunskjær" <maaudk at yahoo.dk>, "paraview at paraview.org" <paraview at paraview.org>
> Dato: torsdag 24. september 2009 18.02
>
>
> Re: [Paraview] Parallel ParaView: inexplicable
> results.
>
>
> Why is OSMesa not an option?
>  Mesa 3D is free and it compiles just about
> everywhere.
>
>
>
> The IceT errors you are getting are actually probably
> caused by you having different resolutions on the local X
> servers.  Specifically, the X server on node 0 probably
> has a larger resolution than at least one of the other X
> servers.
>
>
>
> I cannot think of a reason why D3 would behave differently
> between case 1 and 2.  As far as the filter execution
> is concerned, the two cases should be the same.  Could
> it be that your data is initially replicated everywhere and
> that D3 is somehow not able to combine co-located points?
>
>
>
> -Ken
>
>
>
>
>
> On 9/23/09 11:36 PM, "Martin Aunskjær"
> <maaudk at yahoo.dk> wrote:
>
>
>
> I am getting
> the infamous warning
>
>
>
> "Display is not accessible on the server side.
>
> Remote rendering will be disabled."
>
>
>
> whenever I start PV in client/server mode. This is because
> the remote pvservers cannot connect to the local X servers.
> The only way I have been able to get rid of it is to
> physically log in to each remote node before I establish the
> client/server connection (OSMesa not an option). Now, I can
> either choose to do that (case 1), or I can choose to accept
> the above warning and tolerate that only data processing
> will be parallel - rendering will be done locally on the
> client (case 2).
>
>
>
> I have observed that the following procedure produces
> different results in case 1 and 2:
>
>
>
> Start client/server using reverse connect.
>
> Load data set.
>
> Apply D3 filter.
>
> Apply ProcessId filter.
>
> Adjust color map resolution to equal number of pvserver
> nodes.
>
> Color data set with process id.
>
>
>
> Case 1:
>
> -------
>
> The whole data set is colored with process 0 color.
>
> The pvserver continuosly spits out:
>
> ICET,0:ERROR: Sizes of src and dest do not agree.
>
>
>
> Case 2:
>
> -------
>
> Data set colored as expected showing equal distribution of
> data between nodes.
>
> pvserver spits out:
>
> No protocol specified.
>
>
>
> In both cases Remote Rendering Threshold is on and set to 0
> MB.
>
>
>
> The ICET error is likely caused by different screen
> resolutions on servers and client. It is not possible for me
> to have the same resolution everywhere.
>
>
>
> The 'No protocol specified' is due to the missing X
> server connection, so this is expected.
>
>
>
> Why is case 1 different from case 2 - is it because of the
> ICET error ?
>
>
>
>
>
> A few details:
>
> --------------
>
> ParaView 3.6.1 Release build from sources.
>
> Data set size 111 MB.
>
> VTK_MPI_MAX_NUMPROCS:STRING=32
>
>
>
>
>
>
>
>       ___________________________________________________________
>
> Skal du købe ny bil? Sammenlign priser på
> brugte biler med Kelkoo og find et godt tilbud! - Se mere
> her http://dk.yahoo.com/r/pat/mmb
>
> _______________________________________________
>
> Powered by www.kitware.com
>
>
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
>
>
> Please keep messages on-topic and check the ParaView Wiki
> at: http://paraview.org/Wiki/ParaView
>
>
>
> Follow this link to subscribe/unsubscribe:
>
> http://www.paraview.org/mailman/listinfo/paraview
>
>
>
>
>
>
>
>
>
>    ****
>      Kenneth Moreland
>
>     ***
>      Sandia National Laboratories
>
> ***********
>
> *** *** ***  email: kmorel at sandia.gov
>
> **  ***  **  phone: (505) 844-8919
>
>     ***
>      web:   http://www.cs.unm.edu/~kmorel
>
>
>
>
>
>
>
>

      ________________________________________________________
Audi, Fiat, Peugeot, Skoda, Porsche, Toyota, Ford - Kelkoo har brugte biler til en hver smag! Klik her for at sammenligne priser.(http://dk.yahoo.com/r/pat/mmb)

   ****      Kenneth Moreland
    ***      Sandia National Laboratories
***********
*** *** ***  email: kmorel at sandia.gov
**  ***  **  phone: (505) 844-8919
    ***      web:   http://www.cs.unm.edu/~kmorel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20090928/5796b77a/attachment.htm>