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) <berk.gev...@kitware.com>; Sven Kramer
<svenkrame...@gmail.com>
Cc: ParaView <paraview@paraview.org>
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 | paul.me...@surfsara.nl | www.surfsara.nl |
_______________________________________________
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
