[Paraview] display bonds between atoms using paraview

[Jian Luo]

Hi everyone,

I am in the field of atomic simulation.
Paraview can display atoms beautifully, but I currently cannot find a way
to draw bonds between atoms within certain distance.
Can anyone help me with this? Thanks very much.

Best Regards,
LJ


On Thu, Oct 3, 2013 at 11:09 AM, <paraview-request at paraview.org> wrote:

> Send ParaView mailing list submissions to
>         paraview at paraview.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://www.paraview.org/mailman/listinfo/paraview
> or, via email, send a message with subject or body 'help' to
>         paraview-request at paraview.org
>
> You can reach the person managing the list at
>         paraview-owner at paraview.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ParaView digest..."
>
>
> Today's Topics:
>
>    1. Re: My own filter as part of pipeline for coprocessing raises
>       "name not defined" error (Andy Bauer)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 3 Oct 2013 11:09:15 -0400
> From: Andy Bauer <andy.bauer at kitware.com>
> Subject: Re: [Paraview] My own filter as part of pipeline for
>         coprocessing raises "name not defined" error
> To: Hong Yi <hongyi at renci.org>
> Cc: "paraview at paraview.org" <paraview at paraview.org>
> Message-ID:
>         <
> CAMaOp+F1nzKJfHzZ9FvNOjmSioFbQcsiTcQqxBc7ygm8szkJkA at mail.gmail.com>
> Content-Type: text/plain; charset="windows-1252"
>
> 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_Applicationsbut
> > 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.htm
> >
>
> ------------------------------
>
> _______________________________________________
> 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
>
>
> End of ParaView Digest, Vol 114, Issue 6
> ****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20131003/2837fc9e/attachment-0001.htm>