Re: [Paraview] [Paraview-developers] ParaView bug hackathon

[Utkarsh Ayachit]

+1. I will be there.

On Mon, Jun 20, 2016 at 4:30 PM, Berk Geveci  wrote:
> Hi folks,
>
> We are planning a ParaView bug hackathon on July 13. Going forward, we would
> like this to be a monthly event during which the community comes together to
> address bugs reported to the tracker. It will be an all day event that we
> will host physically at Kitware Headquarters in Clifton Park, NY as well as
> online via Google Hangout. All are welcome to attend as long as they know
> the code base enough to fix bugs.
>
> Any questions? Comments? Any potential issue with the date?
>
> Best,
> -berk
>
> ___
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at:
> http://markmail.org/search/?q=Paraview-developers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/paraview-developers
>
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

[Paraview] ParaView bug hackathon

[Berk Geveci]

Hi folks,

We are planning a ParaView bug hackathon on July 13. Going forward, we
would like this to be a monthly event during which the community comes
together to address bugs reported to the tracker. It will be an all day
event that we will host physically at Kitware Headquarters in Clifton Park,
NY as well as online via Google Hangout. All are welcome to attend as long
as they know the code base enough to fix bugs.

Any questions? Comments? Any potential issue with the date?

Best,
-berk
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] Questions on Paraview with 3D vector fields

[Moreland, Kenneth]

Jim,

It looks like you are asking two questions.

The first question is about using the glyph filter. I'm not sure what the 
confusion is. The arrow glyph filter works equal well with polygons and 
polyhedral. I have no trouble loading in a 3D dataset with 3D cells and 
cell-centered data. I just select the arrow glyph and everything works fine. In 
short, I cannot replicate what your issue is. Perhaps you can give more 
information.

As far as a fly through, yes it is possible in ParaView although, admittingly, 
the controls are not very good. To add a camera path, first open the Animation 
View (View -> Animation View). Then add a track to the Animation View for 
"Camera, Follow Path". After that, double click the track to bring up the 
keyframes dialog. From there you can double click "Path..." to get yet another 
dialog box to edit the path. Click "Camera Position" and then click back to the 
main ParaView window to edit the camera path.

-Ken

-Original Message-
From: ParaView [mailto:paraview-boun...@paraview.org] On Behalf Of Jim
Sent: Wednesday, June 15, 2016 8:10 PM
To: paraview@paraview.org
Subject: [EXTERNAL] [Paraview] Questions on Paraview with 3D vector fields

Hello All:

I'm working with 3D vector fields (2 of them in the same space) and want to do 
a fly through, set the center to be one of the arrow glyphs, and do some 
calculations on both fields using the calculator. I can't seem to do any of 
these. Any ideas?

It looks like the center selection was designed to work with polymeshes. 
The arrow glyphs just can't be selected. Is there any way to fake out Paraview 
and place something that the selector can see?

I saw fly through mentioned on some forum but no solution. I can place a line 
into my space. Is there some way to use the line as a camera path? 
I'm really interested in fly throughs in the program, not watching them as a 
movie. There's just too many things to change to make it a movie and not take 
forever to make/look at them.

The calculator looks like it only hooks up to one vector field at a time. Is 
there some object linking trick or running one field through an intermediate 
calculation that would make both fields visible to the calculator?

Any help appreciated.

-J




___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] capability of ParaView, Catalyst in distributed computing environment ...

[Andy Bauer]

Hi,

Glad to hear that this is working for you and thanks for sharing how you
did it! This is definitely a corner case that few Catalyst users/developers
will ever care about so I'm glad that the Catalyst API is flexible enough
to handle this.

Best,
Andy

On Sun, Jun 19, 2016 at 4:07 AM,  wrote:

