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

Thu Oct 3 11:09:15 EDT 2013

Hmm, I would check the link line for your adaptor and for creating the
executable to see if the plugin library is included there. Something else
you can try is explicitly create the plugin's filter in the adaptor code to
make sure that it is linked in properly.

Regards,
Andy

On Thu, Oct 3, 2013 at 10:41 AM, Hong Yi <hongyi at renci.org> wrote:

>  Hi Andy,****
>
> ** **
>
> That is exactly what I did, and I also modified CMakeLists.txt to link
> ${PARAVIEW_PLUGINLIST}  to the target via target_link_libraries. However,
> the symbol “pv_plugin_instance_SMVorticity” is undefined in the built
> target static library, while following the same process to build pvbatch
> and pvpython executable works, i.e., the same plugin symbol is defined in
> built pvpython executable. Since it is static linking, I know linking order
> matters, but have not got it to work by adjusting linking orders. Let me
> know if you have ideas on what I could try to figure out and resolve this
> issue.****
>
> ** **
>
> Thanks,****
>
> ** **
>
> Hong****
>
> ** **
>
> ** **
>
> *From:* Andy Bauer [mailto:andy.bauer at kitware.com]
> *Sent:* Thursday, October 03, 2013 10:19 AM
>
> *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,****
>
> There won't be a separate library created for Python wrapping your plugin
> for doing ParaView. Did you add in the following to your adaptor:****
>
> #ifndef BUILD_SHARED_LIBS****
>
> #include "pvStaticPluginsInit.h"****
>
> #endif****
>
>
> And then in the adaptor initialization step you should have something in
> it like:****
>
> #ifndef BUILD_SHARED_LIBS****
>
> paraview_static_plugins_init();****
>
> #endif****
>
> If that doesn't work then it will probably take a bit of tinkering to
> figure out what's wrong.
>
> Regards,
> Andy****
>
> ** **
>
> On Wed, Oct 2, 2013 at 12:28 PM, Hong Yi <hongyi at renci.org> wrote:****
>
> 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> 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]
> *Sent:* Friday, September 27, 2013 3:00 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****
>
>  ****
>
> 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> 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]
> *Sent:* Thursday, September 26, 2013 1:28 PM
> *To:* Andy Bauer
> *Cc:* Hong Yi; 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****
>
>  ****
>
> On Thu, Sep 26, 2013 at 12:23 PM, David E DeMarle <
> 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****
>
>  ****
>
> On Wed, Sep 25, 2013 at 10:34 PM, Andy Bauer <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> 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
>
> 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
>
> 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/20131003/9f68cf01/attachment-0001.htm>