Could you share the dataset? Maybe I can reproduce the issue.
Which version of PV are you using? You're not using the latest(4.1) if
--enable-bt isn't there. Upgrading to 4.1 may help...
On 06/19/2014 02:10 PM, jean mensa wrote:
The server has about 16GB of ram, while the client has 8GB. I am
loading only one array and I am starting the server with a simple
'pvserver' then I establish the connection manually from PV which I
start simply calling 'paraview'.
--enable-bt is not a valid option but dmesg does show a segfault:
at-spi-bus-laun[17239]: segfault at 968 ip 0000003e4e425321 sp
00007fff9770a040 error 4 in libX11.so.6.3.0
I don't think that this can be the problem though because the same
excessive memory load happens on the client mac with no crash and a
different version of X (XQuartz).
in the case of remote rendering I should see a black window coming
from pvserver where the dataset should be displayed, right? well I see
the window but nothing gets rendered on it... if remote rendering is
disabled do I still see the window?
j
On Thu, Jun 19, 2014 at 4:43 PM, Burlen Loring
<[email protected] <mailto:[email protected]>> wrote:
questions:
So how much ram is on this system?
How many arrays are you loading? If memory is an issue you may get
by by loading only one (or fewer) of them.
What command line are you using to start the server?
Can you start the client and server with --enable-bt on the
respective command lines? This should print a stack trace during
the crash. If it does send it to the list. If PV is killed because
its out of memory this may have been logged (on linux: dmesg |
egrep -i 'killed process').
about your original question: When in client server(not multicore)
with the server running on a remote system and the client on your
desktop, the client only has to display images rendered on the
server. so very low load on the client side. If you're seeing a
high load in that case , remote rendering is probably disabled,
perhaps this is a bug.
multicore would disable remote rendering , according to a recent
post on the mail list.
mulitcore the client and servers run on the same system and thus
the X server load could in fact be coming from the server rather
than the client.
On 06/19/2014 01:26 PM, jean mensa wrote:
it's the crash. The server loads about 8GB of data and then it
idles. The status bar also shows that
the vtkUnstructuredGridReader is loading the dataset and it
reaches 100% without giving any errors. The problem seems to be
displaying the data...
On Thu, Jun 19, 2014 at 4:17 PM, Burlen Loring <[email protected]
<mailto:[email protected]>> wrote:
>
> The server seems to load the dataset properly but no image is
shown on the client.
>
> OK, so is this the crash or a new issue? If there's no image
how could you tell the server loaded the dataset correctly?
>
>
>
> On 06/19/2014 12:53 PM, jean mensa wrote:
>
> same result. I disabled multicore and I was already using 0MB
remote rendering threshold. I have tried with paraview on both
linux and macosx. The server seems to load the dataset properly
but no image is shown on the client.
>
>
>
> On Thu, Jun 19, 2014 at 3:40 PM, Burlen Loring <[email protected]
<mailto:[email protected]>> wrote:
>>
>> Ug. you're using the multicore option to start the servers! I
believe that this forces remote rendering off. That would explain
your issues. Could you try duisabling the multi core option and
start your servers manually?
>>
>>
>> On 06/19/2014 12:29 PM, Burlen Loring wrote:
>>
>> OK, one possibility is that it may be related to remote
rendering settings. Under menu Edit->Settings->Render
View->Server there is a remote render threshold. I always set
this to 0 bytes to ensure remote parallel rendering. What's yours
set to?
>>
>> On 06/19/2014 12:18 PM, jean mensa wrote:
>>
>> Sorry, I didn't explain it properly. I have already tried to
connect to a pvserver from a GUI running on the client (without
an ssh connection then) but it also drains the memory on Xorg.
What is the load supposed to be on a client-pvserver connection?
>> Thanks,
>>
>>
>> On Thu, Jun 19, 2014 at 3:08 PM, Burlen Loring
<[email protected] <mailto:[email protected]>> wrote:
>>>
>>> Jean,
>>>
>>> What you describe is expected. X forwarding doesn't work well
for visualizing large datasets. The point is : don't use X
forwarding. The links show how to configure the client server
connection without X forwarding. Make sure that there is no -X on
the ssh command line.
>>>
>>> Burlen
>>>
>>>
>>> On 06/19/2014 11:46 AM, jean mensa wrote:
>>>
>>> When I do that Xorg process on the client drains the memory
up until it crashes. The connection I think is properly
established since it works fine for smaller datasets. What should
the load on the client be in that case?
>>> j
>>>
>>>
>>> On Thu, Jun 19, 2014 at 2:14 PM, Burlen Loring
<[email protected] <mailto:[email protected]>> wrote:
>>>>
>>>> Yes, this is expected. The OpenGL calls get piped to your
local system. This includes data like vertices and colors as
well. X forwarding doesn't give good performance and with large
data it may not even be feasible.
>>>>
>>>> You need to set up client server connection.
>>>>
>>>>
http://www.paraview.org/Wiki/Reverse_connection_and_port_forwarding
>>>> http://www.paraview.org/Wiki/ParaView:Server_Configuration
>>>> http://www.paraview.org/Wiki/Setting_up_a_ParaView_Server
>>>> http://www.paraview.org/Wiki/ParaView_And_Mesa_3D
>>>>
>>>>
>>>>
>>>>
>>>> On 06/19/2014 10:33 AM, jean mensa wrote:
>>>>
>>>> Hi all,
>>>> I have a rather large unstructured pvtu dataset (about 4
million points) which I am visualizing on a remote server. I am
running the paraview GUI (with the multicore option) on the
server and I connect to it via ssh sharing the X server. In this
way I can control the GUI running on the serve. I thought that
with this configuration I would only receive a screenshot of the
window and no actual data from paraview but the client seems to
share at least some of the load of the visualization. Is this the
expected behaviour? How can I avoid loading data on the client side?
>>>> Thanks in advance,
>>>>
>>>> --
>>>> Jean A. Mensa
>>>> Graduate Assistant
>>>> University of Miami
>>>> RSMAS - MPO
>>>> 4600 Rickenbacker Causeway
>>>> Miami, FL 33149-1098
>>>>
>>>>
>>>> _______________________________________________
>>>> Powered by www.kitware.com <http://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://public.kitware.com/mailman/listinfo/paraview
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Jean A. Mensa
>>> Graduate Assistant
>>> University of Miami
>>> RSMAS - MPO
>>> 4600 Rickenbacker Causeway
>>> Miami, FL 33149-1098
>>>
>>>
>>
>>
>>
>> --
>> Jean A. Mensa
>> Graduate Assistant
>> University of Miami
>> RSMAS - MPO
>> 4600 Rickenbacker Causeway
>> Miami, FL 33149-1098
>>
>>
>>
>
>
>
> --
> Jean A. Mensa
> Graduate Assistant
> University of Miami
> RSMAS - MPO
> 4600 Rickenbacker Causeway
> Miami, FL 33149-1098
>
>
--
Jean A. Mensa
Graduate Assistant
University of Miami
RSMAS - MPO
4600 Rickenbacker Causeway
Miami, FL 33149-1098
_______________________________________________
Powered bywww.kitware.com <http://www.kitware.com>
Visit other Kitware open-source projects
athttp://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://public.kitware.com/mailman/listinfo/paraview
--
*Jean A. Mensa*
/Graduate Assistant/
University of Miami
RSMAS - MPO
4600 Rickenbacker Causeway
Miami, FL 33149-1098
_______________________________________________
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://public.kitware.com/mailman/listinfo/paraview
