<div dir="ltr">Hi Paul,<div><br></div><div><div class="gmail_extra">This is very valid criticism. As I read it, there are two parts to the issue.</div><div class="gmail_extra"><br></div><div class="gmail_extra">> How bugs are handled.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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...</div><div class="gmail_extra"><br></div><div class="gmail_extra">> Stability of ParaView.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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 :-)</div><div class="gmail_extra"><br></div><div class="gmail_extra">Best,</div><div class="gmail_extra">-berk</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 16, 2016 at 4:52 AM, Paul Melis <span dir="ltr"><<a href="mailto:paul.melis@surfsara.nl" target="_blank">paul.melis@surfsara.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<span><br>
<br>
On 15-06-16 16:18, Berk Geveci wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I believe that the main differentiator between ParaView and other vis<br>
tools out there is the broad functionality _and_ the code quality.<br>
Having the two together is really tough but our community managed this<br>
with a heavy emphasis on code review and code testing. I strongly<br>
recommend that folks look at the software processes used to develop VTK<br>
& ParaView as well as the huge amount of testing (both test quantity and<br>
platform coverage) that we do before every single commit in addition to<br>
nightly. There is a very good overlap between the CMake, CTest & CDash<br>
communities and the VTK/ParaView development communities and there is<br>
very good reason behind this.<br>
</blockquote>
<br></span>
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).<br>
<br>
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.<br>
<br>
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!<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Regards,<br>
Paul<span><font color="#888888"><br>
<br>
-- <br>
<br>
Paul Melis<br>
| Visualization group leader & developer | SURFsara |<br>
| Science Park 140 | 1098 XG Amsterdam |<br>
| T 020 800 1312 | <a href="mailto:paul.melis@surfsara.nl" target="_blank">paul.melis@surfsara.nl</a> | <a href="http://www.surfsara.nl" rel="noreferrer" target="_blank">www.surfsara.nl</a> |<br>
</font></span></blockquote></div><br></div></div></div>