[Paraview] Glyph filters mask-points option only shows half side with vectors

[Carolin Helbig]

Hello,

I have got a problem with the behavior of the glyphs filter. I try to 
explain my approach and the problem:


- I calculated with the calculator filter: U*iHat + V*jHat
- After that I added the glyph filter
- If the "mask points" checkbox is NOT selected, all vectors are pictured
- If I select the checkbox "mask points", only half of the vectors are 
pictured
--> If I use the X+/- view it seams like only the vectors under the 
Y-axis or very close to it are shown
--> If I use the Y+/- view it seams like only the vectors under the 
X-axis or very close to it are shown


Does somebody know why there are only half of the vectors are shown if I 
use the "mask points" option?


Greetings,
Carolin.
___
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] Glyph filters mask-points option only shows half side with vectors

[David E DeMarle]

On Tue, Aug 28, 2012 at 5:59 AM, Carolin Helbig  wrote:
> Hello,
>
> I have got a problem with the behavior of the glyphs filter. I try to
> explain my approach and the problem:
>
> - I calculated with the calculator filter: U*iHat + V*jHat
> - After that I added the glyph filter
> - If the "mask points" checkbox is NOT selected, all vectors are pictured
> - If I select the checkbox "mask points", only half of the vectors are
> pictured
> --> If I use the X+/- view it seams like only the vectors under the Y-axis
> or very close to it are shown
> --> If I use the Y+/- view it seams like only the vectors under the X-axis
> or very close to it are shown
>

Please attach screen shots.

> Does somebody know why there are only half of the vectors are shown if I use
> the "mask points" option?

What is the setting of "Maximum Number Of Points", what is the setting
of "Random Mode" and how many points does the Information tab say
there are in your data?

> Greetings,
> Carolin.
> ___
> 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

Re: [Paraview] some ui issues

[Kyle Lutz]

Hi Burlen,

Could you try the panels with the newest ParaView from git?

The display button should move to the bottom if it is collapsed and
the properties section is filled up with widgets.

-kyle

On Wed, Aug 15, 2012 at 4:31 PM, Burlen Loring  wrote:
> Hi Kyle,
>
> Have you noticed that sources with 3d widgets (eg line source) have
> duplicate entries?
>
> I just pulled from master and saw the new property and display buttons to
> collapse their respective properties, that's nice! It would be great if when
> collapsed the display button would then move to the bottom of the widget
> freeing up real estate for the remaining properties.
>
> Burlen
>
>
> On 08/15/2012 09:20 AM, Burlen Loring wrote:
>>
>> Hi Kyle,
>>
>> Thanks, the following steps reproduce slice filter issue:
>>
>> start paraview, build the following pipeline:
>>
>> wavelet source -> slice
>>
>> in the pipeline browser:
>>
>> select wavelet, select slice, select wavelet
>>
>> The slice filter is marked modified.
>>
>> Is there going to be a way of undocking the display properties from the
>> object properties? In our filters/sources with a number of properties having
>> that real estate makes it easier to use.
>>
>> Burlen
>>
>> On 08/15/2012 08:43 AM, Kyle Lutz wrote:
>>>
>>> Hi Burlen,
>>>
>>> On Mon, Aug 13, 2012 at 8:50 AM, burlen  wrote:

 I've noticed that the slice filter is having similar issue: apply
 activated
 by selecting in the pipeline browser. In my panels this was because pv
 is
 creating/destroying the panel as the object is selected/deselected in
 the
 browser so I had to be more careful during the initialization not to
 mark
 the object as modified, it's probably a similar issue.
>>>
>>> Yes, this behavior has changed with the new panels. Property widgets
>>> should be lightweight and avoid doing any heavy computation or
>>> communication.
>>>
>>> Also, if you could give me a list of steps to reproduce incorrect
>>> modified flag issue I could take a look and fix it for you.
>>>
>>> Cheers,
>>> -kyle
>>
>>
>
___
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] some ui issues

[Burlen Loring]

Hi Kyle, It's looking great, and working well. I like your new design a lot.

Burlen

On 08/28/2012 07:09 AM, Kyle Lutz wrote:

Hi Burlen,

Could you try the panels with the newest ParaView from git?

The display button should move to the bottom if it is collapsed and
the properties section is filled up with widgets.

-kyle

On Wed, Aug 15, 2012 at 4:31 PM, Burlen Loring  wrote:

Hi Kyle,

Have you noticed that sources with 3d widgets (eg line source) have
duplicate entries?

I just pulled from master and saw the new property and display buttons to
collapse their respective properties, that's nice! It would be great if when
collapsed the display button would then move to the bottom of the widget
freeing up real estate for the remaining properties.