> Hi Andy,
>
> I used first approach and fix the issue using following customised
> coprocessorinitializewithpython function. In this case, i converted type
> of communicator coming from Fortran to C using MPI_Comm_f2c call. Now, the
> code works without any problem. Thanks for your kindly help.
>
> extern "C" void my_coprocessorinitializewithpython_(int *fcomm, const
> char* pythonScriptName, const char strarr[][255], int *size) {
>   if (pythonScriptName != NULL) {
> if (!g_coprocessor) {
>   g_coprocessor = vtkCPProcessor::New();
>   MPI_Comm handle = MPI_Comm_f2c(*fcomm);
>   vtkMPICommunicatorOpaqueComm *Comm = new
> vtkMPICommunicatorOpaqueComm();
>   g_coprocessor->Initialize(*Comm);
>   vtkSmartPointer pipeline =
> vtkSmartPointer::New();
>   pipeline->Initialize(pythonScriptName);
>   g_coprocessor->AddPipeline(pipeline);
>   //pipeline->FastDelete();
> }
>
> if (!g_coprocessorData) {
>   g_coprocessorData = vtkCPDataDescription::New();
>   // must be input port for all model components and for all dimensions
>   for (int i = 0; i < *size; i++) {
> g_coprocessorData->AddInput(strarr[i]);
> std::cout << "adding input port [" << i << "] = " << strarr[i] <<
> std::endl;
>   }
> }
>   }
> }
>
> Regards,
>
> --ufuk
>
> > Hi Ufuk,
> >
> > I can think of two potential fixes:
> >
> >- Use the vtkCPProcessor:: Initialize(vtkMPICommunicatorOpaqueComm&
> >comm) method to initialize each process with the proper MPI
> > communicator.
> >Note that vtkMPICommunicatorOpaqueComm is defined in
> >vtkMPICommunicator.cxx. A similar example to this is available in the
> >Examples/Catalyst/MPISubCommunicatorExample directory.
> >- Call vtkCPProcessor::Initialize() on all processes with your global
> >communicator and then create a vtkMPIController partitioned the way
> you
> >want and set that to be the "global" communicator through
> >vtkMPIController::SetGlobalController().
> >
> > Please let us know if either of these methods work for you.
> >
> > Also, what code are you working on and is it a publicly available code?
> If
> > you show your implementation I may have some in-depth suggestions for
> > improvements.
> >
> > Best,
> >
> > Andy
> >
> >
> >
> > On Fri, Jun 17, 2016 at 4:17 AM, 
> wrote:
> >
> >> Hi All,
> >>
> >> I was working on the issue recently and i am very close to having
> >> prototype code but i had some difficulties in initialization of the
> >> co-processing component with coprocessorinitializewithpython call. In my
> >> case, two model components and adaptor have its own processing source
> >> (or
> >> MPI_COMM_WORLD). For example, MPI processor 0, 1, 2, 3 are used by 1st
> >> model, 4, 5, 6, 7 are used by 2nd model code and 8, 9, 10, 11 is used by
> >> adaptor. The code basically handles transferring the grid information
> >> and
> >> data to adaptor. So, the problem is that if i try to call my custom
> >> coprocessorinitializewithpython call in adaptor (only in 8, 9, 10, 11)
> >> then it hangs in g_coprocessor->Initialize(); (see code at the end of
> >> the
> >> mail) step but if i call coprocessorinitializewithpython in the main
> >> code
> >> that uses all the available processor (between 0 and 11) and it runs
> >> without any problem. It seems that there is a restriction in the
> >> ParaView
> >> side (expecially vtkCPProcessor::Initialize() that can be found in
> >> CoProcessing/Catalyst/vtkCPProcessor.cxx) but i am not sure. Do you have
> >> any suggestion about that? Do you think that is it possible to fix it
> >> easily. Of corse the adaptor code could use all the processor but it is
> >> better to have its own dedicated resource that might have GPU support in
> >> those specific servers or processors. I am relatively new to VTK and it
> >> might be difficult for me to fix it and i need your guidance to start.
> >>
> >> Best Regards,
> >>
> >> --ufuk
> >>
> >> vtkCPProcessor* g_coprocessor;
> >>
> >> extern "C" void my_coprocessorinitializewithpython_(const char*
> >> pythonScriptName, const char strarr[][255], int *size) {
> >>   if (pythonScriptName != NULL) {
> >> if (!g_coprocessor) {
> >>   g_coprocessor = vtkCPProcessor::New();
> >>   g_coprocessor->Initialize();
> >>   vtkSmartPointer pipeline =
> >> vtkSmartPointer::New();
> >>   pipeline->Initialize(pythonScriptName);
> >>   g_coprocessor->AddPipeline(pipeline);
> >>   //pipeline->FastDelete();
> >> }
> >>
> >> if (!g_coprocessorData) {
> >>   g_coprocessorData = vtkCPDataDescription::New();
> >>   // must be 

[Paraview] Transparent background in python scripts

[Armin Wehrfritz]

Hi!

How can I save screenshots with a transparent (alpha channel based)
background from a python script?

Currently, I'm using this command to save screenshots:

SaveScreenshot('image.png', magnification=3, view=renderView)

But this does not write the alpha channel information.


Using "File/ Save Screenshot" in the Paraview GUI, the screenshots
have the alpha channel information saved correctly when I setting "Edit/
Settings/ General/ Transparent Background".

I'm using ParaView 5.0.1 on a 64bit Linux workstation with the latest
Nvidia driver (367.27).


-Armin
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] Comparison of Visit and ParaView development

[Berk Geveci]

Hi Paul,

This is very valid criticism. As I read it, there are two parts to the
issue.

> How bugs are handled.

You are absolutely right that we have done a poor job responding to
community bug reports and fixes. Both on VTK & ParaView bug trackers but
especially on the ParaView side. We have been having some discussions on
how to address this. Part of the solution is going to be on the tool side.
We will move away from the Mantis bug tracker to the Gitlab bug tracker and
setup some processes to maintain the bug list more easily. We will also
expire bugs more quickly to manage the list in a reasonable way. The other
part is to change our attitude towards community bugs (as opposed to bugs
Kitware is funded to fix). We have always had resources to go after a
modest amount of such bugs but culturally it has not been a priority.
Utkarsh and I will work on ways of addressing this. More on this in the
near future...

> Stability of ParaView.

I don't (fully) agree with your assessment here. ParaView is very stable,
within a particular expanding feature set that the community actively
supports. Two issues here: 1. It is hard to define what this feature set
is, 2. ParaView is open ended so it supports a much larger feature set out
of box. We support a large community that uses ParaView day-to-day for
their production work and we have clear evidence (feedback) that ParaView
has grown very stable. These folks usually leverage a small subset of what
can be done with ParaView - the same feature set provided by many other vis
tools. If you go beyond this set, you venture into areas that are not
tested for all different combinations and because of the previous issue of
how we address (don't) community bugs, issues are not always addressed
here. We will work at doing better addressing bugs here but it will never
be perfect. We will never be able to gracefully handle input files that are
out of spec for example. This is probably the #1 reason ParaView crashes.
Nor will we able to handle all cases where ParaView runs out of memory (for
example because someone converted a regular grid to an unstructured grid
through clipping). It is simply not possible to provide an open-ended tool,
which is a light layer on top of VTK, and support stability of every
infinite combination. Let's not even get started with what one can do using
Python :-)

Best,
-berk


On Thu, Jun 16, 2016 at 4:52 AM, Paul Melis  wrote:

> Hi,
>
> On 15-06-16 16:18, Berk Geveci wrote:
>
>> I believe that the main differentiator between ParaView and other vis
>> tools out there is the broad functionality _and_ the code quality.
>> Having the two together is really tough but our community managed this
>> with a heavy emphasis on code review and code testing. I strongly
>> recommend that folks look at the software processes used to develop VTK
>> & ParaView as well as the huge amount of testing (both test quantity and
>> platform coverage) that we do before every single commit in addition to
>> nightly. There is a very good overlap between the CMake, CTest & CDash
>> communities and the VTK/ParaView development communities and there is
>> very good reason behind this.
>>
>
> Slightly off-topic (not fully about ParaView vs VisIt), but I always
> wondered about the development process of VTK/ParaView with respect to bug
> reports. There seem to be a huge number of reported bugs for ParaView (and
> a few for VTK), ranging from crashes to incorrect functionality to feature
> requests. Over the years I have entered more than two dozen myself, but was
> always surprised about the lack of response, especially when reporting
> things that were easily reproducible and/or crasher bugs (e.g. VTK #10528,
> ParaView #15291, ParaView #15944, ParaView #13802).
>
> Now, I understand that what's not working for me might not be important to
> others, so, of course, assigning priorty and doing actual fixes for reports
> is done by the developer community. A second "handicap" in this respect is
> undoubtedly the fact that KitWare is a business and so has different
> priorities than a bunch of hackers working mostly in their spare time on
> their pet project.
>
> But basically anything reported these days immediately gets status
> "backlog" and I would guesstimate getting a response to a report only about
> 25% of the time. I report bugs quite often for other open-source projects
> (and try to enter concise reports with a testcase), but with ParaView/VTK I
> get the feeling it's not worth the trouble, which is a shame. Actually
> getting back on topic: the one or two times I reported a bug in VisIt I got
> a reply and fix quickly!
>
> Furthermore, ParaView seems quite easy to segfault and it happens even
> with moderately complex pipelines and modest datasets. Parallel volume
> rendering has been broken for ages (or is it fixed these days? Can't tell,
> ParaView #13801 did not get any replies). Some examples shown on the wiki
> cause Python errors (e.g. 

Re: [Paraview] Can a collaborative client share a pipeline without creating a view itself?

[Peter Debuchev]

Well, I see that I'll need some more debug sessions to get this solved.

>Why not make M aware of the code that needs to be executed and then
>just trigger those through higher level messages from S? This is like
>your first option, but you're only sending coarse messages eg. "Do
>Action1" etc to M.

Yes, this would be my option 2). "Make M aware of the code" means that I
need some interpreted language that I send from S to M. (I would probably
not use a separate message to execute the transmitted code, but rather
execute it as soon as it has completely arrived. But this is a minor
detail.)

What I don't understand is why only the master is allowed to add sources
etc. My attempts run fine if I start ParaView as master and then add
sources through my custom (slave) clients. Is the missing thread safety in
VTK the problem, so that I could run into synchronization issues if several
clients request changes on the server "at the same time"? (If so, I'd
suggest that the server rejects messages which are not originating from the
master.)

There is this one remaining problem that ParaView seems not to initialize
correctly if a different master has set up a pipeline earlier. Did you have
a chance to look into this issue? I might also file a bug report, if you
prefer.

Thanks
Peter


2016-06-20 16:03 GMT+02:00 Utkarsh Ayachit :

> Peter,
>
>
> > Or does additional
> > documentation (design documents, message exchange protocols, ...) exist?
>
> Sorry my friend. Nothing more than what I previously mentioned on the
> mailing list.
>
>
> http://www.paraview.org/ParaView/images/2/24/ParaViewCollaborationChanges.pdf
> http://www.paraview.org/ParaView/index.php/ProcessModule_2.0
> http://www.paraview.org/ParaView/index.php/ServerManager_2.0
>
>
> > So, although the concept of promoting different clients as master is
> obvious
> > from the video above, something more is needed to allow any slave to
> change
> > the pipeline automatically by permission of the master: the slave (S)
> must
> > request to be promoted as master to the current master (M), M must
> promote S
> > as master, S operates on the pipeline, and S must promote M as master
> again.
>
> (My knowledge on how several of these things is quite rusty  -- so
> bear with me). I'd suggest look at pqCollaborationManager and see how
> it implements chat messages. You should be able to extend that concept
> to add support for custom messages.
>
>
> > After some thoughts, my suggested option 2) may be easier and more
> secure: S
> > would send its intended operations to M, and M executes them. Here, the
> > question is whether I have to invent a new streaming language to encode
> > pipeline changes that S wants to send to M? Or can S just build the
> pipeline
> > as intended and use some available serialization to send this pipeline
> state
> > to M?
>
> Why not make M aware of the code that needs to be executed and then
> just trigger those through higher level messages from S? This is like
> your first option, but you're only sending coarse messages eg. "Do
> Action1" etc to M.
>
> > Any of the options requires some additional messages to be send between
> > slaves and master. This is what I am trying to figure out. The --cslog
> > options looks very useful, but a short overview which classes are
> involved
> > in sending custom messages including an encoded pipeline state would be
> even
> > more helpful.
>
> Follow the code path  from  pqCollaborationManager::onChatMessage().
> It calls pqServer::sendToOtherClients(...) with a vtkSMMessage object
> created.
>
> Utkarsh
>
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] Can a collaborative client share a pipeline without creating a view itself?

[Utkarsh Ayachit]

Peter,


> Or does additional
> documentation (design documents, message exchange protocols, ...) exist?

Sorry my friend. Nothing more than what I previously mentioned on the
mailing list.

http://www.paraview.org/ParaView/images/2/24/ParaViewCollaborationChanges.pdf
http://www.paraview.org/ParaView/index.php/ProcessModule_2.0
http://www.paraview.org/ParaView/index.php/ServerManager_2.0


> So, although the concept of promoting different clients as master is obvious
> from the video above, something more is needed to allow any slave to change
> the pipeline automatically by permission of the master: the slave (S) must
> request to be promoted as master to the current master (M), M must promote S
> as master, S operates on the pipeline, and S must promote M as master again.

(My knowledge on how several of these things is quite rusty  -- so
bear with me). I'd suggest look at pqCollaborationManager and see how
it implements chat messages. You should be able to extend that concept
to add support for custom messages.


> After some thoughts, my suggested option 2) may be easier and more secure: S
> would send its intended operations to M, and M executes them. Here, the
> question is whether I have to invent a new streaming language to encode
> pipeline changes that S wants to send to M? Or can S just build the pipeline
> as intended and use some available serialization to send this pipeline state
> to M?

Why not make M aware of the code that needs to be executed and then
just trigger those through higher level messages from S? This is like
your first option, but you're only sending coarse messages eg. "Do
Action1" etc to M.

> Any of the options requires some additional messages to be send between
> slaves and master. This is what I am trying to figure out. The --cslog
> options looks very useful, but a short overview which classes are involved
> in sending custom messages including an encoded pipeline state would be even
> more helpful.

Follow the code path  from  pqCollaborationManager::onChatMessage().
It calls pqServer::sendToOtherClients(...) with a vtkSMMessage object
created.

Utkarsh
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] Can a collaborative client share a pipeline without creating a view itself?

