[Paraview] Gathering information about python wrappers

[Berk Geveci]

Hi Erik,

The proxy classes override getattr and in some instances, they do
extra work when an attribute is requested. For example, any attribute
related to data causes the underlying filter to execute RequestInformation,
which causes it to execute RequestDataObject. Some filters require
that the input is connected before RequestDataObject because their
output data type depends on the input data type. This will change in
the future but currently there is no easy way to get around it.

Instead of parsing all of the attributes of the proxies, you can simply
access the properties. I believe I sent information about how to do
that in a previous e-mail.

Alternatively, you can identify the attributes that give you the errors
and filter them out. However, I am not crazy about the idea of exposing
all of attributes of the proxy classes to VisTrails because some of
them may cause similar issues in the future if they are accessed
before the pipeline is connected.

-berk

On Wed, Aug 4, 2010 at 5:52 PM, Erik Anderson <eranders at sci.utah.edu> wrote:
> Hi all,
>   I am trying to gather information about the Python-wrapped classes
> provided by the paraview.simple API.  So far, I have a script that uses some
> introspection and gets a lot done, but I'm left with a strange abort trap
> before things complete (in addition to some other strange errors).  The
> following script will reproduce all errors that I've seen and cannot
> explain.
>
>>>> import paraview.simple as pv
> paraview version 3.8.0, Date: 2010-03-26
>
> #  Some modules don't seem to like being instantiated at all...
>>>> forbidden = ["AlltoN", "Balance", "CTHSurface"]
>
> #  Grab all possible objects from the package
>>>> l = dir(pv)
>
> # Just create an object for each module and then destroy it to make sure we
> can get through the list...
>>>> for m in l:
>
> # If it doesn't like being created, just skip it for now.
>>>>   if forbidden.__contains__(m):
>>>>     continue
>
> # Grab a handle to the wrapper
>>>>   mod = getattr(pv, m)
>
> # Make sure it's a createable object.
>>>>   if hasattr(mod, "func_name"):
>>>>     if mod.func_name == "CreateObject":
>
> #  Create it and then delete it... This will eventually be necessary to
> inspect it's class methods.
>>>>       pv_instance = getattr(pv, m)()
>>>>       del pv_instance
>
> One of the questionable errors that does NOT cause the script to fail and
> exit -- I've found that this happens upon instantiation of the Clip module
> (although a handful of others show this as well):
>
> ERROR: In
> /Users/erikanderson/env/ParaView-3.8.0/VTK/Filtering/vtkExecutive.cxx, line
> 756
> vtkCompositeDataPipeline (0x10ac101a0): Algorithm
> vtkPVArrayCalculator(0x10ac0dbe0) returned failure for request:
> vtkInformation (0x10ac37ed0)
>  Debug: Off
>  Modified Time: 182297
>  Reference Count: 1
>  Registered Events: (none)
>  Request: REQUEST_DATA_OBJECT
>  FORWARD_DIRECTION: 0
>  ALGORITHM_AFTER_FORWARD: 1
>  FROM_OUTPUT_PORT: 0
>
>
>
> ERROR: In
> /Users/erikanderson/env/ParaView-3.8.0/Servers/Common/vtkPVClassNameInformation.cxx,
> line 47
> vtkPVClassNameInformation (0x10ac37e00): Cannot get class name from NULL
> object.
>
> ERROR: In
> /Users/erikanderson/env/ParaView-3.8.0/Servers/ServerManager/vtkSMOutputPort.cxx,
> line 338
> vtkSMOutputPort (0x10ac38070): Missing data information.
>
> ERROR: In
> /Users/erikanderson/env/ParaView-3.8.0/VTK/Filtering/vtkExecutive.cxx, line
> 756
> vtkCompositeDataPipeline (0x10ac101a0): Algorithm
> vtkPVArrayCalculator(0x10ac0dbe0) returned failure for request:
> vtkInformation (0x10ac37ed0)
>  Debug: Off
>  Modified Time: 182297
>  Reference Count: 1
>  Registered Events: (none)
>  Request: REQUEST_DATA_OBJECT
>  FORWARD_DIRECTION: 0
>  ALGORITHM_AFTER_FORWARD: 1
>  FROM_OUTPUT_PORT: 0
>
>
>
> ERROR: In
> /Users/erikanderson/env/ParaView-3.8.0/Servers/Common/vtkPVDataInformation.cxx,
> line 588
> vtkPVDataInformation (0x10ac38280): Could not cast object to a known data
> set: vtkAlgorithmOutput
>
> The fatal error:
>
> terminate called after throwing an instance of 'std::logic_error'
>  what():  basic_string::_S_construct NULL not valid
> Abort trap
>
> This happens after instantiation of the Ribbon module; however, if I skip a
> few it happens at another one down the line.
>
> Any help on this would be great!
> Thanks,
> Erik Anderson
>
>
> _______________________________________________
> 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
>
> Follow this link to subscribe/unsubscribe:
> http://www.paraview.org/mailman/listinfo/paraview
>