Burlen


On 08/15/2012 09:20 AM, Burlen Loring wrote:

Hi Kyle,

Thanks, the following steps reproduce slice filter issue:

start paraview, build the following pipeline:

wavelet source ->  slice

in the pipeline browser:

select wavelet, select slice, select wavelet

The slice filter is marked modified.

Is there going to be a way of undocking the display properties from the
object properties? In our filters/sources with a number of properties having
that real estate makes it easier to use.

Burlen

On 08/15/2012 08:43 AM, Kyle Lutz wrote:

Hi Burlen,

On Mon, Aug 13, 2012 at 8:50 AM, burlen   wrote:

I've noticed that the slice filter is having similar issue: apply
activated
by selecting in the pipeline browser. In my panels this was because pv
is
creating/destroying the panel as the object is selected/deselected in
the
browser so I had to be more careful during the initialization not to
mark
the object as modified, it's probably a similar issue.

Yes, this behavior has changed with the new panels. Property widgets
should be lightweight and avoid doing any heavy computation or
communication.

Also, if you could give me a list of steps to reproduce incorrect
modified flag issue I could take a look and fix it for you.

Cheers,
-kyle




___
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] Python interpreter not being created for coprocessing?

[Andy Bauer]

Hmm, ParaView has been undergoing a lot of changes lately so it's been a
bit unstable. I just checked out a clean version and built it without any
problems. The SHA from that was 2537cabbf0cc9b39f17f347105ee18c559d0041a.
What version are you on?

Have you tried building with GCC instead of PGI? I'm thinking of ways to
simplify the build since I haven't tried building with PGI+CUDA+MPI+Python
myself.

Andy

On Mon, Aug 27, 2012 at 3:31 PM, Vanmoer, Mark W wrote:

>  Hi Andy, I just did a fresh git clone and ccmake gives me
>
> 
>
> Make Error at VTK/CMake/vtkModuleTop.cmake:29 (message):
>
>No such module "vtkWrappingTools" needed by
> "vtkUtilitiesWrapClientServer"
>
> Call Stack (most recent call first):
>
>VTK/CMake/vtkModuleTop.cmake:45 (vtk_module_check)
>
>VTK/CMake/vtkModuleTop.cmake:52 (vtk_module_check)
>
>VTK/CMakeLists.txt:334 (include)
>
> ** **
>
> Mark
>
> ** **
>
> *From:* Andy Bauer [mailto:andy.ba...@kitware.com]
> *Sent:* Monday, August 27, 2012 11:59 AM
>
> *To:* Vanmoer, Mark W
> *Cc:* paraview@paraview.org
> *Subject:* Re: [Paraview] Python interpreter not being created for
> coprocessing?
>
> ** **
>
> Hi Mark,
>
> With the modularization of VTK and ParaView the coprocessing tests were
> temporarily in a bad state. The serial ones are fixed now (the parallel
> runs but gives incorrect results for the screenshot). Is it possible for
> you to update your version of ParaView and retry this?
>
> Thanks,
> Andy
>
> On Fri, Aug 24, 2012 at 4:03 PM, Vanmoer, Mark W 
> wrote:
>
> Hi, I rebuilt with ParaViewData directory set and it’s only finding 1 out
> 3 of the CoProcessing tests. Did I forget a step?
>
>  
>
> $ ctest --verbose --output-on-failure --output-log ctest.out -R CoProcess*
> ***
>
>  
>
> UpdateCTestConfiguration  from
> :/usr/apps/vis/ParaView/repo/withTesting/DartConfiguration.tcl
>
> Parse Config
> file:/usr/apps/vis/ParaView/repo/withTesting/DartConfiguration.tcl
>
> UpdateCTestConfiguration  from
> :/usr/apps/vis/ParaView/repo/withTesting/DartConfiguration.tcl
>
> Parse Config
> file:/usr/apps/vis/ParaView/repo/withTesting/DartConfiguration.tcl
>
> Test project /usr/apps/vis/ParaView/repo/withTesting
>
> Constructing a list of tests
>
> Done constructing a list of tests
>
> Checking test dependency graph...
>
> Checking test dependency graph end
>
> test 29
>
> Start  29: vtkCoProcessor-HeaderTest
>
>  
>
> 29: Test command: /usr/bin/python
> "/usr/apps/vis/ParaView/repo/ParaView/VTK/Testing/Core/HeaderTesting.py"
> "/usr/apps/vis/ParaView/repo/ParaView/CoProcessing/Core"
> "VTKCOPROCESSOR_EXPORT"
>
> 29: Test timeout computed to be: 1500
>
> 29: Use export macro: VTKCOPROCESSOR_EXPORT
>
> 1/3 Test  #29: vtkCoProcessor-HeaderTest    Passed0.37 sec
>
> test 100
>
> Start 100: CoProcessingTestPythonScript
>
>  
>
> 100: Test command: /usr/apps/vis/CMake/2.8.9/bin/cmake "-Dcfg=Release"
> "-P"
> "/usr/apps/vis/ParaView/repo/withTesting/CoProcessing/CoProcessingTestPythonScript.cmake"
> 
>
> 100: Test timeout computed to be: 1500
>
> 100: CMake Error at
> /usr/apps/vis/ParaView/repo/withTesting/CoProcessing/CoProcessingTestPythonScript.cmake:6
> (message):
>
> 100:   
>
> 100:
> '/usr/apps/vis/ParaView/repo/withTesting/ThirdParty/protobuf/vtkprotobuf/bin/Release/CoProcessingPythonScriptExample.exe'
> 
>
> 100:   does not exist
>
> 100: 
>
> 100: 
>
> 2/3 Test #100: CoProcessingTestPythonScript .***Failed0.79 sec
>
> CMake Error at
> /usr/apps/vis/ParaView/repo/withTesting/CoProcessing/CoProcessingTestPythonScript.cmake:6
> (message):
>
>   
>
>
>   
> '/usr/apps/vis/ParaView/repo/withTesting/ThirdParty/protobuf/vtkprotobuf/bin/Release/CoProcessingPythonScriptExample.exe'
> 
>
>   does not exist
>
>  
>
>  
>
>  
>
> test 101
>
> Start 101: PCoProcessingTestPythonScript
>
>  
>
> 101: Test command: /usr/apps/vis/CMake/2.8.9/bin/cmake "-Dcfg=Release"
> "-P"
> "/usr/apps/vis/ParaView/repo/withTesting/CoProcessing/PCoProcessingTestPythonScript.cmake"
> 
>
> 101: Test timeout computed to be: 1500
>
> 101: CMake Error at
> /usr/apps/vis/ParaView/repo/withTesting/CoProcessing/PCoProcessingTestPythonScript.cmake:6
> (message):
>
> 101:   
>
> 101:
> '/usr/apps/vis/ParaView/repo/withTesting/ThirdParty/protobuf/vtkprotobuf/bin/Release/CoProcessingPythonScriptExample.exe'
> 
>
> 101:   does not exist
>
> 101: 
>
> 101: 
>
> 3/3 Test #101: PCoProcessingTestPythonScript ***Failed0.01 sec
>
> CMake Error at
> /usr/apps/vis/ParaView/repo/withTesting/CoProcessing/PCoProcessingTestPythonScript.cmake:6
> (message):
>
>   
>
>
>   
> '/usr/apps/vis/ParaView/repo/withTesting/ThirdParty/protobuf/vtkprotobuf/bin/Release/CoProcessingPythonScriptExample.exe'
> 
>
>   does not exist
>
>  **

Re: [Paraview] ParaView thinks that it does not have a wind blade reader

[Sohail Shafii]

MPI is only used if it's available. It tries to see if there is a
MPIController available.  If not, then the number of ranks is 1, which
means that the parallel class calls the super class's requestdata (super
class is the serial wind blade reader).

However, the parallel class overrides certain functions to make use of MPI.
So even the parallel instantiation will call the superclass's requestdata,
the overriden functions that are called from that point on assume that MPI
is available...this is a problem when the MPI controller is not available.

On another note, it appears that the rectilinear grid that I am reading
(VTK file, structured points I think) is read by the vtkFileSeriesReader,
which makes use of the vtkPDataSetReader class.  Strange that if I use
vtkPDataSetReader myself in C++ code that uses VTK and not paraview,
bounds/cell information is not generated. So I think that ParaView does
something else besides using that reader...hmmm.

On Mon, Aug 27, 2012 at 7:32 PM, Andy Bauer  wrote:

