[Paraview] Comparison of Visit and ParaView development

[Paul Melis]

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 | paul.melis at surfsara.nl | www.surfsara.nl |