[vtk-developers] Handling invalid vtp files

Will Schroeder will.schroeder at kitware.com
Sun Feb 14 14:43:50 EST 2010


This is a very tough nut to crack and from my experience is not completely
solved in most systems.

You can and probably should put some lightweight sanity checks into the
readers (and sprinkled elsewhere) to validate data. But believe me this is
not enough.

For example, one thing I've come across a lot is a polydata with a valid
vtkCellArray and a valid vtkPoints and yet it still crashes. Why? because
the person writing the file thought that VTK is 1-offset, meaning that
somewhere in the vtkCellArray are cells that refer to a non-existent point,
and crash!

Okay we can probably fix that, but what about the case of a badly-ordered
hex or wedge (jacobian is negative and/or the cell is mangled)?
Self-intersectiing mesh? Zero volume/area cell? And I could probably come up
with a list of a dozen or more problems related to topology, geometry and
assumptions about attributes (normalized normals, etc.) that might bring
down a particular filter. Some can be checked for pretty quickly, while some
are very expensive to address and could badly impact the reader's
performance. So if you put in a lot of validity checking you then start
hearing "VTK is slow...." You can't win :-)

Not only this, but if we are not careful, the validity checking code might
be duplicated across multiple readers;you'd like to contain this somehow.

So I think it's a design balancing act, some code in the readers and
sprinkled through the code base for quick sanity checks, with other
heavy-duty filters/functions used for debugging.

Will

On Sun, Feb 14, 2010 at 2:15 PM, Berk Geveci <berk.geveci at kitware.com>wrote:

>
> On Sun, Feb 14, 2010 at 7:18 AM, Will Schroeder <
> will.schroeder at kitware.com> wrote:
>
>> Another option here is to create a filter (or family of filters) that can
>> be inserted into the pipeline to check for validity (there could be
>> different sorts of checks). The filter could be removed, or disabled with a
>> flag, once the application is being tuned for performance and the data is
>> known to be good. In my mind these validity checks are more like debugging
>> tools and should be able to easily removed when debugging is complete.
>
>
> I somewhat disagree. Yes, these are debugging tools BUT they shouldn't be
> always optional. If I am a scientists who wants to load a dataset that I
> wrote using my code and ParaView crashes somewhere far far downstream, how
> am I supposed to know that my file is wrong? I would probably send a message
> to the mailing list, then some poor developer would ask for the file and
> debug and then find out that I don't know how to read the file format spec.
> That's assuming that the file is not 20 GB or something. If, instead, the
> reader said:
>
>  - Hey dude, there is something wrong with this file, please read the file
> format spec. Also, to debug this further, you can use this nice program that
> can give you more details about the problem.
>
> then the user wouldn't even have to come to the mailing list.
>
> -berk
>



-- 
William J. Schroeder, PhD
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
will.schroeder at kitware.com
http://www.kitware.com
(518) 881-4902
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20100214/900471de/attachment.html>


More information about the vtk-developers mailing list