>
>
> On Mon, Aug 27, 2012 at 6:53 PM, Sohail Shafii wrote:
>
>> I see...so if MPI is running then it will create a parallel version of
>> the class. Otherwise, it will create the normal reader.
>>
>
> Technically, if ParaView is built with MPI enabled it will create the
> parallel version of the class every time whether or not the client, server,
> or python scripts are actually run with mpiexec, mpirun, or whatever is
> used to start the executable. So you can't rely on MPI being initialized
> and should not initialize it yourself in your class as that can cause
> problems as well. I think that's what you meant but wanted to be as clear
> as possible for the implications for the classes.
>
>
>>
>> As far as the check goes for a multiprocess controller; while it does
>> call the parent request data in the serial case, the inherited parallel
>> class overrides some of the methods.  Which is a problem because it refers
>> to its own file pointer in those methods (it uses MPI_File instead of a
>> FILE*). Hmm.
>>
>> Sohail
>>
>>
>> On Thu, Aug 23, 2012 at 3:20 PM, Andy Bauer wrote:
>>
>>> Hi Sohail,
>>>
>>> Sorry for the slow reply but I wanted to make sure how things should
>>> work first and that took a bit to figure out. Anyways, this is closer to
>>> what's needed but the way it is supposed to work in VTK is that we use
>>> vtkObjectFactory to determine which one should be created when
>>> vtkWindBladeReader::New() is called. This is done at build time based on
>>> whether or not VTK is built with MPI. So if VTK and ParaView are built in
>>> parallel then there is code added that creates a vtkPWindBladeReader when
>>> vtkWindBladeReader::New() is called. This is regardless of whether or not
>>> the executable is run with mpi initialized or not. Because of this, the
>>> parallel version of the reader is responsible for checking whether mpi is
>>> initialized, ideally by doing
>>> vtkMultiProcessController::GetGlobalController()->IsA("vtkMPIController")
>>> is true, and if it isn't it should just call the parent class's methods for
>>> reading in the files. You may want to look at vtkPNrrdReader and the
>>> CMakeLists.txt file in that directory to see how they did things. Note
>>> though that if it's a single process running that it doesn't do any MPI
>>> calls even in the parallel version so your code will be slightly different
>>> than theirs.
>>>
>>> As for other parts of the email below:
>>>
>>> 1) yes, please keep cc'ing the list as there are some details in here
>>> that will be helpful to other people trying to implement their own parallel
>>> readers or filters
>>>
>>> 2) I'm not sure what's going on with the gradient filter but am guessing
>>> that it has to do with the multiblock data set and that there probably
>>> isn't that same array in each block. But that's just a guess. Did you try
>>> extracting the "air" block and do the vorticity and/or q criterion
>>> computation on that?
>>>
>>> 3) vtkSMReaderFactory may be the class you're looking for to determine
>>> which reader is getting used. ParaViewReaders.xml has a list of readers
>>> that it will try to read in a file.
>>>
>>> Andy
>>>
>>>
>>> On Tue, Aug 21, 2012 at 7:11 PM, Sohail Shafii wrote:
>>>
  >>> stuff because it's stupid>

 Here's the first version.  Do you want me to keep ccing the list? Not
 sure if that's necessary at this point because this is related to the
 development of ParaView and not help.

 I've run it with an older version of the master, and it seems to read
 in a test .wind file just fine.  For now I had to store the
 vtkPWindBladeReader* files into VTK/Parallel/MPI since I don't have
 VTK/IO/MPIParallel module yet.  Now when I run the gradient filter after
 the field, the gradient filter thinks that the input array does not have
 the appropriate number of components for Q criterion or vorticity...but it
 should (UVW does have three components per tuple).  Might be my outd

Re: [Paraview] ParaView thinks that it does not have a wind blade reader

[Sohail Shafii]

Well I guess it's not a problem in the derived functions if I check to see
if MPI is available; if not, call the superclass's version of the virtual
function.

On Tue, Aug 28, 2012 at 11:32 AM, Sohail Shafii wrote:

