Re: [Paraview] [EXTERNAL] Client/Server connection problems
I learned something new! Although I don't now how I managed to enable it, that was the problem. Thanks. From: Scott, W Alan wasc...@sandia.govmailto:wasc...@sandia.gov Date: Tuesday, January 14, 2014 6:59 PM To: Nathan Fabian ndfa...@sandia.govmailto:ndfa...@sandia.gov, Utkarsh Ayachit utkarsh.ayac...@kitware.commailto:utkarsh.ayac...@kitware.com Cc: paraview@paraview.orgmailto:paraview@paraview.org paraview@paraview.orgmailto:paraview@paraview.org Subject: RE: [Paraview] [EXTERNAL] Client/Server connection problems You compiled it in? '-DPARAVIEW_ALWAYS_SECURE_CONNECTION:BOOL=ON ' From: Fabian, Nathan Sent: Tuesday, January 14, 2014 5:41 PM To: Fabian, Nathan; Utkarsh Ayachit; Scott, W Alan Cc: paraview@paraview.orgmailto:paraview@paraview.org Subject: Re: [Paraview] [EXTERNAL] Client/Server connection problems Okay, I figured it out, although I'm still confused. Resolution add -connect_id to both cluster and desktop. The cluster reverse connecting was handshaking with an appended connect_id. I had initially tried not using a connect_id, but it errors out saying it's required. The desktop doesn't have one, unless I add it in on the command line run. Any idea why the server is requiring one? Also is there a way to add in the connect_id through the GUI as opposed to through the command line? Thanks, From: Fabian, Nathan Fabian ndfa...@sandia.govmailto:ndfa...@sandia.gov Date: Monday, January 13, 2014 5:42 PM To: Utkarsh Ayachit utkarsh.ayac...@kitware.commailto:utkarsh.ayac...@kitware.com, Scott, W Alan wasc...@sandia.govmailto:wasc...@sandia.gov Cc: paraview@paraview.orgmailto:paraview@paraview.org paraview@paraview.orgmailto:paraview@paraview.org Subject: Re: [Paraview] [EXTERNAL] Client/Server connection problems Thanks for the tip. I'll try this out and let you know how it goes. From: Utkarsh Ayachit utkarsh.ayac...@kitware.commailto:utkarsh.ayac...@kitware.com Date: Saturday, January 11, 2014 7:43 AM To: Scott, W Alan wasc...@sandia.govmailto:wasc...@sandia.gov Cc: Nathan Fabian ndfa...@sandia.govmailto:ndfa...@sandia.gov, paraview@paraview.orgmailto:paraview@paraview.org paraview@paraview.orgmailto:paraview@paraview.org Subject: Re: [Paraview] [EXTERNAL] Client/Server connection problems Nathan, First, let me clarify what is checked, since what Alan said isn't entirely correct. What comprises the handshake? The handshake is a string of the following form: paraview.MajorNumber.MinorNumber If a connect-id is specified then the handshake becomes: paraview.MajorNumber.MinorNumber.connect_id.ConnectId The client and the root-server node exchange these strings. If either side concludes that they don't match, the connection is terminated. To debug, you can put a cout in vtkTCPNetworkAccessManager::ConnectToRemove(), or vtkTCPNetworkAccessManager::ParaViewHandshake() call on both(or either) sides to print the relevant string. How is the MajorNumber/MinorNumber determined? = First, it's hardcoded in the top level CMakeLists.txt. Any time a version number changes, this is manually updated. So on git/master, this will change when we changed from 4.0.1 to 4.1.0-RC1. Thus, even before the official release the version number has changed. This could explain why two builds from git master may not always work with each other. Secondly, if the source repository is a git repository (nothing to do with whether it has access to the Internet), then the version is determined by using the git command git describe. By making sure we tag the repository when the CMakeLists.txt change happens, we ensure that git describe results in version numbers of the form MajorNumber.MinorNumber-FOO-BAR. We can ignore FOO/BAR for now. These are extra annotations that us determine exactly what source version you're using, esp when doing git/master builds. The thing to note is that the handshake only uses the MajorNumber and MinorNumber. So even if your git/master checkouts are from slightly different points in history, they can work together (unless of course, the two checkout happened to be across a version number change). Hope that clarifies things. Putting a cout in vtkTCPNetworkAccessManager and comparing the handshake strings would be a good start to debug this. Utkarsh On Fri, Jan 10, 2014 at 7:00 PM, Scott, W Alan wasc...@sandia.govmailto:wasc...@sandia.gov wrote: Then no, that isn't the issue. One more thing to try - and I don't completely know how to do it. (i.e., ask Kitware). I believe that they now look at not just ParaView version numbers, but also git checkin tags or whatever it is called. If the two trees are basically the same, and ANYONE touched the tree between pulls, that is your problem. This has been an issue for me when one of the two (client or server) is behind a firewall, but the other can connect back to Kitware and find that git tag. Make sure the source trees
Re: [Paraview] [EXTERNAL] Client/Server connection problems
Okay, I figured it out, although I'm still confused. Resolution add -connect_id to both cluster and desktop. The cluster reverse connecting was handshaking with an appended connect_id. I had initially tried not using a connect_id, but it errors out saying it's required. The desktop doesn't have one, unless I add it in on the command line run. Any idea why the server is requiring one? Also is there a way to add in the connect_id through the GUI as opposed to through the command line? Thanks, From: Fabian, Nathan Fabian ndfa...@sandia.govmailto:ndfa...@sandia.gov Date: Monday, January 13, 2014 5:42 PM To: Utkarsh Ayachit utkarsh.ayac...@kitware.commailto:utkarsh.ayac...@kitware.com, Scott, W Alan wasc...@sandia.govmailto:wasc...@sandia.gov Cc: paraview@paraview.orgmailto:paraview@paraview.org paraview@paraview.orgmailto:paraview@paraview.org Subject: Re: [Paraview] [EXTERNAL] Client/Server connection problems Thanks for the tip. I'll try this out and let you know how it goes. From: Utkarsh Ayachit utkarsh.ayac...@kitware.commailto:utkarsh.ayac...@kitware.com Date: Saturday, January 11, 2014 7:43 AM To: Scott, W Alan wasc...@sandia.govmailto:wasc...@sandia.gov Cc: Nathan Fabian ndfa...@sandia.govmailto:ndfa...@sandia.gov, paraview@paraview.orgmailto:paraview@paraview.org paraview@paraview.orgmailto:paraview@paraview.org Subject: Re: [Paraview] [EXTERNAL] Client/Server connection problems Nathan, First, let me clarify what is checked, since what Alan said isn't entirely correct. What comprises the handshake? The handshake is a string of the following form: paraview.MajorNumber.MinorNumber If a connect-id is specified then the handshake becomes: paraview.MajorNumber.MinorNumber.connect_id.ConnectId The client and the root-server node exchange these strings. If either side concludes that they don't match, the connection is terminated. To debug, you can put a cout in vtkTCPNetworkAccessManager::ConnectToRemove(), or vtkTCPNetworkAccessManager::ParaViewHandshake() call on both(or either) sides to print the relevant string. How is the MajorNumber/MinorNumber determined? = First, it's hardcoded in the top level CMakeLists.txt. Any time a version number changes, this is manually updated. So on git/master, this will change when we changed from 4.0.1 to 4.1.0-RC1. Thus, even before the official release the version number has changed. This could explain why two builds from git master may not always work with each other. Secondly, if the source repository is a git repository (nothing to do with whether it has access to the Internet), then the version is determined by using the git command git describe. By making sure we tag the repository when the CMakeLists.txt change happens, we ensure that git describe results in version numbers of the form MajorNumber.MinorNumber-FOO-BAR. We can ignore FOO/BAR for now. These are extra annotations that us determine exactly what source version you're using, esp when doing git/master builds. The thing to note is that the handshake only uses the MajorNumber and MinorNumber. So even if your git/master checkouts are from slightly different points in history, they can work together (unless of course, the two checkout happened to be across a version number change). Hope that clarifies things. Putting a cout in vtkTCPNetworkAccessManager and comparing the handshake strings would be a good start to debug this. Utkarsh On Fri, Jan 10, 2014 at 7:00 PM, Scott, W Alan wasc...@sandia.govmailto:wasc...@sandia.gov wrote: Then no, that isn't the issue. One more thing to try - and I don't completely know how to do it. (i.e., ask Kitware). I believe that they now look at not just ParaView version numbers, but also git checkin tags or whatever it is called. If the two trees are basically the same, and ANYONE touched the tree between pulls, that is your problem. This has been an issue for me when one of the two (client or server) is behind a firewall, but the other can connect back to Kitware and find that git tag. Make sure the source trees are exactly the same. Alan -Original Message- From: Fabian, Nathan Sent: Friday, January 10, 2014 4:57 PM To: Scott, W Alan; paraview@paraview.orgmailto:paraview@paraview.org Subject: Re: [EXTERNAL] [Paraview] Client/Server connection problems That sounded promising, but it doesn't appear to have worked. I deleted everything under .config/ParaView and .config/Kitware on both machines, still getting the same error. On 1/10/14 4:45 PM, Scott, W Alan wasc...@sandia.govmailto:wasc...@sandia.gov wrote: Delete your configuration files. Corrupt configuration files sometimes cause this. Surprisingly, on one client of mine, the first connect works, the configuration file gets written, and you never get another successful connect using that configuration file. I haven't chased this down yes, hoping it goes away
Re: [Paraview] [EXTERNAL] Client/Server connection problems
Thanks for the tip. I'll try this out and let you know how it goes. From: Utkarsh Ayachit utkarsh.ayac...@kitware.commailto:utkarsh.ayac...@kitware.com Date: Saturday, January 11, 2014 7:43 AM To: Scott, W Alan wasc...@sandia.govmailto:wasc...@sandia.gov Cc: Nathan Fabian ndfa...@sandia.govmailto:ndfa...@sandia.gov, paraview@paraview.orgmailto:paraview@paraview.org paraview@paraview.orgmailto:paraview@paraview.org Subject: Re: [Paraview] [EXTERNAL] Client/Server connection problems Nathan, First, let me clarify what is checked, since what Alan said isn't entirely correct. What comprises the handshake? The handshake is a string of the following form: paraview.MajorNumber.MinorNumber If a connect-id is specified then the handshake becomes: paraview.MajorNumber.MinorNumber.connect_id.ConnectId The client and the root-server node exchange these strings. If either side concludes that they don't match, the connection is terminated. To debug, you can put a cout in vtkTCPNetworkAccessManager::ConnectToRemove(), or vtkTCPNetworkAccessManager::ParaViewHandshake() call on both(or either) sides to print the relevant string. How is the MajorNumber/MinorNumber determined? = First, it's hardcoded in the top level CMakeLists.txt. Any time a version number changes, this is manually updated. So on git/master, this will change when we changed from 4.0.1 to 4.1.0-RC1. Thus, even before the official release the version number has changed. This could explain why two builds from git master may not always work with each other. Secondly, if the source repository is a git repository (nothing to do with whether it has access to the Internet), then the version is determined by using the git command git describe. By making sure we tag the repository when the CMakeLists.txt change happens, we ensure that git describe results in version numbers of the form MajorNumber.MinorNumber-FOO-BAR. We can ignore FOO/BAR for now. These are extra annotations that us determine exactly what source version you're using, esp when doing git/master builds. The thing to note is that the handshake only uses the MajorNumber and MinorNumber. So even if your git/master checkouts are from slightly different points in history, they can work together (unless of course, the two checkout happened to be across a version number change). Hope that clarifies things. Putting a cout in vtkTCPNetworkAccessManager and comparing the handshake strings would be a good start to debug this. Utkarsh On Fri, Jan 10, 2014 at 7:00 PM, Scott, W Alan wasc...@sandia.govmailto:wasc...@sandia.gov wrote: Then no, that isn't the issue. One more thing to try - and I don't completely know how to do it. (i.e., ask Kitware). I believe that they now look at not just ParaView version numbers, but also git checkin tags or whatever it is called. If the two trees are basically the same, and ANYONE touched the tree between pulls, that is your problem. This has been an issue for me when one of the two (client or server) is behind a firewall, but the other can connect back to Kitware and find that git tag. Make sure the source trees are exactly the same. Alan -Original Message- From: Fabian, Nathan Sent: Friday, January 10, 2014 4:57 PM To: Scott, W Alan; paraview@paraview.orgmailto:paraview@paraview.org Subject: Re: [EXTERNAL] [Paraview] Client/Server connection problems That sounded promising, but it doesn't appear to have worked. I deleted everything under .config/ParaView and .config/Kitware on both machines, still getting the same error. On 1/10/14 4:45 PM, Scott, W Alan wasc...@sandia.govmailto:wasc...@sandia.gov wrote: Delete your configuration files. Corrupt configuration files sometimes cause this. Surprisingly, on one client of mine, the first connect works, the configuration file gets written, and you never get another successful connect using that configuration file. I haven't chased this down yes, hoping it goes away with the new version. But... If this is the problem, please let me know. You may have an easier setup that we can use to get to the root cause of the problem. Alan -Original Message- From: paraview-boun...@paraview.orgmailto:paraview-boun...@paraview.org [mailto:paraview-boun...@paraview.orgmailto:paraview-boun...@paraview.org] On Behalf Of Fabian, Nathan Sent: Friday, January 10, 2014 3:59 PM To: paraview@paraview.orgmailto:paraview@paraview.org Subject: [EXTERNAL] [Paraview] Client/Server connection problems Hi, I've been trying to figure this one out for a few days and I'm finally giving in for help. I've got a code base on my server that should be a duplicate of the one on my desktop, built differently. In one case I did pulls from master at the same time. I've more recently just tried pulling directly from my desktop and building clean on both. I've also tried disabling MPI on the desktop side and connecting
[Paraview] Client/Server connection problems
Hi, I've been trying to figure this one out for a few days and I'm finally giving in for help. I've got a code base on my server that should be a duplicate of the one on my desktop, built differently. In one case I did pulls from master at the same time. I've more recently just tried pulling directly from my desktop and building clean on both. I've also tried disabling MPI on the desktop side and connecting without MPI on the server side. Still I'm getting the following message when trying to reverse connect: ERROR: In /projects/coprocessing/ParaView/ParaViewCore/ClientServerCore/Core/vtkTCPNe tworkAccessManager.cxx, line 330 vtkTCPNetworkAccessManager (0x135a3150): Failed to connect to xyz.sandia.gov:1. Client-Server Handshake failed. Please verify that the client and server versions are compatible with each other, and that 'connect-id', if any, matches. And then each attempt to connect gives this on the desktop: Accepting connection(s): xyz.sandia.gov:1 Evidence that some sort of communication has worked. This has worked with master builds in the past. I'm not sure what I changed, but there's plenty I have that may have influenced this. Any suggestions on where to start looking? Thanks, Nathan. ___ 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
Re: [Paraview] [EXTERNAL] Client/Server connection problems
That sounded promising, but it doesn't appear to have worked. I deleted everything under .config/ParaView and .config/Kitware on both machines, still getting the same error. On 1/10/14 4:45 PM, Scott, W Alan wasc...@sandia.gov wrote: Delete your configuration files. Corrupt configuration files sometimes cause this. Surprisingly, on one client of mine, the first connect works, the configuration file gets written, and you never get another successful connect using that configuration file. I haven't chased this down yes, hoping it goes away with the new version. But... If this is the problem, please let me know. You may have an easier setup that we can use to get to the root cause of the problem. Alan -Original Message- From: paraview-boun...@paraview.org [mailto:paraview-boun...@paraview.org] On Behalf Of Fabian, Nathan Sent: Friday, January 10, 2014 3:59 PM To: paraview@paraview.org Subject: [EXTERNAL] [Paraview] Client/Server connection problems Hi, I've been trying to figure this one out for a few days and I'm finally giving in for help. I've got a code base on my server that should be a duplicate of the one on my desktop, built differently. In one case I did pulls from master at the same time. I've more recently just tried pulling directly from my desktop and building clean on both. I've also tried disabling MPI on the desktop side and connecting without MPI on the server side. Still I'm getting the following message when trying to reverse connect: ERROR: In /projects/coprocessing/ParaView/ParaViewCore/ClientServerCore/Core/vtkTCPN e tworkAccessManager.cxx, line 330 vtkTCPNetworkAccessManager (0x135a3150): Failed to connect to xyz.sandia.gov:1. Client-Server Handshake failed. Please verify that the client and server versions are compatible with each other, and that 'connect-id', if any, matches. And then each attempt to connect gives this on the desktop: Accepting connection(s): xyz.sandia.gov:1 Evidence that some sort of communication has worked. This has worked with master builds in the past. I'm not sure what I changed, but there's plenty I have that may have influenced this. Any suggestions on where to start looking? Thanks, Nathan. ___ 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 ___ 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
[Paraview] Calculator removes cell data
Hi, I just submitted a bug on this: http://paraview.org/Bug/view.php?id=12944 But I'm wondering if there's a way to work around it. The problem is that I'm trying to modify the coordinates insitu using the displacement, but that ends up deleting the cell data. Is there any way to merge the cell data from one data source into the another? Something like this: InputData = InputData() #get the input data from coprocessing Calculator = Calculator () #removes the cell data Merged = CopyCellDataFromAtoB (InputData, Calculator) #copies the cell data from InputData, but uses modified mesh from Calculator Thanks, Nathan. ___ 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
[Paraview] Screen flicker
Hi, I've had a problem recently with paraview causing my whole screen to flicker when it's rendering. I've tried recompiling with different versions of Qt and with carbon vs cocoa with no luck either way. It seems to be an opengl problem because it only happens when I'm rendering surfaces or something that uses the card. Has anyone else experienced this or know how to fix it? It's paraview 3.12 rc1 (latest git) Mac Pro GeForce 8600M GT, OSX 10.5.8 Thanks, Nathan. ___ 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
Re: [Paraview] Screen flicker
One point of information I forgot to mention. It does not appear to happen at all with a DMG downloaded from ParaView.org. This is what led me to think it's my fault somehow. On 9/7/11 12:49 PM, Utkarsh Ayachit utkarsh.ayac...@kitware.com wrote: Nathan, I've seen this issue with my macbook pro too. The solution included a visit to the MacStore and getting the motherboard replaced :). Hope your laptop is still under warranty. Also, try switching to the high performance graphics card. I had the issue when my settings were set to use the better battery life graphics card. Utkarsh On Wed, Sep 7, 2011 at 2:41 PM, Fabian, Nathan ndfa...@sandia.gov wrote: Hi, I've had a problem recently with paraview causing my whole screen to flicker when it's rendering. I've tried recompiling with different versions of Qt and with carbon vs cocoa with no luck either way. It seems to be an opengl problem because it only happens when I'm rendering surfaces or something that uses the card. Has anyone else experienced this or know how to fix it? It's paraview 3.12 rc1 (latest git) Mac Pro GeForce 8600M GT, OSX 10.5.8 Thanks, Nathan. ___ 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 ___ 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
[Paraview] targets not in export set
Hi, When I enable install with development install, I'm getting the errors below. Am I missing a flag for install CS wrapped or something like that? This is on a git pull from about 20 minutes ago. Thanks, Nathan. CMake Error: INSTALL(EXPORT ParaViewTargets ...) includes target vtkPVCommon which requires target vtkIOCS that is not in the export set. CMake Error: INSTALL(EXPORT ParaViewTargets ...) includes target vtkPVVTKExtensions which requires target vtkPVCommonCS that is not in the export set. CMake Error: INSTALL(EXPORT ParaViewTargets ...) includes target vtkPVVTKExtensions which requires target vtkXdmfCS that is not in the export set. CMake Error: INSTALL(EXPORT ParaViewTargets ...) includes target vtkPVVTKExtensions which requires target vtkHybridCS that is not in the export set. CMake Error: INSTALL(EXPORT ParaViewTargets ...) includes target vtkPVVTKExtensions which requires target vtkParallelCS that is not in the export set. CMake Error: INSTALL(EXPORT ParaViewTargets ...) includes target vtkPVVTKExtensions which requires target vtkVolumeRenderingCS that is not in the export set. CMake Error: INSTALL(EXPORT ParaViewTargets ...) includes target vtkPVVTKExtensions which requires target vtkWidgetsCS that is not in the export set. CMake Error: INSTALL(EXPORT ParaViewTargets ...) includes target vtkPVVTKExtensions which requires target vtkViewsCS that is not in the export set. CMake Error: INSTALL(EXPORT ParaViewTargets ...) includes target vtkPVVTKExtensions which requires target vtkChartsCS that is not in the export set. CMake Error: INSTALL(EXPORT ParaViewTargets ...) includes target vtkPVClientServerCore which requires target vtkPVVTKExtensionsCS that is not in the export set. CMake Error: INSTALL(EXPORT ParaViewTargets ...) includes target vtkPVServerImplementation which requires target vtkPVClientServerCoreCS that is not in the export set. CMake Error: INSTALL(EXPORT ParaViewTargets ...) includes target vtkPVServerManager which requires target vtkPVServerImplementationCS that is not in the export set. ___ 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
[Paraview] Mesa-7.8.2 incompatible?
Hi, I've built a recent pull of the master branch against Mesa-7.8.2. I'm building pure Offscreen with no X or GL. When I try to render I get the following fatal error: main/renderbuffer.c:1924: _mesa_add_renderbuffer: Assertion `bufferName == BUFFER_DEPTH || bufferName == BUFFER_STENCIL || fb-Attachment[bufferName].Renderbuffer == ((void *)0)' failed. I get this in my own coprocessing app, but I also tested pvserver connected via client elsewhere and got the same error when the render started. When I build with GL both apps work fine. Any suggestions would be greatly appreciated. Thanks, Nathan. ___ 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
Re: [Paraview] Mesa-7.8.2 incompatible?
Yep. 7.9 works great. I've used 7.8.2 with 3.8.x. Is Mesa something people should expect to upgrade going to paraview 3.10? On 2/15/11 2:40 PM, David Partyka david.part...@kitware.com wrote: Use an older (7.6?) or newer mesa (7.9). On Tue, Feb 15, 2011 at 4:38 PM, Fabian, Nathan ndfa...@sandia.gov wrote: Hi, I've built a recent pull of the master branch against Mesa-7.8.2. I'm building pure Offscreen with no X or GL. When I try to render I get the following fatal error: main/renderbuffer.c:1924: _mesa_add_renderbuffer: Assertion `bufferName == BUFFER_DEPTH || bufferName == BUFFER_STENCIL || fb-Attachment[bufferName].Renderbuffer == ((void *)0)' failed. I get this in my own coprocessing app, but I also tested pvserver connected via client elsewhere and got the same error when the render started. When I build with GL both apps work fine. Any suggestions would be greatly appreciated. Thanks, Nathan. ___ 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://www.paraview.org/mailman/listinfo/paraview ___ 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
Re: [Paraview] Fwd: Amazon EC2 Cluster + Paraview
Actually, the error I saw was related to it trying to include a wrong
renderwindow.h ..
However, your error is similar. It looks like it's got the wrong directory for
including exodus headers, since it includes
${CMAKE_SOURCE_DIR}/Utilities/exodusii/include
when it should probably be
${CMAKE_SOURCE_DIR}/VTK/Utilities/exodusii/include
if it's building inside Paraview. I'm not knowledgeable enough to say what the
true answer is, since I think it's not always built inside paraview.
The shorter answer may be just to disable XDMF_BUILD_UTILS in your CMake config.
On 2/12/11 11:51 AM, Matthew Dillon mrdil...@alaska.edu wrote:
I am guessing that this error is related to the error you mentioned below...
/home/ubuntu/ParaView-3.8.1/Utilities/Xdmf2/libsrc/utils/XdmfExodusReader.cxx:27:22:
error: exodusII.h: No such file or directory
I have no need for the exodusii reader, I didn't see anywhere that I could
disable it in cmake
On Fri, Feb 11, 2011 at 4:37 PM, Fabian, Nathan ndfa...@sandia.gov wrote:
The OSMESA_LIBRARY should also point to libOSMesa.so
(btw you can also compile leaving OPENGL_gl_LIBRARY and OPENGL_glu_LIBRARY
empty. I found I needed to do this when compiling static to avoid link errors
in, I think, the XDMF library).
On 2/11/11 6:32 PM, Matthew Dillon mrdil...@alaska.edu
http://mrdil...@alaska.edu wrote:
Nathan,
Thanks for the reply. That cleared out most of the warnings. I am left with:
WARNING: Target vtkRendering requests linking to directory
/home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is
dropping the item.
WARNING: Target vtkRendering requests linking to directory
/home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is
dropping the item.
WARNING: Target vtkVolumeRendering requests linking to directory
/home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is
dropping the item.
which seems kind of critical to me... I am sure i am missing something else,
but not sure what:
From my cmake list -
OPENGL_INCLUDE_DIR /home/ubuntu/osmesa/include
OPENGL_gl_LIBRARY/home/ubuntu/osmesa/lib/libOSMesa.so
OPENGL_glu_LIBRARY /home/ubuntu/osmesa/lib/libGLU.so
OPENGL_xmesa_INCLUDE_DIR OPENGL_xmesa_INCLUDE_DIR-NOTFOUND
OSMESA_INCLUDE_DIR /home/ubuntu/osmesa/include
OSMESA_LIBRARY /home/ubuntu/osmesa/lib
On Fri, Feb 11, 2011 at 4:19 PM, Fabian, Nathan ndfa...@sandia.gov
http://ndfa...@sandia.gov wrote:
The cmake variable needs to point to the library itself like:
/home/ubuntu/osmesa/lib/libOSMesa.so
On 2/11/11 6:16 PM, Matthew Dillon mrdil...@alaska.edu
http://mrdil...@alaska.edu http://mrdil...@alaska.edu wrote:
Hmm, I was greeted with a few warnings when generating the cmake build files:
/begin quote
WARNING: Target vtkRendering requests linking to directory
/home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is
dropping the item.
WARNING: Target vtkRendering requests linking to directory
/home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is
dropping the item.
WARNING: Target vtkVolumeRendering requests linking to directory
/home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is
dropping the item.
WARNING: Target icet requests linking to directory
/home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is
dropping the item.
WARNING: Target icet_mpi requests linking to directory
/home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is
dropping the item.
WARNING: Target icet_mpi requests linking to directory
/home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is
dropping the item.
WARNING: Target icet_strategies requests linking to directory
/home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is
dropping the item.
WARNING: Target icet_strategies requests linking to directory
/home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is
dropping the item.
WARNING: Target vtkPVFilters requests linking to directory
/home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is
dropping the item.
WARNING: Target vtkPVFiltersCS requests linking to directory
/home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is
dropping the item.
WARNING: Target vtkPVFiltersPython requests linking to directory
/home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is
dropping the item.
WARNING: Target vtkPVFiltersPythonD requests linking to directory
/home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is
dropping the item.
WARNING: Target ServersFiltersPrintSelf requests linking to directory
/home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is
dropping the item.
WARNING: Target TestExtractHistogram requests linking to directory
/home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is
dropping
Re: [Paraview] Fwd: Amazon EC2 Cluster + Paraview
The OSMESA_LIBRARY should also point to libOSMesa.so (btw you can also compile leaving OPENGL_gl_LIBRARY and OPENGL_glu_LIBRARY empty. I found I needed to do this when compiling static to avoid link errors in, I think, the XDMF library). On 2/11/11 6:32 PM, Matthew Dillon mrdil...@alaska.edu wrote: Nathan, Thanks for the reply. That cleared out most of the warnings. I am left with: WARNING: Target vtkRendering requests linking to directory /home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is dropping the item. WARNING: Target vtkRendering requests linking to directory /home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is dropping the item. WARNING: Target vtkVolumeRendering requests linking to directory /home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is dropping the item. which seems kind of critical to me... I am sure i am missing something else, but not sure what: From my cmake list - OPENGL_INCLUDE_DIR /home/ubuntu/osmesa/include OPENGL_gl_LIBRARY/home/ubuntu/osmesa/lib/libOSMesa.so OPENGL_glu_LIBRARY /home/ubuntu/osmesa/lib/libGLU.so OPENGL_xmesa_INCLUDE_DIR OPENGL_xmesa_INCLUDE_DIR-NOTFOUND OSMESA_INCLUDE_DIR /home/ubuntu/osmesa/include OSMESA_LIBRARY /home/ubuntu/osmesa/lib On Fri, Feb 11, 2011 at 4:19 PM, Fabian, Nathan ndfa...@sandia.gov wrote: The cmake variable needs to point to the library itself like: /home/ubuntu/osmesa/lib/libOSMesa.so On 2/11/11 6:16 PM, Matthew Dillon mrdil...@alaska.edu http://mrdil...@alaska.edu wrote: Hmm, I was greeted with a few warnings when generating the cmake build files: /begin quote WARNING: Target vtkRendering requests linking to directory /home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is dropping the item. WARNING: Target vtkRendering requests linking to directory /home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is dropping the item. WARNING: Target vtkVolumeRendering requests linking to directory /home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is dropping the item. WARNING: Target icet requests linking to directory /home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is dropping the item. WARNING: Target icet_mpi requests linking to directory /home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is dropping the item. WARNING: Target icet_mpi requests linking to directory /home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is dropping the item. WARNING: Target icet_strategies requests linking to directory /home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is dropping the item. WARNING: Target icet_strategies requests linking to directory /home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is dropping the item. WARNING: Target vtkPVFilters requests linking to directory /home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is dropping the item. WARNING: Target vtkPVFiltersCS requests linking to directory /home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is dropping the item. WARNING: Target vtkPVFiltersPython requests linking to directory /home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is dropping the item. WARNING: Target vtkPVFiltersPythonD requests linking to directory /home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is dropping the item. WARNING: Target ServersFiltersPrintSelf requests linking to directory /home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is dropping the item. WARNING: Target TestExtractHistogram requests linking to directory /home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is dropping the item. WARNING: Target TestExtractScatterPlot requests linking to directory /home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is dropping the item. WARNING: Target TestMPI requests linking to directory /home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is dropping the item. WARNING: Target vtkPVServerManager requests linking to directory /home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is dropping the item. WARNING: Target vtkPVServerManagerPython requests linking to directory /home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is dropping the item. WARNING: Target vtkPVServerManagerPythonD requests linking to directory /home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is dropping the item. WARNING: Target vtkSMExtractDocumentation-real requests linking to directory /home/ubuntu/osmesa/lib. Targets may link only to libraries. CMake is dropping the item. WARNING: Target ServerManagerStateLoader requests linking to directory /home/ubuntu/osmesa/lib. Targets may link only
Re: [Paraview] CoProcessing - Export State
Well part of my problem was (and maybe all of it except I built clean, so I can't verify) that there was a switch from Utilities/VTKPythonWrapping to Utilities/VTKPythonWrapping/site-packages for the PYTHONPATH that I was not aware of. I'm guessing the updates were installed there, but I was still looking at the old directory. On 9/1/10 5:21 PM, pat marion pat.mar...@kitware.com wrote: If you just run 'make paraview' it won't copy the py files. The target responsible for copying the py files is 'make paraview_pyc'. If you just run 'make' then the paraview_pyc target should re-execute when the timestamps have been modified on any of the py files. Maybe we should add a new target dependency rule? Pat On Wed, Sep 1, 2010 at 6:45 PM, Andy Bauer andy.ba...@kitware.com wrote: The other person that mentioned this problem also didn't seem to have the servermanager.py file updated in the build directory even though they updated their code in the source tree. I'll check on that to see why it's happening. Thanks, Andy On Wed, Sep 1, 2010 at 6:16 PM, Fabian, Nathan ndfa...@sandia.gov wrote: Okay thanks. Apparently, I'm doing some version of building that includes not bringing those updates over from the src directory to the build directory... On 9/1/10 4:08 PM, Andy Bauer andy.ba...@kitware.com http://andy.ba...@kitware.com wrote: This was fixed a little while ago. Try updating paraview if you can. The change servermanager.py is: @@ -796,6 +796,10 @@ class ArraySelectionProperty( VectorProperty): elif len(values) == 2: if isinstance(values[0], str): val = str(ASSOCIATIONS[values[0]]) +else: +# In case user didn't specify valid association, +# just pick POINTS. +val = str(ASSOCIATIONS['POINTS']) self.SMProperty.SetElement(3, str(val)) self.SMProperty.SetElement(4, values[1]) else: Andy On Wed, Sep 1, 2010 at 5:43 PM, Fabian, Nathan ndfa...@sandia.gov http://ndfa...@sandia.gov wrote: Hi, When I export state with the image data into the coprocessing python script it includes some properties which don't appear when I use coprocessing. For instance, DataRepresentation1.SelectOrientationVectors = [None, '']. It complains with: File /Users/ndfabia/Desktop/Work/ParaView_build/Utilities/VTKPythonWrapping/para view/servermanager.py, line 2367, in setProperty return self.SetPropertyWithName(propName, value) File /Users/ndfabia/Desktop/Work/ParaView_build/Utilities/VTKPythonWrapping/para view/servermanager.py, line 256, in SetPropertyWithName prop.SetData(arg) File /Users/ndfabia/Desktop/Work/ParaView_build/Utilities/VTKPythonWrapping/para view/servermanager.py, line 799, in SetData self.SMProperty.SetElement(3, str(val)) UnboundLocalError: local variable 'val' referenced before assignment It's using the same paraview to export the script as is running insitu... Does anyone have a suggestion as to what I'm missing? Thanks, Nathan. ___ Powered by www.kitware.com http://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://www.paraview.org/mailman/listinfo/paraview ___ 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://www.paraview.org/mailman/listinfo/paraview ___ 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
[Paraview] CoProcessing - Export State
Hi, When I export state with the image data into the coprocessing python script it includes some properties which don't appear when I use coprocessing. For instance, DataRepresentation1.SelectOrientationVectors = [None, '']. It complains with: File /Users/ndfabia/Desktop/Work/ParaView_build/Utilities/VTKPythonWrapping/para view/servermanager.py, line 2367, in setProperty return self.SetPropertyWithName(propName, value) File /Users/ndfabia/Desktop/Work/ParaView_build/Utilities/VTKPythonWrapping/para view/servermanager.py, line 256, in SetPropertyWithName prop.SetData(arg) File /Users/ndfabia/Desktop/Work/ParaView_build/Utilities/VTKPythonWrapping/para view/servermanager.py, line 799, in SetData self.SMProperty.SetElement(3, str(val)) UnboundLocalError: local variable 'val' referenced before assignment It's using the same paraview to export the script as is running insitu... Does anyone have a suggestion as to what I'm missing? Thanks, Nathan. ___ 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
Re: [Paraview] CoProcessing - Export State
Okay thanks. Apparently, I'm doing some version of building that includes not bringing those updates over from the src directory to the build directory... On 9/1/10 4:08 PM, Andy Bauer andy.ba...@kitware.com wrote: This was fixed a little while ago. Try updating paraview if you can. The change servermanager.py is: @@ -796,6 +796,10 @@ class ArraySelectionProperty( VectorProperty): elif len(values) == 2: if isinstance(values[0], str): val = str(ASSOCIATIONS[values[0]]) +else: +# In case user didn't specify valid association, +# just pick POINTS. +val = str(ASSOCIATIONS['POINTS']) self.SMProperty.SetElement(3, str(val)) self.SMProperty.SetElement(4, values[1]) else: Andy On Wed, Sep 1, 2010 at 5:43 PM, Fabian, Nathan ndfa...@sandia.gov wrote: Hi, When I export state with the image data into the coprocessing python script it includes some properties which don't appear when I use coprocessing. For instance, DataRepresentation1.SelectOrientationVectors = [None, '']. It complains with: File /Users/ndfabia/Desktop/Work/ParaView_build/Utilities/VTKPythonWrapping/para view/servermanager.py, line 2367, in setProperty return self.SetPropertyWithName(propName, value) File /Users/ndfabia/Desktop/Work/ParaView_build/Utilities/VTKPythonWrapping/para view/servermanager.py, line 256, in SetPropertyWithName prop.SetData(arg) File /Users/ndfabia/Desktop/Work/ParaView_build/Utilities/VTKPythonWrapping/para view/servermanager.py, line 799, in SetData self.SMProperty.SetElement(3, str(val)) UnboundLocalError: local variable 'val' referenced before assignment It's using the same paraview to export the script as is running insitu... Does anyone have a suggestion as to what I'm missing? Thanks, Nathan. ___ 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://www.paraview.org/mailman/listinfo/paraview ___ 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
Re: [Paraview] CoProcessing question
Hi,
I originally tried the following on each piece:
SetOrigin(0,0,0)
SetSpacing(.1,.1,0)
SetExtent(0,xmax,ystart(myproc),ystop(myproc),0,0)
And when I output it to XMLPImageDataWriter, paraview couldn't read it
complaining about the extents. It actually correctly showed the first piece.
I could have sworn I talked to Utkarsh about it, but I can't find the
conversation... So it's quite possible there's a serious operator error on my
part.
The current solution is in Paraview under
CoProcessing/Adaptors/FortranAdaptors/NPICAdaptor That solution creates a
MultiBlockDataSet with one block (on each processor) which contains the image.
Nathan.
On 7/28/10 4:44 PM, Moreland, Kenneth kmo...@sandia.gov wrote:
John,
I don't have any experience with that, but I think Nathan Fabian telling me he
tried that and it didn't work. I don't remember why.
-Ken
On 7/28/10 3:25 PM, Biddiscombe, John A. biddi...@cscs.ch wrote:
Hold on a minute. Everything you said is quite right and I'm with you 100% -
Except. Suppose the pipeline places piece numbers in each update request -
which are converted to structured extents (can't remember exactly where in the
executive this will happen, but it will somewhere) - then the reader (or in
this case coprocessing library) produces pieces of data which in our case, will
not be the right pieces. We set the extents accordingly on out imagedata and
just past the results out. When the pipeline downstream receives all these
pieces, it will probably ignore the updateextent that was requested and use the
real extent on the actual dataobjects. No? yes?
It might work. Anyway. I'll try out some pieces and see what gives. Ideally the
coprocessing library will need a way of modifying the extents. I'll see if
there's a way of managing it. (I'll also see what the TableExtentTranslator
thingy does, though it may be the reverse of what we want).
Kenneth Moreland
*** Sandia National Laboratories
***
*** *** *** email: kmo...@sandia.gov
** *** ** phone: (505) 844-8919
*** web: http://www.cs.unm.edu/~kmorel
___
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
Re: [Paraview] node ordering mismatch when saving vtu as exodus and vice versa
Okay, this one I can repeat. I'll take a look. Thanks, Nathan. On 5/7/10 8:17 AM, pat marion pat.mar...@kitware.com wrote: I think you can repeat it like this: create wavelet source apply append datasets to convert to unstructured grid save as exodus, then reopen the saved file Pat On Fri, May 7, 2010 at 2:01 AM, Hom Nath Gharti hng.em...@gmail.com wrote: In my case it was Paraview 3.7 and 3.8 RC2. Thanks ___ 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
Re: [Paraview] node ordering mismatch when saving vtu as exodus and vice versa
I just tried opening the file and saved as a .e file and then opened the .e and did not notice any difference. What version of paraview is this happening? Thanks, Nathan. On 5/6/10 10:59 AM, Scott, W Alan wasc...@sandia.gov wrote: Please write this up as a bug in the ParaView bug tracker. Thanks, Alan -Original Message- From: paraview-boun...@paraview.org [mailto:paraview-boun...@paraview.org] On Behalf Of Hom Nath Gharti Sent: Thursday, May 06, 2010 1:42 AM To: ParaView Subject: [Paraview] node ordering mismatch when saving vtu as exodus and vice versa I think there is a mismatch in node ordering when we want to save vtu file as exodus and vice versa for 20-noded hexahedral meshes. This is due to the different node ordering scheme for VTK and exodus for this particular element type. e.g., if you open an attached vtu file, it is fine. If you save that as .e file and open looks different. That was due the different ordering! Thanks, HNG ___ 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 ___ 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
[Paraview] Process id from within pvbatch
Hi, Is there any way to get the local process id from within a python script? I can't seem to get hold of vtkMultiProcessController and can't find any other way through the modules... Thanks, Nathan. ___ 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
Re: [Paraview] Process id from within pvbatch
That did it. Thanks On 4/9/10 12:40 PM, Andy Bauer andy.ba...@kitware.com wrote: I think what you want is: pid = servermanager.vtkProcessModule.GetProcessModule().GetPartitionId() Andy On Fri, Apr 9, 2010 at 2:34 PM, Fabian, Nathan ndfa...@sandia.gov wrote: Hi, Is there any way to get the local process id from within a python script? I can't seem to get hold of vtkMultiProcessController and can't find any other way through the modules... Thanks, Nathan. ___ 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://www.paraview.org/mailman/listinfo/paraview ___ 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
[Paraview] Turn off text progress output in pvbatch
Hi, When I run pvbatch I get progress to stdout like this: vtkFilter(10) : [ .] vtkFilter(135) : [ .] vtkFilter(137) : [ .] vtkFilter(127) : [ .] vtkFilter(139) : [ .] How do I turn that off? Thanks, Nathan. ___ 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
Re: [Paraview] Turn off text progress output in pvbatch
Along a similar line, it seems like this might be convenient as a command line
parameter where when I'm running the script as a debug I would leave the output
on, but once I send it over to the cluster I'd just add the flag to disable it
in the qsub instead of needing to change the script.
On 9/2/09 6:06 PM, Moreland, Kenneth kmo...@sandia.gov wrote:
This is slightly tangential, but I always thought that there should be a method
to simply turn it on or off. Whenever I wanted to use this function, it was
really in a script where I simply wanted to suppress the messages. In order to
do that, I need to go through a weird process of checking the flag and then
toggling if it's on.
-Ken
On 9/2/09 5:10 PM, pat marion pat.mar...@kitware.com wrote:
servermanager.ToggleProgressPrinting()
Pat
On Wed, Sep 2, 2009 at 6:50 PM, Fabian, Nathanndfa...@sandia.gov wrote:
Hi,
When I run pvbatch I get progress to stdout like this:
vtkFilter(10) : [ .]
vtkFilter(135) : [ .]
vtkFilter(137) : [ .]
vtkFilter(127) : [ .]
vtkFilter(139) : [ .]
How do I turn that off?
Thanks,
Nathan.
___
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
___
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: kmo...@sandia.gov
** *** ** phone: (505) 844-8919
*** web: http://www.cs.unm.edu/~kmorel
___
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
