Kai, You are welcome! Thanks for letting us know the problem is resolved for you.
Cory On Thu, Oct 1, 2015 at 8:12 AM, kai liu <liuwu...@yahoo.com> wrote: > Cory, > > Yes. ParaView's master branch works fine with STL load issue now. Thank > you for your help! > > Kai L. > > > > On Wednesday, September 30, 2015 11:03 AM, Cory Quammen < > cory.quam...@kitware.com> wrote: > > > Kai, > > Thanks for filing these bug reports. I believe the STL load issue is > already fixed in ParaView's master branch, but the bug fix did not make it > into version 4.4. > > Best regards, > Cory > > On Tue, Sep 29, 2015 at 7:13 PM, kai liu <liuwu...@yahoo.com> wrote: > > Hi Scott, > > I have filed both bug reports: STL file load issue and surface with edges > issue in local rendering. > > http://www.paraview.org/Bug/view.php?id=15747 > > http://www.paraview.org/Bug/view.php?id=15748 > > Please let me know if I need to make changes/corrections in the bug > reports. > > Thank you for all your assistance. > > Kai L. > > > > On Tuesday, September 29, 2015 11:04 AM, Scott Wittenburg < > scott.wittenb...@kitware.com> wrote: > > > Hello Kai, > > Now after doing a clean build of a recent ParaView master, it seems I > can no longer see the Mitchel.stl file, and the server produces the error > logs you have mentioned somewhere above about the being unable to read the > reading point. So I would say at this point, there is perhaps a bug in the > stl reader. I wonder if you would be willing to file a bug report? Maybe > two while you're at it? > > 1) stl file load issue, it would be great if you are able to upload a file > that can be used to reproduce the issue, something you don't mind sharing. > > 2) surface with edges issue in ParaViewWeb when doing local rendering > > We are still keeping track of bugs with Mantis for the time being: > > http://www.paraview.org/Bug/my_view_page.php > > Thanks! Someone will get around to these when we get some time, but we > probably can't estimate when that will be. > > Cheers, > Scott > > On Sat, Sep 26, 2015 at 6:43 PM, kai liu <liuwu...@yahoo.com> wrote: > > > Dear Scott, > > Should I just wait for the next patch release for the local rendering > (WebGL) "Surface with edges" issue? > > > I just tried the following commands to obtain the source from the GitLab > and rebuilt the ParaViewWeb 4.4 with OSMesa, but it still does not resolve > my stl loading issue. Am I still not getting latest 4.4 release with all > the commits? > . > > git clone https://gitlab.kitware.com/paraview/paraview.git src > cd src > git submodule update --init > > > On the other hand, I also tried to download and build from master .tar.gz > file from the GitLab, but it seems not to have the latest submodule. I > got the following error message: > > CMake Error at CMakeLists.txt:625 (include): > include could not find load file: > > vtkModuleAPI > > > > CMake Error at CMakeLists.txt:626 (include): > include could not find load file: > > vtkModuleMacros > > > > CMake Error at CMake/ParaViewMacros.cmake:416 (include): > include could not find load file: > > vtkForwardingExecutable > > > I am not sure how to update to the latest submodule since I did not use > the git to clone the source. > > Thank you again! > > Kai L. > > > > > On Friday, September 25, 2015 4:28 PM, Scott Wittenburg < > scott.wittenb...@kitware.com> wrote: > > > > > On Fri, Sep 25, 2015 at 3:24 PM, kai liu <liuwu...@yahoo.com> wrote: > > Dear Scott: > > I do not have problems setting the representation to "Surface" with color > "T" in local deprecated rendering mode. However, I do get the same error > message with representation set to "Surface with edges" or "Wireframe" with > color "T" in local deprecated rendering. > > But "Surface with edges" and "Wireframe" with color "T" in remote > rendering are fine. > > When I click "choose palette" , select "Cool to Warm" and click apply > properties for my cube data sample, it does not apply to the geometry. One > thing I have noticed is that it seems to have post backs twice because the > drop-down menu selection goes from "Cool to Warm" to "choose platter" > after I clicked apply properties. Could this be my sever response issue? > > > I think it probably is applying the color palette you choose to the > geometry. Think of the color palette as the starting point for your > coloring scheme, and from there you can add and remove colors from the > lookup table at will. For this reason, we don't keep the value you choose > for color palette in the drop-down box, because as soon as you adjust the > lookup table, that palette name would no longer match the lookup table > you're using. Since the default color palette is "Cool to Warm", you don't > notice any change when you choose that one again. And since your data > arrays have a numeric range of 0, you should just see blue. If you change > the color palette to "Red to Blue Rainbow", in your case, you will see the > data become all red, though the color palette drop-down will not change. > > > Also there is always latency between user inputs and visualization. What > I meant is that when users select and apply different properties to the > visualization, > it seems to take awhile to apply those properties. For example, color > management's representation and color selections. Could the latency be due > to our ubuntu sever specifications? > > > Some latency is expected, but I guess the question is how much latency you > are seeing when changing properties and applying them. A second to a > couple of seconds is normal to apply property changes, but it could vary > with the data you are visualizing. > > > Could you please provide me the latest master git HTTPS clone URL ? I can > try and rebuild the ParaViewWeb 4.4 with OSMesa. > > > We have moved to gitlab recently, and I don't think you should need an > account or anything to access the repo there. Try this url: > > https://gitlab.kitware.com/paraview/paraview.git > > On the main gitlab page (https://gitlab.kitware.com/paraview/paraview) > you should find links to the new development workflow documentation which > can guide you through the process. > > > My new question is that if we would like to start ParaViewWeb with our own > default view. For example, set the representation always to "Surface with > edges", Set color always to "T" , set palette always to "Cool to Warm" and > etc. Do we simply modify the HTML markup and possibly modify/add JavaScript > to those files in www directory? . What would be the best way to handle > this situation? > > > That is probably not the way I would go with it, but I think this is > beyond the scope of normal mailing list support questions. If you are > interested in customizing the Web Visualizer for your own needs, you could > consider a support contract. See here for some information: > > http://www.kitware.com/products/consulting.html > > Hope this helps. > > Cheers, > Scott > > > Sorry for all the questions. Thank you very much! > > Kai L > > > > On Friday, September 25, 2015 1:09 PM, Scott Wittenburg < > scott.wittenb...@kitware.com> wrote: > > > Hello Kai, > > So in doing some more testing it seems, that the problem may actually > be with the webgl exporter when you set the representation to "Surface with > edges". Can you try to see if you have the problem with just "Surface"? > In that case, there is potentially a bug in the geometry exporter. > > Regarding the stl file issue, I did follow the same steps to build > ParaViewWeb which you provided (just using hardware rendering rather than > OSMesa) and I see the same issue you described. So in this case, it seems > like maybe some commit since the 4.4 release has fixed an issue with the > stl reader. If you are able to get the latest master and build it, that > could fix your stl loading problem. > > Hope this helps. > > Cheers, > Scott > > > On Fri, Sep 25, 2015 at 12:45 PM, kai liu <liuwu...@yahoo.com> wrote: > > 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 src > cd src > git checkout v4.4.0 > git 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 src > cd src > git submodule update --init > > > > I have put my responses inline below again .... > > > > > On Fri, Sep 25, 2015 at 9:15 AM, kai liu <liuwu...@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 > 461 > vtkSTLReader (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 784 > vtkPVCompositeDataPipeline (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 src > cd src > git checkout v4.4.0 > git 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. > > [image: Inline image] > > > > > 2015-09-23 17:33:52-0400 [-] Log opened. > 2015-09-23 17:33:53-0400 [-] Site starting on 9009 > 2015-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 reaper > 2015-09-23 17:33:53-0400 [HTTPChannel,0,127.0.0.1] on_connect: connection > count = 1 > pvpython: > /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 ON > PARAVIEW_BUILD_QT_GUI OFF > CMAKE_INSTALL_PREFIX /.../ParaView/install > VTK_USE_X OFF > OPENGL_INCLUDE_DIR /opt/mesa/9.2.2/llvmpipe/include > OPENGL_gl_LIBRARY > OPENGL_glu_LIBRARY /opt/mesa/9.2.2/llvmpipe/lib/libGLU.so > > ... > > [Message clipped] > > > > > > > > > > > > > > -- > Cory Quammen > R&D Engineer > Kitware, Inc. > > > -- Cory Quammen R&D Engineer Kitware, Inc.
_______________________________________________ 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