> MPI is only used if it's available. It tries to see if there is a
> MPIController available.  If not, then the number of ranks is 1, which
> means that the parallel class calls the super class's requestdata (super
> class is the serial wind blade reader).
>
> However, the parallel class overrides certain functions to make use of
> MPI. So even the parallel instantiation will call the superclass's
> requestdata, the overriden functions that are called from that point on
> assume that MPI is available...this is a problem when the MPI controller is
> not available.
>
> On another note, it appears that the rectilinear grid that I am reading
> (VTK file, structured points I think) is read by the vtkFileSeriesReader,
> which makes use of the vtkPDataSetReader class.  Strange that if I use
> vtkPDataSetReader myself in C++ code that uses VTK and not paraview,
> bounds/cell information is not generated. So I think that ParaView does
> something else besides using that reader...hmmm.
>
>
> On Mon, Aug 27, 2012 at 7:32 PM, Andy Bauer wrote:
>
>>
>>
>> On Mon, Aug 27, 2012 at 6:53 PM, Sohail Shafii wrote:
>>
>>> I see...so if MPI is running then it will create a parallel version of
>>> the class. Otherwise, it will create the normal reader.
>>>
>>
>> Technically, if ParaView is built with MPI enabled it will create the
>> parallel version of the class every time whether or not the client, server,
>> or python scripts are actually run with mpiexec, mpirun, or whatever is
>> used to start the executable. So you can't rely on MPI being initialized
>> and should not initialize it yourself in your class as that can cause
>> problems as well. I think that's what you meant but wanted to be as clear
>> as possible for the implications for the classes.
>>
>>
>>>
>>> As far as the check goes for a multiprocess controller; while it does
>>> call the parent request data in the serial case, the inherited parallel
>>> class overrides some of the methods.  Which is a problem because it refers
>>> to its own file pointer in those methods (it uses MPI_File instead of a
>>> FILE*). Hmm.
>>>
>>> Sohail
>>>
>>>
>>> On Thu, Aug 23, 2012 at 3:20 PM, Andy Bauer wrote:
>>>
 Hi Sohail,

 Sorry for the slow reply but I wanted to make sure how things should
 work first and that took a bit to figure out. Anyways, this is closer to
 what's needed but the way it is supposed to work in VTK is that we use
 vtkObjectFactory to determine which one should be created when
 vtkWindBladeReader::New() is called. This is done at build time based on
 whether or not VTK is built with MPI. So if VTK and ParaView are built in
 parallel then there is code added that creates a vtkPWindBladeReader when
 vtkWindBladeReader::New() is called. This is regardless of whether or not
 the executable is run with mpi initialized or not. Because of this, the
 parallel version of the reader is responsible for checking whether mpi is
 initialized, ideally by doing
 vtkMultiProcessController::GetGlobalController()->IsA("vtkMPIController")
 is true, and if it isn't it should just call the parent class's methods for
 reading in the files. You may want to look at vtkPNrrdReader and the
 CMakeLists.txt file in that directory to see how they did things. Note
 though that if it's a single process running that it doesn't do any MPI
 calls even in the parallel version so your code will be slightly different
 than theirs.

 As for other parts of the email below:

 1) yes, please keep cc'ing the list as there are some details in here
 that will be helpful to other people trying to implement their own parallel
 readers or filters

 2) I'm not sure what's going on with the gradient filter but am
 guessing that it has to do with the multiblock data set and that there
 probably isn't that same array in each block. But that's just a guess. Did
 you try extracting the "air" block and do the vorticity and/or q criterion
 computation on that?

 3) vtkSMReaderFactory may be the class you're looking for to determine
 which reader is getting used. ParaViewReaders.xml has a list of readers
 that it will try to read in a file.

 Andy


 On Tue, Aug 21, 2012 at 7:11 PM, Sohail Shafii wrote:

>   stuff because it's stupid>
>
> Here's the first version.  Do you want me to keep ccing the list? Not
> sure if that's necessary at this point because this is related to the
> development of ParaView and not help.
>
> I've run it with an older version of the master, and it seems to read
> in a test .wind file just fine.  For now I had to store the
> vtkPWindBladeReader* files into VTK/Paralle

Re: [Paraview] ParaView thinks that it does not have a wind blade reader

[Sohail Shafii]

As far as the gradient filter is concerned: I pick the UVW array in the
GUI.  It does compute a gradient, but only for one array -- "A-Scale
turbulence" (all variables are loaded).  So picking a different array in
the GUI doesn't seem to make a difference as it keeps computing gradient
for that one input (point data) array.  That's why it can't compute
vorticity or q-criterion because a-scale turbulence is a 1-component array.

Might be because I'm using an older version of the repo from late July.

Sohail

On Tue, Aug 28, 2012 at 11:51 AM, Sohail Shafii wrote:

> Well I guess it's not a problem in the derived functions if I check to see
> if MPI is available; if not, call the superclass's version of the virtual
> function.
>
>
> On Tue, Aug 28, 2012 at 11:32 AM, Sohail Shafii wrote:
>
>> MPI is only used if it's available. It tries to see if there is a
>> MPIController available.  If not, then the number of ranks is 1, which
>> means that the parallel class calls the super class's requestdata (super
>> class is the serial wind blade reader).
>>
>> However, the parallel class overrides certain functions to make use of
>> MPI. So even the parallel instantiation will call the superclass's
>> requestdata, the overriden functions that are called from that point on
>> assume that MPI is available...this is a problem when the MPI controller is
>> not available.
>>
>> On another note, it appears that the rectilinear grid that I am reading
>> (VTK file, structured points I think) is read by the vtkFileSeriesReader,
>> which makes use of the vtkPDataSetReader class.  Strange that if I use
>> vtkPDataSetReader myself in C++ code that uses VTK and not paraview,
>> bounds/cell information is not generated. So I think that ParaView does
>> something else besides using that reader...hmmm.
>>
>>
>> On Mon, Aug 27, 2012 at 7:32 PM, Andy Bauer wrote:
>>
>>>
>>>
>>> On Mon, Aug 27, 2012 at 6:53 PM, Sohail Shafii wrote:
>>>
 I see...so if MPI is running then it will create a parallel version of
 the class. Otherwise, it will create the normal reader.

