[Paraview] My own filter as part of pipeline for coprocessing raises "name not defined" error

Wed Oct 2 12:28:17 EDT 2013

Thanks for the helpful info, Andy. I looked at the link and followed the code change Burlen posted to add the static linked plugin initialization into pvbatch and pvpython and that worked fine. Now pvbatch and pypthon all have my filter plugin statically loaded. I still got the "name not defined" error when coprocessing parses the pipeline though. I believe the problem remains because there is still no python wrapped proxy to my filter since there is no change to lib\site-packages after I add the static linked plugin initialization into pybatch and pvpython. To make sure I am on the right track for my further investigation, I am hoping to get answers to a couple of my further questions below:

1.       What is the right way to go to have the proxy to my filter Python wrapped? How can I verity I have the proxy to my filter Python wrapped? Is it true that the Python-wrapped proxy to my filter should show up in some python file in lib\site-packages if the filter is indeed python-wrapped?

2.       I made similar changes to CPythonAdaptorAPI.cxx and CMakeLists.txt as I did to pvpthon and pvbatch to load and init static plugin in function coprocessorinitializewithpython() hoping to have plugin loaded when doing coprocessing linked to simulation, however, I still have the symbol "pv_plugin_instance_SMVorticity" undefined in built PythonCatalyst static lib while the plugin symbol is indeed defined in pvpython with the same code changes. Just to confirm, does the plugin need to be loaded in Catalyst initialization in order to use it in a coprocessing pipeline? In other words, to get my plugin working in catalyst linked to simulation, I need to resolve two problems: (1) get the plugin statically loaded in Catalyst initialization; (2) get the proxy to the plugin Python wrapped and show up in some python file in lib\site-packages. Is this true?

Yes, I know the gradient of unstructured data set filter can compute vorticity, which I referenced to write this custom vorticity filter to make it fit our needs better with better performance. I did try to use the genetic gradient filter to compute vorticity for coprocessing, but it raises a segmentation fault after outputting several images. Will have to debug and investigate more to find out more on that.

Thanks,
Hong

From: Andy Bauer [mailto:andy.bauer at kitware.com]
Sent: Tuesday, October 01, 2013 2:19 PM
To: Hong Yi
Cc: David E DeMarle; paraview at paraview.org
Subject: Re: [Paraview] My own filter as part of pipeline for coprocessing raises "name not defined" error

Hi Hong,
I don't think you want to do VTK Python wrapping of your class. What you want is to have the proxy to the filter Python wrapped such that it's available when you import paraview.simple. This is what's needed for Catalyst Python pipelines. I don't think you're properly initializing the plugins from the previous directions I sent. You may want to look at http://public.kitware.com/pipermail/paraview-developers/2013-September/002499.html
As a side note, the gradient of unstructured data set filter can compute vorticity as well. It does require a vtkDataArray with three components to use though.
Regards,
Andy

On Mon, Sep 30, 2013 at 5:06 PM, Hong Yi <hongyi at renci.org<mailto:hongyi at renci.org>> wrote:
Thanks, Andy. The CMakeLists.txt for my plugin is copied below with newly added lines for python wrapping in orange:

-----------------------------
if(NOT ParaView_SOURCE_DIR)
  find_package(ParaView)
  include("${PARAVIEW_USE_FILE}")
  include (ParaViewPlugins)
else()
  # we're building from within ParaView Source.
endif()

include_directories(${VTK_INCLUDE_DIRS})
include(wrap-python.cmake)

# create a paraview plugin containing server manager xml and the server
# manager classes to build
# this plugin can be loaded on the server side

ADD_PARAVIEW_PLUGIN(SMVorticity "1.0"
  SERVER_MANAGER_XML VorticityFilter.xml
  SERVER_MANAGER_SOURCES VorticityFilter.cxx)

target_link_libraries(SMVorticity ${deps})

if(VTK_WRAP_PYTHON)
  wrap_python(SMVorticity "${sources}")
endif()
-----------------------------

The orange lines are added by following http://www.paraview.org/pipermail/paraview/2012-May/024855.html which works well and builds my filter and also wraps it in Python (i.e., it generates libSMVorticity.a and libSMVorticityPythonD.a). I have also verified the plugin is indeed loaded into pvserver and pvpython in paraview built bin directory.

However, I still got "name not defined" error in coprocessing script when creating this filter by name "VorticityOfUnstructuredDataSet" in python script. I have a couple of specific questions I am currently investigating and hoping to get some inputs from experts in the list:

1. I am not sure where this name "VorticityOfUnstructuredDataSet" (exported by coprocessing script generator plugin) comes from, the only clue I can see is in plugin.cmake, where the plugin is specified with DESCRIPTION "Vorticity Of Unstructured DataSet" and in VorticityFilter.xml, where the plugin is given a label of "Vorticity Of Unstructured DataSet." Should this name be defined somewhere such as in some python file in paraview python site-packages?

