[Paraview] Extending Broken in 2.6.0

[Mike Jackson]

On May 7, 2007, at 11:02 AM, Kent Eschenberg wrote:

> Bikash Agarwal wrote:
> > I was stuck on that for a while too. But PV 2.6 rejects the  
> "SetInput" ...
>
> Berk Geveci wrote:
>> SetInputConnection() is now the preferred way to connect  
>> algorithms in
>> VTK (as of 5.0) ...
>
> Thanks!
>
> Here is a related discovery that others might find useful.
>
> I am developing a new reader using (incorrectly) SetInput. When  
> things failed PV produced a half dozen error messages related to  
> the LSDyna reader followed by the error message related to my new  
> reader. That is what really threw me - my reader has nothing to do  
> with LSDyna and looks for a different file extension. It is almost  
> as if PV, when it couldn't find my SetInput, became despondent and  
> started wandering aimlessly through the other readers before  
> committing suicide. Maybe PV is becomming self aware ...
>
> Kent
> Pittsburgh Supercomputing Center


    I also wrote a reader for our data files and ran into the same  
problem. The LSDyna reader data files do NOT have extensions so the  
LSDyna reader will respond that it can read to _any_ file. Therefor  
it will not matter what extension you use the LSDyna reader will try  
to open. I asked about this earlier on this list on Feb 7, 2007. The  
subject was "LSDynaReader interferring with my own reader".

The response I got from was:

Mike Jackson Wrote:
 > basically there is a bug where the LSDyna is outputting
 > when it shouldn't.
 > Also this kinda sucks because say I am reading lots and lots of
 > files, I have to deal with the overhead of failed read attempts by
 > the LSDynaReader for every file? That seems like a problem to me.
 > Is it possible to add extensions to the LSDyna Files?

David Thomspson Wrote:
No, but as I said in my previous message, I will make sure
that CanReadFile doesn't print any error messages.
The proper way to avoid CanReadFile being called on
a large number of files is to have your reader placed
at the top of the list of all readers, rather than the
bottom. That seems like the proper behavior anyway, allowing
people to override the default set of readers shipped with
ParaView even where filename extensions conflict.

     David

<rant>So basically you have to hack up paraview because someone can  
not put a file extension on a data file and we all get to incur that  
performance penalty.</rant>
-- 
Mike Jackson   Senior Research Engineer
Innovative Management & Technology Services