>>>
>>> Technically, if ParaView is built with MPI enabled it will create the
>>> parallel version of the class every time whether or not the client, server,
>>> or python scripts are actually run with mpiexec, mpirun, or whatever is
>>> used to start the executable. So you can't rely on MPI being initialized
>>> and should not initialize it yourself in your class as that can cause
>>> problems as well. I think that's what you meant but wanted to be as clear
>>> as possible for the implications for the classes.
>>>
>>>

 As far as the check goes for a multiprocess controller; while it does
 call the parent request data in the serial case, the inherited parallel
 class overrides some of the methods.  Which is a problem because it refers
 to its own file pointer in those methods (it uses MPI_File instead of a
 FILE*). Hmm.

 Sohail


 On Thu, Aug 23, 2012 at 3:20 PM, Andy Bauer wrote:

> Hi Sohail,
>
> Sorry for the slow reply but I wanted to make sure how things should
> work first and that took a bit to figure out. Anyways, this is closer to
> what's needed but the way it is supposed to work in VTK is that we use
> vtkObjectFactory to determine which one should be created when
> vtkWindBladeReader::New() is called. This is done at build time based on
> whether or not VTK is built with MPI. So if VTK and ParaView are built in
> parallel then there is code added that creates a vtkPWindBladeReader when
> vtkWindBladeReader::New() is called. This is regardless of whether or not
> the executable is run with mpi initialized or not. Because of this, the
> parallel version of the reader is responsible for checking whether mpi is
> initialized, ideally by doing
> vtkMultiProcessController::GetGlobalController()->IsA("vtkMPIController")
> is true, and if it isn't it should just call the parent class's methods 
> for
> reading in the files. You may want to look at vtkPNrrdReader and the
> CMakeLists.txt file in that directory to see how they did things. Note
> though that if it's a single process running that it doesn't do any MPI
> calls even in the parallel version so your code will be slightly different
> than theirs.
>
> As for other parts of the email below:
>
> 1) yes, please keep cc'ing the list as there are some details in here
> that will be helpful to other people trying to implement their own 
> parallel
> readers or filters
>
> 2) I'm not sure what's going on with the gradient filter but am
> guessing that it has to do with the multiblock data set and that there
> probably isn't that same array in each block. But that's just a guess. Did
> you try extracting the "air" block and do the vorticity and/or q criterion
> computation on that?
>
> 3) vtkSMReaderFactory may be the clas

Re: [Paraview] Python interpreter not being created for coprocessing?

[Vanmoer, Mark W]

[mvanmoer@forge ParaView]$ git log origin/master | head -1
commit 2537cabbf0cc9b39f17f347105ee18c559d0041a

I should mention I do have a gcc, mvapich2 compiled version of coprocessing 
compiled on Forge and it works great. However any program built with 
PGI/openmpi code (required because of the CUDA Fortran) crashes with MPI 
errors. That's why I was trying to build ParaView with PGI/openmpi. I guess I 
could try gcc/openmpi and see if that linked to pgi/openmpi will run.

Mark


From: Andy Bauer [mailto:andy.ba...@kitware.com]
Sent: Tuesday, August 28, 2012 12:19 PM
To: Vanmoer, Mark W
Cc: paraview@paraview.org
Subject: Re: [Paraview] Python interpreter not being created for coprocessing?

Hmm, ParaView has been undergoing a lot of changes lately so it's been a bit 
unstable. I just checked out a clean version and built it without any problems. 
The SHA from that was 2537cabbf0cc9b39f17f347105ee18c559d0041a. What version 
are you on?

Have you tried building with GCC instead of PGI? I'm thinking of ways to 
simplify the build since I haven't tried building with PGI+CUDA+MPI+Python 
myself.

Andy
On Mon, Aug 27, 2012 at 3:31 PM, Vanmoer, Mark W 
mailto:mvanm...@illinois.edu>> wrote:
Hi Andy, I just did a fresh git clone and ccmake gives me
Make Error at VTK/CMake/vtkModuleTop.cmake:29 (message):
   No such module "vtkWrappingTools" needed by "vtkUtilitiesWrapClientServer"
Call Stack (most recent call first):
   VTK/CMake/vtkModuleTop.cmake:45 (vtk_module_check)
   VTK/CMake/vtkModuleTop.cmake:52 (vtk_module_check)
   VTK/CMakeLists.txt:334 (include)

Mark

From: Andy Bauer [mailto:andy.ba...@kitware.com]
Sent: Monday, August 27, 2012 11:59 AM