2. I did try to add PV_PLUGIN_IMPORT macros to the adaptor since I am using Catalyst, however, the plugin symbol "pv_plugin_instance_SMVorticity" is undefined in the adaptor static lib (the same plugin symbol is defined in pvserver), hence I got an undefined error when linking simulation code to the adaptor. I did try to add my plugin static lib (in which the plugin symbol is defined) to the adaptor target via target_link_libraries before linking to vtkPVPythonCatalyst, but that does not seem to take any effect. For some reason I am still investigating, my plugin lib does not get to link to the adaptor via target_link_libraries. What I did is to go to src directory in the cross target and modified CMakeLists.txt for PhastaAdaptor, then went to corresponding paraview-build directory, and did "make clean" followed by "make" to rebuild PhastaAdaptor lib. Is there something obvious that I did not do correctly?

Thanks for any inputs!

Hong

________________________________
From: Andy Bauer [andy.bauer at kitware.com<mailto:andy.bauer at kitware.com>]
Sent: Friday, September 27, 2013 3:00 PM
To: Hong Yi
Cc: David E DeMarle; paraview at paraview.org<mailto:paraview at paraview.org>

Subject: Re: [Paraview] My own filter as part of pipeline for coprocessing raises "name not defined" error

Can you share your plugin or at least the CMakeLists.txt for your plugin? Have you tried with any other plugins that get packaged with ParaView to see if they work?
If you're using Catalyst, I would suggest adding in the PV_PLUGIN_IMPORT_INIT macros to the adaptor.
Andy

On Thu, Sep 26, 2013 at 3:40 PM, Hong Yi <hongyi at renci.org<mailto:hongyi at renci.org>> wrote:
Thanks! I did put my plugin inside ParaView/Plugins in the same way as other Plugins, and enabled it when building ParaView superbuild on Titan. I can see the static lib for the Plugin is built in paraview-build/lib directory. And yes, I did use a plugin and load it via Tools|Manage Plugins when creating python coprocessing script. However, it looks like my plugin is not loaded automatically even though it is built by ParaView superbuild. Perhaps I should still follow the link http://www.paraview.org/Wiki/ParaView/Plugin_HowTo#Plugins_in_Static_Applications but I am having some difficulty in following the info in the link to do what is suggested. Specifically, to what file should I insert two macros? It does not sound right to insert them into my custom plugin cxx file. Where should I add two macros to get my custom filter plugin to be loaded and wrapper into python module? I see "LoadPlugin" function defined in simple.py to call servermanager.LoadPlugin(filename, remote) which I am thinking perhaps should be called to load my plugin before my python coprocessing script is executed, but not sure whether this is the case or not.

Thanks for any suggestions!

Hong

From: David E DeMarle [mailto:dave.demarle at kitware.com<mailto:dave.demarle at kitware.com>]
Sent: Thursday, September 26, 2013 1:28 PM
To: Andy Bauer
Cc: Hong Yi; paraview at paraview.org<mailto:paraview at paraview.org>
Subject: Re: [Paraview] My own filter as part of pipeline for coprocessing raises "name not defined" error

Utkarsh pointed out that you still need to follow http://www.paraview.org/Wiki/ParaView/Plugin_HowTo#Plugins_in_Static_Applications
when the plugin is external to ParaView. If you put your plugin inside ParaView/Plugins, then it is done automatically.

David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909<tel:518-881-4909>

On Thu, Sep 26, 2013 at 12:23 PM, David E DeMarle <dave.demarle at kitware.com<mailto:dave.demarle at kitware.com>> wrote:
I think that information is out of date. I believe that is done automatically now.

Otherwise Andy is right. Putting the filter inside a plugin a good way to go. The plugin infrastructure will make it so that when you provide the XML that describes your vtk class, ParaView's build system will automatically wrap it into a proxy and python class so that ParaView will be able to use it.

Also, I recommend trying it on a local static build first. That way the build time will be less and development will be quicker. Once you can load you plugin locally, then you should only have to compile on titan once.

David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909<tel:518-881-4909>

On Wed, Sep 25, 2013 at 10:34 PM, Andy Bauer <andy.bauer at kitware.com<mailto:andy.bauer at kitware.com>> wrote:
Did you use a plugin to add in your custom filter when creating the Python co-processing script? I'm not sure how plugins are "loaded" for static builds but you may want to look at http://www.paraview.org/Wiki/ParaView/Plugin_HowTo#Plugins_in_Static_Applications. If that doesn't work, we'll have to figure out some other way to do it.
Andy

On Wed, Sep 25, 2013 at 9:16 PM, Hong Yi <hongyi at renci.org<mailto:hongyi at renci.org>> wrote:
Hello,

I set up a pipeline that used a custom filter I developed and exported it as a python script for coprocessing. I have made sure the static library for my custom filter is built and available in paraview-build/lib directory, and I have also linked this custom filter static library along with Catalyst libs to the simulation code for coprocessing. However, when I run the simulation linked with ParaView coprocessing for in-situ visualization, I got "NameError: name 'MyCustomizedFilterName' is not defined" error when the line of my customized filter in my python coprocessing script is read in for pipeline coprocessing. What should I do to get my custom filter wrapped in python so that it can be recognized and used as part of the python pipeline script for coprocessing? Any advice and suggestions are very much appreciated.

Thanks,

Hong

_______________________________________________
Powered by www.kitware.com<http://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

_______________________________________________
Powered by www.kitware.com<http://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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20131002/cfe476d1/attachment-0001.htm>