[Peter Debuchev]

Dear Utkarsh,
to have some basis for this discussion, I'd like to mention that my
knowledge on the collaboration functionality is limited to what is shown in
http://vimeo.com/34480656 and to the class reference
http://www.paraview.org/ParaView/Doc/Nightly/www/cxx-doc/classvtkSMCollaborationManager.html.
Everything else I am trying to understand by debugging. Or does additional
documentation (design documents, message exchange protocols, ...) exist?

So, although the concept of promoting different clients as master is
obvious from the video above, something more is needed to allow any slave
to change the pipeline automatically by permission of the master: the slave
(S) must request to be promoted as master to the current master (M), M must
promote S as master, S operates on the pipeline, and S must promote M as
master again.
After some thoughts, my suggested option 2) may be easier and more secure:
S would send its intended operations to M, and M executes them. Here, the
question is whether I have to invent a new streaming language to encode
pipeline changes that S wants to send to M? Or can S just build the
pipeline as intended and use some available serialization to send this
pipeline state to M?

Any of the options requires some additional messages to be send between
slaves and master. This is what I am trying to figure out. The --cslog
options looks very useful, but a short overview which classes are involved
in sending custom messages including an encoded pipeline state would be
even more helpful.

Thanks
Peter


2016-06-20 1:23 GMT+02:00 Utkarsh Ayachit :