To: Vanmoer, Mark W
Cc: paraview@paraview.org
Subject: Re: [Paraview] Python interpreter not being created for coprocessing?

Hi Mark,

With the modularization of VTK and ParaView the coprocessing tests were 
temporarily in a bad state. The serial ones are fixed now (the parallel runs 
but gives incorrect results for the screenshot). Is it possible for you to 
update your version of ParaView and retry this?

Thanks,
Andy
On Fri, Aug 24, 2012 at 4:03 PM, Vanmoer, Mark W 
mailto:mvanm...@illinois.edu>> wrote:
Hi, I rebuilt with ParaViewData directory set and it's only finding 1 out 3 of 
the CoProcessing tests. Did I forget a step?

$ ctest --verbose --output-on-failure --output-log ctest.out -R CoProcess

UpdateCTestConfiguration  from 
:/usr/apps/vis/ParaView/repo/withTesting/DartConfiguration.tcl
Parse Config file:/usr/apps/vis/ParaView/repo/withTesting/DartConfiguration.tcl
UpdateCTestConfiguration  from 
:/usr/apps/vis/ParaView/repo/withTesting/DartConfiguration.tcl
Parse Config file:/usr/apps/vis/ParaView/repo/withTesting/DartConfiguration.tcl
Test project /usr/apps/vis/ParaView/repo/withTesting
Constructing a list of tests
Done constructing a list of tests
Checking test dependency graph...
Checking test dependency graph end
test 29
Start  29: vtkCoProcessor-HeaderTest

29: Test command: /usr/bin/python 
"/usr/apps/vis/ParaView/repo/ParaView/VTK/Testing/Core/HeaderTesting.py" 
"/usr/apps/vis/ParaView/repo/ParaView/CoProcessing/Core" "VTKCOPROCESSOR_EXPORT"
29: Test timeout computed to be: 1500
29: Use export macro: VTKCOPROCESSOR_EXPORT
1/3 Test  #29: vtkCoProcessor-HeaderTest    Passed0.37 sec
test 100
Start 100: CoProcessingTestPythonScript

100: Test command: /usr/apps/vis/CMake/2.8.9/bin/cmake "-Dcfg=Release" "-P" 
"/usr/apps/vis/ParaView/repo/withTesting/CoProcessing/CoProcessingTestPythonScript.cmake"
100: Test timeout computed to be: 1500
100: CMake Error at 
/usr/apps/vis/ParaView/repo/withTesting/CoProcessing/CoProcessingTestPythonScript.cmake:6
 (message):
100:
100:   
'/usr/apps/vis/ParaView/repo/withTesting/ThirdParty/protobuf/vtkprotobuf/bin/Release/CoProcessingPythonScriptExample.exe'
100:   does not exist
100:
100:
2/3 Test #100: CoProcessingTestPythonScript .***Failed0.79 sec
CMake Error at 
/usr/apps/vis/ParaView/repo/withTesting/CoProcessing/CoProcessingTestPythonScript.cmake:6
 (message):

  
'/usr/apps/vis/ParaView/repo/withTesting/ThirdParty/protobuf/vtkprotobuf/bin/Release/CoProcessingPythonScriptExample.exe'
  does not exist



test 101
Start 101: PCoProcessingTestPythonScript

101: Test command: /usr/apps/vis/CMake/2.8.9/bin/cmake "-Dcfg=Release" "-P" 
"/usr/apps/vis/ParaView/repo/withTesting/CoProcessing/PCoProcessingTestPythonScript.cmake"
101: Test timeout computed to be: 1500
101: CMake Error at 
/usr/apps/vis/ParaView/repo/withTesting/CoProcessing/PCoProcessingTestPythonScript.cmake:6
 (message):
101:
101:   
'/usr/apps/vis/ParaView/repo/withTesting/ThirdParty/protobuf/vtkprotobuf/bin/Release/CoProcessingPythonScriptExample.exe'
101:   does not exist
101:
101:
3/3 Test #101: PCoProcessingTestPythonScript ***Failed0.01 sec
CMake Error at 
/usr/apps/vis/ParaView/repo/withTesting/CoProcessing/PCoProcessingTestPythonScript.cmake:6
 (messa

[Paraview] Problems with visibility of 3D Widgets when switching between views

[Nenad Vujicic]

Hello everyone!

I have problems with visibility of 3D widgets when I have several
views opened in one ParaView Qt client and I switch between them. I
experience this behavior on both Windows and Linux. Here is how to
reproduce it:

0) Start ParaView Qt client,
1) Create Sphere source and press Apply button,
2) Create Slice filter, turn off Show Plane option and press Apply button,
3) Create new layout item by pushing '+' and select Spreadsheet View,
4) Go on Render View by pressing Layout 1 item,
5) Export 3D scene from currently active render view to VRML file
(File->Export),
6) Reopen ParaView Qt client and load previously exported VRML file.

