[Paraview] ParaViewWeb - Issues with Loading ASCII STL file & Rendering the Output Fields
kai liu
liuwukai at yahoo.com
Fri Sep 25 14:45:14 EDT 2015
Dear Scott:
Thank you for the testings.
1) Regarding using local rendering on the cube data file: It seems that with local rendering, we may not properly handle coloring by arrays where the data range is 0 (e.g. the range of T in your case was [303.1499938964844, 303.1499938964844]). I was able to use local rendering by first loading the data, then choosing a local rendering approach (either worked fine), and then going back and coloring by T. This could be a workaround if you need to test the speed of local rendering vs remote.
Kai's Response:
My local deprecated (WebGL) rendering seems quite fast now when I load ParaView Datasets.
I was not able to use local rendering (Local VGL or Local Deprecated) on my cube data file. I first loaded the data, chose local (Deprecated) option and then went back to color by T. I got the same error message: WebSocket connection to 'ws://XXXX:8080/proxy?sessionId=7bb6e67a-63a9-11e5-9b44-00155dd73e0d' failed: Error during WebSocket handshake: Unexpected response code: 503 . I believe the server side process indeed crashed. However, remote rendering does seem to work fine with T color. The speed of local rendering is very slow, but the speed of local deprecated (WebGL) rendering is very fast now.
2) Regarding loading the .stl file, I did not run into the same issue as you did, i.e. the .stl file loaded without any problems. The paraviewweb I am running was built from master which is a day or so old, so I'm wondering what version you may have compiled?
Kai's Response:
I tried .stl file a couple of times again and still the same. I do not see the geometry in ParaViewWeb, and the log file has the same error message as before. Currently my Ubuntu 14.04 has ParaViewWeb - 4.4 version. I built this on 09/22/2015. The following is the commands I used to obtain the source:
Get ParaViewWeb by a Specific Version
git clone git://paraview.org/ParaView.git srccd srcgit checkout v4.4.0git submodule update --init
When I build ParaViewWeb 4.3 in July, 2015, I used the following commands:
Get the latest ParaViewWeb source
git clone git://paraview.org/stage/ParaView.git srccd src git submodule update --init
I have put my responses inline below again ....
On Fri, Sep 25, 2015 at 9:15 AM, kai liu <liuwukai at yahoo.com> wrote:
Dear Scott,
Thanks for your quick response, I have also put my responses inline below with light blue color :
Issue 1: Loading ASCII stl file
When I try to load my ASCII stl file on the ParaviewWeb, I receive the following error message in my log file. However, desktop ParaView application loads the file fine.
ERROR: In /home/user/ParaViewWeb/ParaView/src/VTK/IO/Geometry/vtkSTLReader.cxx, line 461vtkSTLReader (0x5d89b50): STLReader: error while reading file /home/user/ParaViewWeb/data/Mitchell_Lee_Administration_ReckordArmory_.stl at line 14: unable to read reading point.
ERROR: In /home/user/ParaViewWeb/ParaView/src/VTK/Common/ExecutionModel/vtkExecutive.cxx, line 784vtkPVCompositeDataPipeline (0x5d84f70): Algorithm vtkFileSeriesReader(0x5d881b0) returned failure for request: vtkInformation (0x5d97f30) Debug: Off Modified Time: 225417 Reference Count: 1 Registered Events: (none) Request: REQUEST_DATA FROM_OUTPUT_PORT: 0 ALGORITHM_AFTER_FORWARD: 1 FORWARD_DIRECTION: 0
Did you build the ParaView desktop application in the same build as the version you're using to run ParaViewWeb? Maybe you could try to take one of the standard ParaView datasets and try to load it in ParaViewWeb, and see if you have the same issue you mentioned above. To get this data if you don't already have it, go here:
http://www.paraview.org/download/
And under "Type of Download", choose "Data, Documentation, and Tutorials". Once you get this data, try opening the "disk_out_ref.ex2" file in ParaViewWeb. If you see the same issue as above, then there could be something going on with the way you have built ParaView, which we can try to figure out at that point. If you do not see the same issue as above, then perhaps you could send me (off the list) a sample data file I could use to try to replicate the problem and debug it on this end.
Kai's Response
I did not build the ParaView desktop application. I installed ParaView 4.1.0 through the Ubuntu terminal using sudo apt-get install paraviewopenfoam410 .
I tested files with local ParaView desktop application as well as local ParaViewWeb. My Ubuntu 14.04 server does not have ParaView application, and it has only ParaViewWeb. Both server and local ParaViewWeb produce the same issues.
I have tested "disk_out_ref.ex2" file in ParaViewWeb, and it seems to be okay. I will send you the sample data files privately.
Just so I am clear. Your "local" version is the one you install via apt-get? And the Ubuntu 14.04 server version is the one you built yourself? Did you download a source bundle to build the server one? If so, do you know what version you downloaded and built on your server?
Kai's Response:
I apologize for the confusion. I built both my "local" and "sever" ParaViewWeb 4.4.0 with OSMesa using the following commands:
git clone git://paraview.org/ParaView.git srccd srcgit checkout v4.4.0git submodule update --init
I had to use git checkout v4.4.0 because last time the repository head was 4.3 version.
My "local" ParaView 4.1 desktop application was installed via apt-get. When I said ParaView desktop application, I am not referring to the ParaViewWeb at all. I always refer ParaView and ParaViewWeb as two applications.
Please note that I had also tried ParaViewWeb 4.1 and 4.3 on both my "local" and "server", they both had the same issues in loading the ASCII STL file and rendering the output fields, which would be the same issues currently I am experiencing in ParaViewWeb 4.4.
Issue 2:
If I do the following selections on the ParaViewWeb, I always receive src/VTK/Common/Core/vtkDataArrayTemplate.h:191: T vtkDataArrayTemplate<T>::GetValue(vtkIdType) [with T = float; vtkIdType = long long int]: Assertion `id >= 0 && id < this->Size' failed message in the log file and cause the web socket connection closed.
2015-09-23 17:33:52-0400 [-] Log opened.2015-09-23 17:33:53-0400 [-] Site starting on 90092015-09-23 17:33:53-0400 [-] Starting factory <twisted.web.server.Site instance at 0x7fb6f2e55830>2015-09-23 17:33:53-0400 [HTTPChannel,0,127.0.0.1] Client has reconnected, cancelling reaper2015-09-23 17:33:53-0400 [HTTPChannel,0,127.0.0.1] on_connect: connection count = 1pvpython: /home/user/ParaViewWeb/ParaView/src/VTK/Common/Core/vtkDataArrayTemplate.h:191: T vtkDataArrayTemplate<T>::GetValue(vtkIdType) [with T = float; vtkIdType = long long int]: Assertion `id >= 0 && id < this->Size' failed.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
WebSocket connection to 'ws://XXXXXXXXXXX:8080/proxy?sessionId=0c562ad6-623f-11e5-9b44-00155dd73e0d' failed: Error during WebSocket handshake: Unexpected response code: 503
I checked HTTP traffic, it has the following message. I assume the connection is closed because of the above error.
I wonder if the server side process crashed as a result of the error you see in the log file? That would explain the websocket connection error. Again, trying a known data set like "disk_out_ref.ex2" may help us to pinpoint problem which caused the error output you saw above.
Kai's Response
My unintelligent question is how could I determine if the server side process crashed?
One approach: Use a terminal on the machine where ParaViewWeb is running and type:
ps -ef | grep pvpython
If the process is running, you should see a pvpython instance running, where your pv_web_visualizer.py script is the argument, along with any other arguments your launcher provided when it started the process for you. Something like:
/path/to/paraview/build/bin/pvpython /path/to/paraview/build/lib/site-packages/paraview/web/pv_web_visualizer.py --port 9999 --data-dir /blah/blah/blah
In the case of the cube you shared with me, the process did indeed crash as a result of the steps you provided.
Kai's Response:
Thank you for the command and the explanations.
Issue 3: Slow ParaViewWeb
My ParaViewWeb is very slow. Even I change the rendering mode to WebGL, It is still very slow. The Ubuntu 14.04 Sever specifications are the following:
- 8 Cores - 8 GB RAM - 2.3 Ghz processors
To get faster rendering with OSMesa, you may try building a recent version of OSMesa using Gallium + LLVMPipe. See here:
http://www.paraview.org/Wiki/ParaView/ParaView_And_Mesa_3D
But even that won't be as fast as hardware rendering (not using OSMesa). I'm not sure why you don't see a speedup when switching to WebGL, though, for if your data is small enough to all fit in within the GPU of your desktop or laptop, then it should be faster than offscreen rendering on the server, once the data is loaded.
Kai's Response
I believe my build is based on recent version of OSMesa using Gallium + LLVMPipe
Mesa 9.2.2 OSMesa Gallium llvmpipe
make -j4
autoreconf -fi
./configure \CXXFLAGS="-O2 -g -DDEFAULT_SOFTWARE_DEPTH_BITS=31" \CFLAGS="-O2 -g -DDEFAULT_SOFTWARE_DEPTH_BITS=31" \--disable-xvmc \--disable-glx \--disable-dri \--with-dri-drivers="" \--with-gallium-drivers="swrast" \--enable-texture-float \--disable-shared-glapi \--disable-egl \--with-egl-platforms="" \--enable-gallium-osmesa \--enable-gallium-llvm=yes \--with-llvm-shared-libs \--prefix=/opt/mesa/9.2.2/llvmpipe
make -j2
make -j4 install
This looks fine to me, though I believe OSMesa Gallium llvmpipe has moved along quite a few versions since that documentation was written, so building a more recent one could be something to try.
When I built ParaViewWeb, The following is what I changed when I generated the cmake file:
PARAVIEW_ENABLE_PYTHON ONPARAVIEW_BUILD_QT_GUI OFFCMAKE_INSTALL_PREFIX /.../ParaView/installVTK_USE_X OFFOPENGL_INCLUDE_DIR /opt/mesa/9.2.2/llvmpipe/includeOPENGL_gl_LIBRARYOPENGL_glu_LIBRARY /opt/mesa/9.2.2/llvmpipe/lib/libGLU.soVTK_OPENGL_HAS_OSMESA ONOSMESA_INCLUDE_DIR /opt/mesa/9.2.2/llvmpipe/includeOSMESA_LIBRARY /opt/mesa/9.2.2/llvmpipe/lib/libOSMesa.so
Please feel free to correct me if you believe you did not build a recent version of OSMesa using Gallium + LLVMPipe
I will send you two data files. First one is an ASCII STL file (issue 1) and second one is the issue rendering output fields (issue 2). Thank you for your help!
Please let me know if you need anything from me.
One other thing that could be useful for us to know is what kind of network is between your browser and the server. When local rendering is enabled, the server's camera is still synchronized with with camera in the browser so that if you switch back to image delivery, you won't see some unexpected camera angle. If the network is *really* slow, this could perhaps keep the local rendering from being as fast as possible. But it seems like it would have to be really slow.
Kai's Response:
I would try to build OSMesa Gallium llvmpipe to the latest version.
When you said what kind of network between my browser and the server, I assume you are referring to the Internet speed. Please correct me if I am off the topic here. I did the speed test a few times, and I have the download speed in the range of 15-30 Mbps and upload speed between 25-40 Mbps. However, when I load ParaView datasets in ParaViewWeb, it seem to load quick fast on my end when I switch to the local rendering mode. I am not sure what may have been the issue before.
I am still having issue with local rendering (Local VGL or Local Deprecated) on my cube data file even I tried your workaround, and I am still not able to load my ASCII .stl file.
Please let me know.
Thank you!
Kai L.
On Friday, September 25, 2015 12:07 PM, Scott Wittenburg <scott.wittenburg at kitware.com> wrote:
Hello Kai,
Regarding the data files you shared, I did some testing and found some things out:
1) Regarding using local rendering on the cube data file: It seems that with local rendering, we may not properly handle coloring by arrays where the data range is 0 (e.g. the range of T in your case was [303.1499938964844, 303.1499938964844]). I was able to use local rendering by first loading the data, then choosing a local rendering approach (either worked fine), and then going back and coloring by T. This could be a workaround if you need to test the speed of local rendering vs remote.
2) Regarding loading the .stl file, I did not run into the same issue as you did, i.e. the .stl file loaded without any problems. The paraviewweb I am running was built from master which is a day or so old, so I'm wondering what version you may have compiled?
The rest of my responses are inline below...
On Fri, Sep 25, 2015 at 9:15 AM, kai liu <liuwukai at yahoo.com> wrote:
Dear Scott,
Thanks for your quick response, I have also put my responses inline below with light blue color :
Issue 1: Loading ASCII stl file
When I try to load my ASCII stl file on the ParaviewWeb, I receive the following error message in my log file. However, desktop ParaView application loads the file fine.
ERROR: In /home/user/ParaViewWeb/ParaView/src/VTK/IO/Geometry/vtkSTLReader.cxx, line 461vtkSTLReader (0x5d89b50): STLReader: error while reading file /home/user/ParaViewWeb/data/Mitchell_Lee_Administration_ReckordArmory_.stl at line 14: unable to read reading point.
ERROR: In /home/user/ParaViewWeb/ParaView/src/VTK/Common/ExecutionModel/vtkExecutive.cxx, line 784vtkPVCompositeDataPipeline (0x5d84f70): Algorithm vtkFileSeriesReader(0x5d881b0) returned failure for request: vtkInformation (0x5d97f30) Debug: Off Modified Time: 225417 Reference Count: 1 Registered Events: (none) Request: REQUEST_DATA FROM_OUTPUT_PORT: 0 ALGORITHM_AFTER_FORWARD: 1 FORWARD_DIRECTION: 0
Did you build the ParaView desktop application in the same build as the version you're using to run ParaViewWeb? Maybe you could try to take one of the standard ParaView datasets and try to load it in ParaViewWeb, and see if you have the same issue you mentioned above. To get this data if you don't already have it, go here:
http://www.paraview.org/download/
And under "Type of Download", choose "Data, Documentation, and Tutorials". Once you get this data, try opening the "disk_out_ref.ex2" file in ParaViewWeb. If you see the same issue as above, then there could be something going on with the way you have built ParaView, which we can try to figure out at that point. If you do not see the same issue as above, then perhaps you could send me (off the list) a sample data file I could use to try to replicate the problem and debug it on this end.
Kai's Response
I did not build the ParaView desktop application. I installed ParaView 4.1.0 through the Ubuntu terminal using sudo apt-get install paraviewopenfoam410 .
I tested files with local ParaView desktop application as well as local ParaViewWeb. My Ubuntu 14.04 server does not have ParaView application, and it has only ParaViewWeb. Both server and local ParaViewWeb produce the same issues.
I have tested "disk_out_ref.ex2" file in ParaViewWeb, and it seems to be okay. I will send you the sample data files privately.
Just so I am clear. Your "local" version is the one you install via apt-get? And the Ubuntu 14.04 server version is the one you built yourself? Did you download a source bundle to build the server one? If so, do you know what version you downloaded and built on your server?
Issue 2:
If I do the following selections on the ParaViewWeb, I always receive src/VTK/Common/Core/vtkDataArrayTemplate.h:191: T vtkDataArrayTemplate<T>::GetValue(vtkIdType) [with T = float; vtkIdType = long long int]: Assertion `id >= 0 && id < this->Size' failed message in the log file and cause the web socket connection closed.
2015-09-23 17:33:52-0400 [-] Log opened.2015-09-23 17:33:53-0400 [-] Site starting on 90092015-09-23 17:33:53-0400 [-] Starting factory <twisted.web.server.Site instance at 0x7fb6f2e55830>2015-09-23 17:33:53-0400 [HTTPChannel,0,127.0.0.1] Client has reconnected, cancelling reaper2015-09-23 17:33:53-0400 [HTTPChannel,0,127.0.0.1] on_connect: connection count = 1pvpython: /home/user/ParaViewWeb/ParaView/src/VTK/Common/Core/vtkDataArrayTemplate.h:191: T vtkDataArrayTemplate<T>::GetValue(vtkIdType) [with T = float; vtkIdType = long long int]: Assertion `id >= 0 && id < this->Size' failed.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
WebSocket connection to 'ws://XXXXXXXXXXX:8080/proxy?sessionId=0c562ad6-623f-11e5-9b44-00155dd73e0d' failed: Error during WebSocket handshake: Unexpected response code: 503
I checked HTTP traffic, it has the following message. I assume the connection is closed because of the above error.
I wonder if the server side process crashed as a result of the error you see in the log file? That would explain the websocket connection error. Again, trying a known data set like "disk_out_ref.ex2" may help us to pinpoint problem which caused the error output you saw above.
Kai's Response
My unintelligent question is how could I determine if the server side process crashed?
One approach: Use a terminal on the machine where ParaViewWeb is running and type:
ps -ef | grep pvpython
If the process is running, you should see a pvpython instance running, where your pv_web_visualizer.py script is the argument, along with any other arguments your launcher provided when it started the process for you. Something like:
/path/to/paraview/build/bin/pvpython /path/to/paraview/build/lib/site-packages/paraview/web/pv_web_visualizer.py --port 9999 --data-dir /blah/blah/blah
In the case of the cube you shared with me, the process did indeed crash as a result of the steps you provided.
Issue 3: Slow ParaViewWeb
My ParaViewWeb is very slow. Even I change the rendering mode to WebGL, It is still very slow. The Ubuntu 14.04 Sever specifications are the following:
- 8 Cores - 8 GB RAM - 2.3 Ghz processors
To get faster rendering with OSMesa, you may try building a recent version of OSMesa using Gallium + LLVMPipe. See here:
http://www.paraview.org/Wiki/ParaView/ParaView_And_Mesa_3D
But even that won't be as fast as hardware rendering (not using OSMesa). I'm not sure why you don't see a speedup when switching to WebGL, though, for if your data is small enough to all fit in within the GPU of your desktop or laptop, then it should be faster than offscreen rendering on the server, once the data is loaded.
Kai's Response
I believe my build is based on recent version of OSMesa using Gallium + LLVMPipe
Mesa 9.2.2 OSMesa Gallium llvmpipe
make -j4
autoreconf -fi
./configure \CXXFLAGS="-O2 -g -DDEFAULT_SOFTWARE_DEPTH_BITS=31" \CFLAGS="-O2 -g -DDEFAULT_SOFTWARE_DEPTH_BITS=31" \--disable-xvmc \--disable-glx \--disable-dri \--with-dri-drivers="" \--with-gallium-drivers="swrast" \--enable-texture-float \--disable-shared-glapi \--disable-egl \--with-egl-platforms="" \--enable-gallium-osmesa \--enable-gallium-llvm=yes \--with-llvm-shared-libs \--prefix=/opt/mesa/9.2.2/llvmpipe
make -j2
make -j4 install
This looks fine to me, though I believe OSMesa Gallium llvmpipe has moved along quite a few versions since that documentation was written, so building a more recent one could be something to try.
When I built ParaViewWeb, The following is what I changed when I generated the cmake file:
PARAVIEW_ENABLE_PYTHON ONPARAVIEW_BUILD_QT_GUI OFFCMAKE_INSTALL_PREFIX /.../ParaView/installVTK_USE_X OFFOPENGL_INCLUDE_DIR /opt/mesa/9.2.2/llvmpipe/includeOPENGL_gl_LIBRARYOPENGL_glu_LIBRARY /opt/mesa/9.2.2/llvmpipe/lib/libGLU.soVTK_OPENGL_HAS_OSMESA ONOSMESA_INCLUDE_DIR /opt/mesa/9.2.2/llvmpipe/includeOSMESA_LIBRARY /opt/mesa/9.2.2/llvmpipe/lib/libOSMesa.so
Please feel free to correct me if you believe you did not build a recent version of OSMesa using Gallium + LLVMPipe
I will send you two data files. First one is an ASCII STL file (issue 1) and second one is the issue rendering output fields (issue 2). Thank you for your help!
Please let me know if you need anything from me.
One other thing that could be useful for us to know is what kind of network is between your browser and the server. When local rendering is enabled, the server's camera is still synchronized with with camera in the browser so that if you switch back to image delivery, you won't see some unexpected camera angle. If the network is *really* slow, this could perhaps keep the local rendering from being as fast as possible. But it seems like it would have to be really slow.
Hope this helps.
Cheers,Scott
Kai L.
--------------------------------------------------------------------------------------------------------------------------------------
On Thursday, September 24, 2015 9:45 AM, Scott Wittenburg <scott.wittenburg at kitware.com> wrote:
Hello Kai,
Thanks for your questions, I have put my responses inline below:
On Thu, Sep 24, 2015 at 5:45 AM, kai liu via ParaView <paraview at paraview.org> wrote:
Dear,
I have deployed ParaViewWeb. Everything seems to work fine, but I am not able to visualize outputs, such as rendering the output fields such as T, V, etc.
I built and tried ParaViewWeb 4.1, 4.3 and 4.4 with offscreen OSMesa, and I have received the same issues. Currently I use Apache 2.4.16 as a front end running on port 8080, python launcher and ParaViewWeb 4.4 with offscreen OSMesa. The following is my launcher and Apache configuration files:
launcher.json
{
"configuration": { "host" : "localhost", "port" : 9000, "endpoint": "paraview", "content": "/home/user/ParaViewWeb/ParaView/build/www", "proxy_file": "/home/user/ParaViewWeb/pv-mapping-file/mapping.txt", "sessionURL" : "ws://testexample.com:8080/proxy?sessionId=${id}", "timeout" : 25, "log_dir" : "/home/user/ParaViewWeb/pvwLogs", "upload_dir" : "/home/user/ParaViewWeb/upload", "fields" : ["file", "host", "port", "updir"] },
"resources" : [ { "host" : "localhost", "port_range" : [9001, 9010] } ],
"properties" : { "build_dir" : "/home/user/ParaViewWeb/ParaView/build", "python_exec" : "/home/user/ParaViewWeb/ParaView/build/bin/pvpython", "python_path": "/home/user/ParaViewWeb/ParaView/build/lib/site-packages", "WWW" : "/home/user/ParaViewWeb/ParaView/build/www", "dataDir": "/home/user/ParaViewWeb/data", "load_file": "/home/user/ParaViewWeb/upload", "source_dir": "/.../src" },
"apps": { "pipeline": { "cmd": [ "${python_exec}", "-dr", "${python_path}/paraview/web/pv_web_visualizer.py", "--port", "${port}", "--data-dir", "${dataDir}" ], "ready_line" : "Starting factory" }, "visualizer": { "cmd": [ "${python_exec}", "-dr", "${python_path}/paraview/web/pv_web_visualizer.py", "--port", "${port}", "--data-dir", "${dataDir}" ], "ready_line" : "Starting factory" }, "loader": { "cmd": [ "${python_exec}", "-dr", "${python_path}/paraview/web/pv_web_file_loader.py", "--port", "${port}", "--data-dir", "${dataDir}", "-f", "--authKey", "${secret}" ], "ready_line" : "Starting factory" }, "data_prober": { "cmd": [ "${python_exec}", "-dr", "${python_path}/paraview/web/pv_web_data_prober.py", "--port", "${port}", "--data-dir", "${dataDir}", "-f", "--authKey", "${secret}" ], "ready_line" : "Starting factory" } }}
httpd-vhosts.conf
<VirtualHost *:8080> ServerName testexample.com ServerAdmin webmaster at example-host.example.com DocumentRoot "/home/user/ParaViewWeb/ParaView/build/www" ErrorLog "/home/user/ParaViewWeb/apacheLogs/pv-error_log" CustomLog "/home/user/ParaViewWeb/apacheLogs/pv-access_log" common
ProxyPass /paraview http://localhost:9000/paraview
# Turn on the rewrite engine RewriteEngine On
# This is the path the mapping file Jetty creates RewriteMap session-to-port txt:/home/user/ParaViewWeb/pv-mapping-file/mapping.txt
# This is the rewrite condition. Look for anything with a sessionId= in the query part of the URL and capture the value to use below. RewriteCond %{QUERY_STRING} ^sessionId=(.*)$ [NC]
# This does the rewrite using the mapping file and the sessionId RewriteRule ^/proxy.*$ ws://${session-to-port:%1}/ws [P]
<Directory "/home/user/ParaViewWeb/ParaView/build/www"> Options Indexes FollowSymLinks Order allow,deny Allow from all AllowOverride None Require all granted </Directory></VirtualHost>
Issue 1: Loading ASCII stl file
When I try to load my ASCII stl file on the ParaviewWeb, I receive the following error message in my log file. However, desktop ParaView application loads the file fine.
ERROR: In /home/user/ParaViewWeb/ParaView/src/VTK/IO/Geometry/vtkSTLReader.cxx, line 461vtkSTLReader (0x5d89b50): STLReader: error while reading file /home/user/ParaViewWeb/data/Mitchell_Lee_Administration_ReckordArmory_.stl at line 14: unable to read reading point.
ERROR: In /home/user/ParaViewWeb/ParaView/src/VTK/Common/ExecutionModel/vtkExecutive.cxx, line 784vtkPVCompositeDataPipeline (0x5d84f70): Algorithm vtkFileSeriesReader(0x5d881b0) returned failure for request: vtkInformation (0x5d97f30) Debug: Off Modified Time: 225417 Reference Count: 1 Registered Events: (none) Request: REQUEST_DATA FROM_OUTPUT_PORT: 0 ALGORITHM_AFTER_FORWARD: 1 FORWARD_DIRECTION: 0
Did you build the ParaView desktop application in the same build as the version you're using to run ParaViewWeb? Maybe you could try to take one of the standard ParaView datasets and try to load it in ParaViewWeb, and see if you have the same issue you mentioned above. To get this data if you don't already have it, go here:
http://www.paraview.org/download/
And under "Type of Download", choose "Data, Documentation, and Tutorials". Once you get this data, try opening the "disk_out_ref.ex2" file in ParaViewWeb. If you see the same issue as above, then there could be something going on with the way you have built ParaView, which we can try to figure out at that point. If you do not see the same issue as above, then perhaps you could send me (off the list) a sample data file I could use to try to replicate the problem and debug it on this end.
Issue 2:
If I do the following selections on the ParaViewWeb, I always receive src/VTK/Common/Core/vtkDataArrayTemplate.h:191: T vtkDataArrayTemplate<T>::GetValue(vtkIdType) [with T = float; vtkIdType = long long int]: Assertion `id >= 0 && id < this->Size' failed message in the log file and cause the web socket connection closed.
2015-09-23 17:33:52-0400 [-] Log opened.2015-09-23 17:33:53-0400 [-] Site starting on 90092015-09-23 17:33:53-0400 [-] Starting factory <twisted.web.server.Site instance at 0x7fb6f2e55830>2015-09-23 17:33:53-0400 [HTTPChannel,0,127.0.0.1] Client has reconnected, cancelling reaper2015-09-23 17:33:53-0400 [HTTPChannel,0,127.0.0.1] on_connect: connection count = 1pvpython: /home/user/ParaViewWeb/ParaView/src/VTK/Common/Core/vtkDataArrayTemplate.h:191: T vtkDataArrayTemplate<T>::GetValue(vtkIdType) [with T = float; vtkIdType = long long int]: Assertion `id >= 0 && id < this->Size' failed.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
WebSocket connection to 'ws://XXXXXXXXXXX:8080/proxy?sessionId=0c562ad6-623f-11e5-9b44-00155dd73e0d' failed: Error during WebSocket handshake: Unexpected response code: 503
I checked HTTP traffic, it has the following message. I assume the connection is closed because of the above error.
I wonder if the server side process crashed as a result of the error you see in the log file? That would explain the websocket connection error. Again, trying a known data set like "disk_out_ref.ex2" may help us to pinpoint problem which caused the error output you saw above.
Issue 3: Slow ParaViewWeb
My ParaViewWeb is very slow. Even I change the rendering mode to WebGL, It is still very slow. The Ubuntu 14.04 Sever specifications are the following:
- 8 Cores - 8 GB RAM - 2.3 Ghz processors
To get faster rendering with OSMesa, you may try building a recent version of OSMesa using Gallium + LLVMPipe. See here:
http://www.paraview.org/Wiki/ParaView/ParaView_And_Mesa_3D
But even that won't be as fast as hardware rendering (not using OSMesa). I'm not sure why you don't see a speedup when switching to WebGL, though, for if your data is small enough to all fit in within the GPU of your desktop or laptop, then it should be faster than offscreen rendering on the server, once the data is loaded.
Just glancing through the configuration files you provided, I don't see anything wrong.
Hope this helps,Scott
Please let me know if I have setup anything incorrectly. Could anybody help me with the above three issues that I am experiencing now. Thank you very much!
Kai L.
_______________________________________________
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
Search the list archives at: http://markmail.org/search/?q=ParaView
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20150925/e4236bea/attachment-0001.html>
More information about the ParaView
mailing list