> Peter,
>
> ParaView already supports changing the master. A "master" can make any
> other connected process the new master. Once that happens the new
> master can start changing pipelines etc.
>
> > Finally, I believe that I will have to dive into message passing between
> > paraview clients, soon.
>
> Try running both the client and server with --cslog= and
> tail those files. You'll see a log for messages being sent between
> client and server.
>
___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please keep messages on-topic and check the ParaView Wiki at: 
http://paraview.org/Wiki/ParaView

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] [EXTERNAL] Re: Comparison of Visit and ParaView development

[Paul Melis]

Hi all,

Thanks for all the replies and sudden bug report action ;-)

I haven't had the time to check the bugs that got updated, will try to 
do that soon.


Regards,
Paul

On 16-06-16 19:06, Scott, W Alan wrote:

Paul,
I looked at a few of the bugs listed below.

I replicated 15944, this would impact my users.  It's on Sandia's list.

13802 works correctly on 5.0.1.  Note that you are creating 2.6 billion cells, 
and from what I can tell, you are running out of memory on your server side.  I 
was able to get this to work with 8 nodes of a cluster.  Try running the View/ 
Memory Inspector, it will tell you how much pressure you are putting on your 
memory.

Alan



-Original Message-
From: ParaView [mailto:paraview-boun...@paraview.org] On Behalf Of Paul Melis
Sent: Thursday, June 16, 2016 2:52 AM
To: Geveci, Berk (External Contact) ; Sven Kramer 