Looks like VRML exporter exports 3D widget's geometry and topology
too, although its turned off. This also occurs with other sources /
filters with 3D widgets (PointSource, Clip, etc.).

Can someone suggest how I could fix this bug, by changing exporter's
or ParaView's sources, or at least approximate place in sources where
I could take a look for a bug?

Thanks,
Nenad.
___
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] Problems with visibility of 3D Widgets when switching between views

[Utkarsh Ayachit]

Nenad,

vtkVRMLExporter will be the starting point where I'd start digging in.
I am guessing somewhere where it iterates over all actors it's not
checking for visibility of 3D widgets or something.

On Tue, Aug 28, 2012 at 5:45 PM, Nenad Vujicic  wrote:
> Hello everyone!
>
> I have problems with visibility of 3D widgets when I have several
> views opened in one ParaView Qt client and I switch between them. I
> experience this behavior on both Windows and Linux. Here is how to
> reproduce it:
>
> 0) Start ParaView Qt client,
> 1) Create Sphere source and press Apply button,
> 2) Create Slice filter, turn off Show Plane option and press Apply button,
> 3) Create new layout item by pushing '+' and select Spreadsheet View,
> 4) Go on Render View by pressing Layout 1 item,
> 5) Export 3D scene from currently active render view to VRML file
> (File->Export),
> 6) Reopen ParaView Qt client and load previously exported VRML file.
>
> Looks like VRML exporter exports 3D widget's geometry and topology
> too, although its turned off. This also occurs with other sources /
> filters with 3D widgets (PointSource, Clip, etc.).
>
> Can someone suggest how I could fix this bug, by changing exporter's
> or ParaView's sources, or at least approximate place in sources where
> I could take a look for a bug?
>
> Thanks,
> Nenad.
> ___
> 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

Re: [Paraview] Problems with visibility of 3D Widgets when switching between views

[Nenad Vujicic]

Dear Utkarsh,

Thank You very much for Your response.

It checks actor's visibility at vtkVRMLExporter.cxx Ln 262, but actors
are visible because of some reasons. I'm sorry, looks like the problem
is much deeper. I tried even by playing from pvpython by executing:

active_objects.source.SMProxy.InvokeEvent('UserEvent', 'ShowWidget')
active_objects.source.SMProxy.InvokeEvent('UserEvent', 'HideWidget')

but it didn't work. I also experimented by counting number of actors
in interactive renderer object. After switching between views, it
contains ~13 actors, while after manually turning on and off widget's
visibility in Display panel it has ~9 (in this state exporter exports
correct scene - without 3d widgets). So, only way to "refresh" data in
current view is to manually turn ON and after it to turn OFF check box
on Display panel, which controls widget's visibility.

Btw, I have much more sophisticated exporter plugin and in which I
have the same problem. It works in similar way as VRMLExporter, so I
reported this with VRMLExporter test-case.

Thanks,
Nenad.


On Wed, Aug 29, 2012 at 12:08 AM, Utkarsh Ayachit
 wrote:
> Nenad,
>
> vtkVRMLExporter will be the starting point where I'd start digging in.
> I am guessing somewhere where it iterates over all actors it's not
> checking for visibility of 3D widgets or something.
>
> On Tue, Aug 28, 2012 at 5:45 PM, Nenad Vujicic  wrote:
>> Hello everyone!
>>
>> I have problems with visibility of 3D widgets when I have several
>> views opened in one ParaView Qt client and I switch between them. I
>> experience this behavior on both Windows and Linux. Here is how to
>> reproduce it:
>>
>> 0) Start ParaView Qt client,
>> 1) Create Sphere source and press Apply button,
>> 2) Create Slice filter, turn off Show Plane option and press Apply button,
>> 3) Create new layout item by pushing '+' and select Spreadsheet View,
>> 4) Go on Render View by pressing Layout 1 item,
>> 5) Export 3D scene from currently active render view to VRML file
>> (File->Export),
>> 6) Reopen ParaView Qt client and load previously exported VRML file.
>>
>> Looks like VRML exporter exports 3D widget's geometry and topology
>> too, although its turned off. This also occurs with other sources /
>> filters with 3D widgets (PointSource, Clip, etc.).
>>
>> Can someone suggest how I could fix this bug, by changing exporter's
>> or ParaView's sources, or at least approximate place in sources where
>> I could take a look for a bug?
>>
>> Thanks,
>> Nenad.
>> ___
>> 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