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 hon...@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.ba...@kitware.com]
*Sent:* Tuesday, October 01, 2013 2:19 PM
*To:* Hong Yi
*Cc:* David E DeMarle; paraview@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 hon...@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
Re: [Paraview] My own filter as part of pipeline for coprocessing raises name not defined error
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.ba...@kitware.com]
Sent: Thursday, October 03, 2013 10:19 AM
To: Hong Yi
Cc: David E DeMarle; paraview@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
hon...@renci.orgmailto:hon...@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.ba...@kitware.commailto:andy.ba...@kitware.com]
Sent: Tuesday, October 01, 2013 2:19 PM
To: Hong Yi
Cc: David E DeMarle; paraview@paraview.orgmailto:paraview@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
hon...@renci.orgmailto:hon...@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)
Re: [Paraview] My own filter as part of pipeline for coprocessing raises name not defined error
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 hon...@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.ba...@kitware.com]
*Sent:* Thursday, October 03, 2013 10:19 AM
*To:* Hong Yi
*Cc:* David E DeMarle; paraview@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 hon...@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.ba...@kitware.com]
*Sent:* Tuesday, October 01, 2013 2:19 PM
*To:* Hong Yi
*Cc:* David E DeMarle; paraview@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
Re: [Paraview] My own filter as part of pipeline for coprocessing raises name not defined error
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.ba...@kitware.com]
Sent: Tuesday, October 01, 2013 2:19 PM
To: Hong Yi
Cc: David E DeMarle; paraview@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
hon...@renci.orgmailto:hon...@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
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 hon...@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.ba...@kitware.com]
*Sent:* Friday, September 27, 2013 3:00 PM
*To:* Hong Yi
*Cc:* David E DeMarle; paraview@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 hon...@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|ManagePlugins
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
Re: [Paraview] My own filter as part of pipeline for coprocessing raises name not defined error
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.ba...@kitware.com]
Sent: Friday, September 27, 2013 3:00 PM
To: Hong Yi
Cc: David E DeMarle; paraview@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
hon...@renci.orgmailto:hon...@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.dema...@kitware.commailto:dave.dema...@kitware.com]
Sent: Thursday, September 26, 2013 1:28 PM
To: Andy Bauer
Cc: Hong Yi; paraview@paraview.orgmailto:paraview@paraview.org
Subject: Re: [Paraview] My own filter as part of pipeline for coprocessing
raises name not
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 hon...@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|ManagePlugins 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.dema...@kitware.com] *Sent:* Thursday, September 26, 2013 1:28 PM *To:* Andy Bauer *Cc:* Hong Yi; paraview@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. RD 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.dema...@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. RD 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.ba...@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 hon...@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
Re: [Paraview] My own filter as part of pipeline for coprocessing raises name not defined error
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. RD 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.ba...@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 hon...@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 ___ 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
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. RD 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.dema...@kitware.comwrote: 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. RD 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.ba...@kitware.comwrote: 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 hon...@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 ___ 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
Re: [Paraview] My own filter as part of pipeline for coprocessing raises name not defined error
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.dema...@kitware.com] Sent: Thursday, September 26, 2013 1:28 PM To: Andy Bauer Cc: Hong Yi; paraview@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. RD 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.dema...@kitware.commailto:dave.dema...@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. RD Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909tel:518-881-4909 On Wed, Sep 25, 2013 at 10:34 PM, Andy Bauer andy.ba...@kitware.commailto:andy.ba...@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 hon...@renci.orgmailto:hon...@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.comhttp://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.comhttp://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
[Paraview] My own filter as part of pipeline for coprocessing raises name not defined error
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
Re: [Paraview] My own filter as part of pipeline for coprocessing raises name not defined error
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 hon...@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