Cc: ParaView 
Subject: [EXTERNAL] Re: [Paraview] Comparison of Visit and ParaView development

Hi,

On 15-06-16 16:18, Berk Geveci wrote:

I believe that the main differentiator between ParaView and other vis
tools out there is the broad functionality _and_ the code quality.
Having the two together is really tough but our community managed this
with a heavy emphasis on code review and code testing. I strongly
recommend that folks look at the software processes used to develop
VTK & ParaView as well as the huge amount of testing (both test
quantity and platform coverage) that we do before every single commit
in addition to nightly. There is a very good overlap between the
CMake, CTest & CDash communities and the VTK/ParaView development
communities and there is very good reason behind this.


Slightly off-topic (not fully about ParaView vs VisIt), but I always wondered 
about the development process of VTK/ParaView with respect to bug reports. 
There seem to be a huge number of reported bugs for ParaView (and a few for 
VTK), ranging from crashes to incorrect functionality to feature requests. Over 
the years I have entered more than two dozen myself, but was always surprised 
about the lack of response, especially when reporting things that were easily 
reproducible and/or crasher bugs (e.g. VTK #10528, ParaView #15291, ParaView 
#15944, ParaView #13802).

Now, I understand that what's not working for me might not be important to others, so, of 
course, assigning priorty and doing actual fixes for reports is done by the developer 
community. A second "handicap" in this respect is undoubtedly the fact that 
KitWare is a business and so has different priorities than a bunch of hackers working 
mostly in their spare time on their pet project.

But basically anything reported these days immediately gets status "backlog" 
and I would guesstimate getting a response to a report only about 25% of the time. I 
report bugs quite often for other open-source projects (and try to enter concise reports 
with a testcase), but with ParaView/VTK I get the feeling it's not worth the trouble, 
which is a shame. Actually getting back on topic: the one or two times I reported a bug 
in VisIt I got a reply and fix quickly!

Furthermore, ParaView seems quite easy to segfault and it happens even with 
moderately complex pipelines and modest datasets. Parallel volume rendering has 
been broken for ages (or is it fixed these days? Can't tell, ParaView #13801 
did not get any replies). Some examples shown on the wiki cause Python errors 
(e.g. #15291, #12796). And so on.

So the comment above about code quality making ParaView stand out from other 
visualization tools is a bit a stretch in my opinion. I would certainly not call ParaView 
"stable". In fact, in the introductory scivis courses we teach with ParaView we 
always warn people that crashes are to be expected regularly and even during the course 
assignments they sometimes happen.

The development process as mentioned by Berk is indeed impressive, but seems 
mostly focused on preventing regressions in existing functionality. This is a 
worthy goal in itself, but is only one half of the story when it comes to 
guaranteeing code quality. The things that aren't working (see bug reports) are 
maybe not getting the attention they deserve, but are apparently things folks 
run into when using ParaView, so they signal something real.

After the stuff above I wanted to finish on a less critical note :) I prefer 
using ParaView over VisIt mostly because of being able to build a pipeline and 
prefer ParaView's nice single-window GUI over VisIt's 
a-window-here-a-window-there-a-window-everywhere approach. They are both good 
and useful tools and are work-horses for scivis tasks. Whenever I get a request 
from an HPC user which one to use I recommend ParaView, as it is easier to get 
into for basic scivis work.

Regards,
Paul




--

Paul Melis
| Visualization group leader & developer | SURFsara |
| Science Park 140 | 1098 XG Amsterdam |
| T 020 800 1312 |