Re: [Paraview] Differences between OpenGL and OpenGL2 versions of ParaView

[Adam Lyon]

Hi Ken - Wow - that's awesome! Thanks very much! If I build ParaView from
the master branch of GitLab, will I get these changes? If so, I can try it
and let you know what I see. Thanks again! -- Adam
___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] Procedure for compiling Catalyst

[Adam Lyon]

Well, reading that page again, it doesn't mention VTK, but adding
"--recursive" to git clone will get the submodule. You should probably
delete your repository and clone it again following the instructions at
https://gitlab.kitware.com/paraview/paraview/blob/master/CONTRIBUTING.md.
-- A

*--*

*Adam L. Lyon*
*Scientist; Associate Division Head for Systems for Scientific Applications*

Scientific Computing Division & Muon g-2 Experiment
Fermi National Accelerator Laboratory
630 840 5522 office
www.fnal.gov
l...@fnal.gov

Connect with us!
News <http://news.fnal.gov/>  |  Facebook
<https://www.facebook.com/Fermilab>  |  Twitter
<https://twitter.com/Fermilab>

On Mon, Jul 25, 2016 at 2:58 PM, Adam Lyon <l...@fnal.gov> wrote:

> You need to follow the instructions at
> https://gitlab.kitware.com/paraview/paraview/blob/master/CONTRIBUTING.md
> . That will tell you how to checkout the VTK submodule. -- Adam
>
> *--*
>
> *Adam L. Lyon*
> *Scientist; Associate Division Head for Systems for Scientific
> Applications*
>
> Scientific Computing Division & Muon g-2 Experiment
> Fermi National Accelerator Laboratory
> 630 840 5522 office
> www.fnal.gov
> l...@fnal.gov
>
> Connect with us!
> News <http://news.fnal.gov/>  |  Facebook
> <https://www.facebook.com/Fermilab>  |  Twitter
> <https://twitter.com/Fermilab>
>
> On Mon, Jul 25, 2016 at 2:43 PM, Christopher Neal <chrisn...@snumerics.com
> > wrote:
>
>> Hey guys,
>>
>>
>>
>> Have you ever had an issue with cmake concerning some missing VTK files?
>> I typed Adam’s command exactly after cloning the Paraview repo(git clone
>> https://github.com/Kitware/ParaView.git). I made a ParaView_build
>> directory and executed Adam’s command in the build directory. I’m seeing
>> the error shown below. The VTK folder in the cloned source directory is
>> completely empty.
>>
>>
>> CMake Error at CMakeLists.txt:615 (include):
>>
>>   include could not find load file:
>>
>>
>>
>> vtkModuleAPI
>>
>>
>>
>>
>>
>> CMake Error at CMakeLists.txt:616 (include):
>>
>>   include could not find load file:
>>
>>
>>
>> vtkModuleMacros
>>
>>
>>
>>
>>
>> CMake Error at CMakeLists.txt:621 (include):
>>
>>   include could not find load file:
>>
>>
>>
>> vtkDetermineCompilerFlags
>>
>>
>>
>>
>>
>> CMake Error at CMake/ParaViewModuleTop.cmake:44
>> (vtk_add_to_module_search_path):
>>
>>   Unknown CMake command "vtk_add_to_module_search_path".
>>
>> Call Stack (most recent call first):
>>
>>   CMakeLists.txt:652 (include)
>>
>>
>>
>> Thank you,
>>
>> Chris Neal
>>
>>
>>
>> *From: *Adam Lyon <l...@fnal.gov>
>> *Date: *Monday, July 25, 2016 at 1:50 PM
>> *To: *Andy Bauer <andy.ba...@kitware.com>
>> *Cc: *Christopher Neal <chrisn...@snumerics.com>, jeff wright <
>> jeffwrigh...@gmail.com>, "paraview@paraview.org" <paraview@paraview.org>
>>
>> *Subject: *Re: [Paraview] Procedure for compiling Catalyst
>>
>>
>>
>> Hi - I build the ParaView package with Catalyst turned on (but the
>> ParaView GUI turned off). My cmake command is (sorry for the poor
>> formatting, some of these options may not be useful for you)...
>>
>>
>>
>> cmake -DCMAKE_BUILD_TYPE:STRING=Release -DCMAKE_SKIP_INSTALL_RPATH:BOOL=YES 
>> -DBUILD_TESTING:BOOL=OFF -DPARAVIEW_BUILD_QT_GUI:BOOL=OFF 
>> -DVTK_RENDERING_BACKEND=OpenGL2 -DPARAVIEW_USE_MPI:BOOL=ON 
>> -DPARAVIEW_ENABLE_PYTHON:BOOL=ON 
>> -DPARAVIEW_INSTALL_DEVELOPMENT_FILES:BOOL=ON 
>> -DPARAVIEW_BUILD_CATALYST_ADAPTERS:BOOL=ON 
>> -DPARAVIEW_BUILD_PLUGIN_AnalyzeNIfTIIO:BOOL=FALSE 
>> -DPARAVIEW_BUILD_PLUGIN_ArrowGlyph:BOOL=FALSE 
>> -DPARAVIEW_BUILD_PLUGIN_CDIReader:BOOL=FALSE 
>> -DPARAVIEW_BUILD_PLUGIN_EyeDomeLighting:BOOL=FALSE 
>> -DPARAVIEW_BUILD_PLUGIN_GMVReader:BOOL=FALSE 
>> -DPARAVIEW_BUILD_PLUGIN_GeodesicMeasurement:BOOL=FALSE 
>> -DPARAVIEW_BUILD_PLUGIN_H5PartReader:BOOL=FALSE 
>> -DPARAVIEW_BUILD_PLUGIN_InSituExodus:BOOL=FALSE 
>> -DPARAVIEW_BUILD_PLUGIN_MantaView:BOOL=FALSE 
>> -DPARAVIEW_BUILD_PLUGIN_Moments:BOOL=FALSE 
>> -DPARAVIEW_BUILD_PLUGIN_NonOrthogonalSource:BOOL=FALSE 
>> -DPARAVIEW_BUILD_PLUGIN_PacMan:BOOL=FALSE 
>> -DPARAVIEW_BUILD_PLUGIN_PointSprite:BOOL=FALSE 
>> -DPARAVIEW_BUILD_PLUGIN_RGBZView:BOOL=FALSE 
>> -DPARAVIEW_BUILD_PLUGIN_SLACTools:BOOL=

Re: [Paraview] Procedure for compiling Catalyst

[Adam Lyon]

You need to follow the instructions at
https://gitlab.kitware.com/paraview/paraview/blob/master/CONTRIBUTING.md .
That will tell you how to checkout the VTK submodule. -- Adam

*--*

*Adam L. Lyon*
*Scientist; Associate Division Head for Systems for Scientific Applications*

Scientific Computing Division & Muon g-2 Experiment
Fermi National Accelerator Laboratory
630 840 5522 office
www.fnal.gov
l...@fnal.gov

Connect with us!
News <http://news.fnal.gov/>  |  Facebook
<https://www.facebook.com/Fermilab>  |  Twitter
<https://twitter.com/Fermilab>

On Mon, Jul 25, 2016 at 2:43 PM, Christopher Neal <chrisn...@snumerics.com>
wrote:

> Hey guys,
>
>
>
> Have you ever had an issue with cmake concerning some missing VTK files? I
> typed Adam’s command exactly after cloning the Paraview repo(git clone
> https://github.com/Kitware/ParaView.git). I made a ParaView_build
> directory and executed Adam’s command in the build directory. I’m seeing
> the error shown below. The VTK folder in the cloned source directory is
> completely empty.
>
>
> CMake Error at CMakeLists.txt:615 (include):
>
>   include could not find load file:
>
>
>
> vtkModuleAPI
>
>
>
>
>
> CMake Error at CMakeLists.txt:616 (include):
>
>   include could not find load file:
>
>
>
> vtkModuleMacros
>
>
>
>
>
> CMake Error at CMakeLists.txt:621 (include):
>
>   include could not find load file:
>
>
>
> vtkDetermineCompilerFlags
>
>
>
>
>
> CMake Error at CMake/ParaViewModuleTop.cmake:44
> (vtk_add_to_module_search_path):
>
>   Unknown CMake command "vtk_add_to_module_search_path".
>
> Call Stack (most recent call first):
>
>   CMakeLists.txt:652 (include)
>
>
>
> Thank you,
>
> Chris Neal
>
>
>
> *From: *Adam Lyon <l...@fnal.gov>
> *Date: *Monday, July 25, 2016 at 1:50 PM
> *To: *Andy Bauer <andy.ba...@kitware.com>
> *Cc: *Christopher Neal <chrisn...@snumerics.com>, jeff wright <
> jeffwrigh...@gmail.com>, "paraview@paraview.org" <paraview@paraview.org>
>
> *Subject: *Re: [Paraview] Procedure for compiling Catalyst
>
>
>
> Hi - I build the ParaView package with Catalyst turned on (but the
> ParaView GUI turned off). My cmake command is (sorry for the poor
> formatting, some of these options may not be useful for you)...
>
>
>
> cmake -DCMAKE_BUILD_TYPE:STRING=Release -DCMAKE_SKIP_INSTALL_RPATH:BOOL=YES 
> -DBUILD_TESTING:BOOL=OFF -DPARAVIEW_BUILD_QT_GUI:BOOL=OFF 
> -DVTK_RENDERING_BACKEND=OpenGL2 -DPARAVIEW_USE_MPI:BOOL=ON 
> -DPARAVIEW_ENABLE_PYTHON:BOOL=ON -DPARAVIEW_INSTALL_DEVELOPMENT_FILES:BOOL=ON 
> -DPARAVIEW_BUILD_CATALYST_ADAPTERS:BOOL=ON 
> -DPARAVIEW_BUILD_PLUGIN_AnalyzeNIfTIIO:BOOL=FALSE 
> -DPARAVIEW_BUILD_PLUGIN_ArrowGlyph:BOOL=FALSE 
> -DPARAVIEW_BUILD_PLUGIN_CDIReader:BOOL=FALSE 
> -DPARAVIEW_BUILD_PLUGIN_EyeDomeLighting:BOOL=FALSE 
> -DPARAVIEW_BUILD_PLUGIN_GMVReader:BOOL=FALSE 
> -DPARAVIEW_BUILD_PLUGIN_GeodesicMeasurement:BOOL=FALSE 
> -DPARAVIEW_BUILD_PLUGIN_H5PartReader:BOOL=FALSE 
> -DPARAVIEW_BUILD_PLUGIN_InSituExodus:BOOL=FALSE 
> -DPARAVIEW_BUILD_PLUGIN_MantaView:BOOL=FALSE 
> -DPARAVIEW_BUILD_PLUGIN_Moments:BOOL=FALSE 
> -DPARAVIEW_BUILD_PLUGIN_NonOrthogonalSource:BOOL=FALSE 
> -DPARAVIEW_BUILD_PLUGIN_PacMan:BOOL=FALSE 
> -DPARAVIEW_BUILD_PLUGIN_PointSprite:BOOL=FALSE 
> -DPARAVIEW_BUILD_PLUGIN_RGBZView:BOOL=FALSE 
> -DPARAVIEW_BUILD_PLUGIN_SLACTools:BOOL=FALSE 
> -DPARAVIEW_BUILD_PLUGIN_SciberQuestToolKit:BOOL=FALSE 
> -DPARAVIEW_BUILD_PLUGIN_SierraPlotTools:BOOL=FALSE 
> -DPARAVIEW_BUILD_PLUGIN_StreamingParticles:BOOL=FALSE 
> -DPARAVIEW_BUILD_PLUGIN_SurfaceLIC:BOOL=FALSE 
> -DPARAVIEW_BUILD_PLUGIN_ThickenLayeredCells:BOOL=FALSE 
> -DPARAVIEW_BUILD_PLUGIN_UncertaintyRendering:BOOL=FALSE 
> -DPARAVIEW_BUILD_PLUGIN_AcceleratedAlgorithms:BOOL=OFF 
> -DVTK_USE_CXX11_FEATURES:BOOL=ON -DCMAKE_INSTALL_PREFIX=/somewhere 
> /path/to/paraview/git/source
>
>
>
>
>
> This will build ParaView, VTK, and Catalyst and install header files so you 
> can build your code with it. -- Adam
>
>
>
> *--*
>
>
>
> *Adam L. Lyon*
>
> *Scientist; Associate Division Head for Systems for Scientific
> Applications*
>
>
>
> Scientific Computing Division & Muon g-2 Experiment
>
> Fermi National Accelerator Laboratory
>
> 630 840 5522 office
>
> www.fnal.gov
>
> l...@fnal.gov
>
>
>
> Connect with us!
> News <http://news.fnal.gov/>  |  Facebook
> <https://www.facebook.com/Fermilab>  |  Twitter
> <https://twitter.com/Fermilab>
>
>
>
> On Mon, Jul 25, 2016 at 12:16 PM, Andy Bauer <andy.ba...@

Re: [Paraview] Procedure for compiling Catalyst

[Adam Lyon]

Hi - I build the ParaView package with Catalyst turned on (but the ParaView
GUI turned off). My cmake command is (sorry for the poor formatting, some
of these options may not be useful for you)...

cmake -DCMAKE_BUILD_TYPE:STRING=Release
-DCMAKE_SKIP_INSTALL_RPATH:BOOL=YES -DBUILD_TESTING:BOOL=OFF
-DPARAVIEW_BUILD_QT_GUI:BOOL=OFF -DVTK_RENDERING_BACKEND=OpenGL2
-DPARAVIEW_USE_MPI:BOOL=ON -DPARAVIEW_ENABLE_PYTHON:BOOL=ON
-DPARAVIEW_INSTALL_DEVELOPMENT_FILES:BOOL=ON
-DPARAVIEW_BUILD_CATALYST_ADAPTERS:BOOL=ON
-DPARAVIEW_BUILD_PLUGIN_AnalyzeNIfTIIO:BOOL=FALSE
-DPARAVIEW_BUILD_PLUGIN_ArrowGlyph:BOOL=FALSE
-DPARAVIEW_BUILD_PLUGIN_CDIReader:BOOL=FALSE
-DPARAVIEW_BUILD_PLUGIN_EyeDomeLighting:BOOL=FALSE
-DPARAVIEW_BUILD_PLUGIN_GMVReader:BOOL=FALSE
-DPARAVIEW_BUILD_PLUGIN_GeodesicMeasurement:BOOL=FALSE
-DPARAVIEW_BUILD_PLUGIN_H5PartReader:BOOL=FALSE
-DPARAVIEW_BUILD_PLUGIN_InSituExodus:BOOL=FALSE
-DPARAVIEW_BUILD_PLUGIN_MantaView:BOOL=FALSE
-DPARAVIEW_BUILD_PLUGIN_Moments:BOOL=FALSE
-DPARAVIEW_BUILD_PLUGIN_NonOrthogonalSource:BOOL=FALSE
-DPARAVIEW_BUILD_PLUGIN_PacMan:BOOL=FALSE
-DPARAVIEW_BUILD_PLUGIN_PointSprite:BOOL=FALSE
-DPARAVIEW_BUILD_PLUGIN_RGBZView:BOOL=FALSE
-DPARAVIEW_BUILD_PLUGIN_SLACTools:BOOL=FALSE
-DPARAVIEW_BUILD_PLUGIN_SciberQuestToolKit:BOOL=FALSE
-DPARAVIEW_BUILD_PLUGIN_SierraPlotTools:BOOL=FALSE
-DPARAVIEW_BUILD_PLUGIN_StreamingParticles:BOOL=FALSE
-DPARAVIEW_BUILD_PLUGIN_SurfaceLIC:BOOL=FALSE
-DPARAVIEW_BUILD_PLUGIN_ThickenLayeredCells:BOOL=FALSE
-DPARAVIEW_BUILD_PLUGIN_UncertaintyRendering:BOOL=FALSE
-DPARAVIEW_BUILD_PLUGIN_AcceleratedAlgorithms:BOOL=OFF
-DVTK_USE_CXX11_FEATURES:BOOL=ON -DCMAKE_INSTALL_PREFIX=/somewhere
/path/to/paraview/git/source



This will build ParaView, VTK, and Catalyst and install header files
so you can build your code with it. -- Adam


*--*

*Adam L. Lyon*
*Scientist; Associate Division Head for Systems for Scientific Applications*

Scientific Computing Division & Muon g-2 Experiment
Fermi National Accelerator Laboratory
630 840 5522 office
www.fnal.gov
l...@fnal.gov

Connect with us!
News   |  Facebook
  |  Twitter


On Mon, Jul 25, 2016 at 12:16 PM, Andy Bauer  wrote:

> Hi Chris,
>
> Catalyst is not a separate entity from ParaView. It is a subset of
> ParaView that is used for *in situ *processing. The concept of the
> editions is that the subset of interest differs based on the desired *in
> situ *processing and linking your simulation code to all of ParaView
> Catalyst can take up a significant amount of memory. Hopefully the blog
> post at https://blog.kitware.com/paraview-catalyst-editions-what-are-they/
> may clear up your confusion.
>
> Best,
> Andy
>
> On Mon, Jul 25, 2016 at 1:07 PM, Christopher Neal  > wrote:
>
>> Thank you Andy,
>>
>>
>>
>> My understanding is that the Catalyst editions can be compiled separately
>> from Paraview i.e. I do not need to have a version of Paraview compiled in
>> order to compile a Catalyst edition. Is this correct?
>>
>> Thank you,
>>
>> Chris
>>
>>
>>
>> *From: *Andy Bauer 
>> *Date: *Friday, July 22, 2016 at 8:23 PM
>> *To: *Christopher Neal 
>> *Cc: *"paraview@paraview.org" 
>> *Subject: *Re: [Paraview] Procedure for compiling Catalyst
>>
>>
>>
>> Hi Chris,
>>
>> You can get the Catalyst editions source code at
>> http://www.paraview.org/download/ by just selecting Catalyst editions
>> for Type of Download. If you're just getting started though I would
>> recommend doing a build of ParaView without the GUI. Yes this will require
>> learning a bit of CMake (see instructions for building ParaView at
>> http://www.paraview.org/Wiki/ParaView:Build_And_Install) but it will
>> likely be smoother for you for understanding Catalyst's capabilities. Also,
>> it's much easier to link a simulation code with Catalyst through CMake than
>> specifying all of the include directories and libraries. When you're
>> looking for a lean build of Catalyst on an HPC machine then I'd suggest
>> going the edition route (the editions help avoid cross-compilation issues
>> on HPC machines too).
>>
>> Best,
>>
>> Andy
>>
>>
>>
>> On Fri, Jul 22, 2016 at 6:16 PM, Christopher Neal <
>> chrisn...@snumerics.com> wrote:
>>
>> Hi All,
>>
>>
>>
>> I’m interesting in trying to compile Paraview Catalyst. I understand that
>> there are ‘Editions’ of the Catalyst library that vary in the amount of
>> functions that are included from the Paraview library. That’s about the
>> extent of my knowledge about the actual source for the Catalyst library.
>> The documentation that I have found for compiling Catalyst is a bit
>> dated(~3 years old), and I haven’t been able to locate an up-to-date set of
>> documents that detail the compilation procedure for building Catalyst.  If
>> I want Catalyst, must I first have a version of Paraview built from scratch
>> 

Re: [Paraview] Connect ParaViewWeb to Catalyst

[Adam Lyon]

Hi Sven - I'm very interested in how you got catalyst to work with
paraviewweb.  Can you post your code somewhere (or send me a tar file or
something)? I would very much appreciate that. Thanks very much! -- Adam

*--*

*Adam L. Lyon*
*Scientist; Associate Division Head for Systems for Scientific Applications*

Scientific Computing Division & Muon g-2 Experiment
Fermi National Accelerator Laboratory
630 840 5522 office
www.fnal.gov
l...@fnal.gov

Connect with us!
News   |  Facebook
  |  Twitter


On Mon, May 23, 2016 at 11:44 AM, Sven Kramer 
wrote:

> Sure, I would share the code. But as I said, I haven't done anything more
> than wrapping pqCatalystConnectReaction::connect() and hacking several
> lines in the python rpc server, which are probably not done right.
> If it helps, I can try to reconstruct all the lines I have modified and
> clean up the stuff. However, you'll probably find a cleaner solution to
> invoke pqCatalystConnectReaction::connect() from the web client.
>
> Sven
>
> 2016-05-23 7:22 GMT+02:00 Sebastien Jourdain <
> sebastien.jourd...@kitware.com>:
>
>> Glad to ear that you managed to get something going. If you feel like
>> sharing your code, we might be able to provide some integration into
>> ParaView and/or ParaViewWeb proper.
>>
>> Seb
>>
>> On Sat, May 21, 2016 at 11:53 AM, Sven Kramer 
>> wrote:
>>
>>> Thank you, Seb,
>>> it seems like I am getting it to work. There are still some difficulties
>>> because of my limited javascript experience, but with some quick
>>> workarounds I do have the Catalyst output displayed from ParaViewWeb. As
>>> you said, nothing else was required than wrapping the C functions in python.
>>>
>>> Thanks
>>> Sven
>>>
>>>
>>> 2016-05-20 18:59 GMT+02:00 Sebastien Jourdain <
>>> sebastien.jourd...@kitware.com>:
>>>
 Hi Sven,

 I am not aware on any specific developer documentation for Catalyst on
 the ParaView side (but I haven't worked on that subject for years),
 although Utkarsh or Andy might know.

 Usually looking at the code and redoing it in the Python world is what
 is required, but as I said, I'm not sure of what it means since I don't
 know that code anymore. ;-)

 For the timeframe, I can't tell (meaning I don't know), but we can
 still try to help you or implement the missing piece via support contract
 if that make sense on your end.

 Thanks,

 Seb

 On Fri, May 20, 2016 at 10:46 AM, Sven Kramer 
 wrote:

> Hello Seb,
> glad to read your answer. So the problem is not only that I was unable
> to find the relevant information.
>
> You say, you have not (yet) written the required code. Does "not
> (yet)" mean that it is on the agenda maybe within the next half year? Then
> I could find a workaround and look forward to the next Paraview updates.
>
> Otherwise I would try to work on the implementation for connecting
> Paraviewweb to Catalyst output. Is there any developer documentation of
> Catalysts "specific socket connection"? Or some general Catalyst developer
> information? Those would be great to get started.
> My first attempt would be to "wrap" the functionality of
> Qt/ApplicationComponents/pqCatalystConnectReaction.cxx into pvserver and
> make it available to the web client. Or are the necessary steps much more
> involved?
>
> Thank you
> Sven
>
>
> 2016-05-20 15:42 GMT+02:00 Sebastien Jourdain <
> sebastien.jourd...@kitware.com>:
>
>> Hi Sven,
>>
>> Live catalyst connection require a specific socket connection to the
>> in-situ process with some special handling.
>> We did not (yet) wrote the Python code to perform that specific
>> action for ParaViewWeb so it could be triggered by the web client or
>> configured via an argument at launch time.
>> I don't see any reason why this couldn't work, but as for now, I also
>> don't know an easy step to do it without spending time doing it myself.
>>
>> Seb
>>
>> On Thu, May 19, 2016 at 1:52 PM, Sven Kramer 
>> wrote:
>>
>>> Hello,
>>> I am looking for the recommended steps how to display an in-situ
>>> (live) Catalyst simulation through ParaViewWeb.
>>>
>>> After some efforts I am able to run ParaViewWeb successfully and I
>>> can view a Catalyst-enabled simulation in paraview.
>>>
>>> I hope, it is also possible to show the live Catalyst output via
>>> ParaViewWeb, but I cannot imagine how to achieve this. I tried starting 
>>> a
>>> pvserver as mentioned at the end of
>>> https://blog.kitware.com/introduction-to-paraview-catalyst-live/
>>> and giving "--ds-host localhost --ds-port 1" options to
>>> 

Re: [Paraview] Differences between OpenGL and OpenGL2 versions of ParaView

[Adam Lyon]

Hi - Just thought I'd let you all know that I've finally made progress on
this problem. To recap, I have a MultiBlockDataSet (MBDS) containing
PolyData objects. The PolyData objects don't all have the same attributes
(some have Normals, some don't; some have particular FieldData, others
don't). This "heterogeneous" MBDS reflects the visualization data I get
from the Geant4 simulation program - some things have particular attributes
and others don't.

As you (Ken & Utkarsh) pointed out, such a heterogenous MBDS triggers a
generic renderer in ParaView v5/OpenGL2 unless every block within the MBDS
has the same structure. The generic renderer is extremely slow, and it
makes interacting with the visualization in ParaView painful (e.g. a few
frames per second or less).

I now have a filter (I should fix my ParaView Source that creates the MBDS
- but that'll be for later) that runs through the MBDS and makes it
homogeneous - that is it removes Normals and TCoords (only a very few
PolyData have them) and adds missing FieldData with defaults. This triggers
the fast renderer - and boy it's *a lot* faster. 30x - 200x faster frame
rates compared to the generic renderer.  The fast renderer is at least many
times faster than the OpenGL1 renderer in ParaView v4.4.

I'm quite happy with this solution and am glad I can finally use the new
features in ParaView v5/OpenGL2. Woohoo!

I'm wondering if other people are going to hit this generic renderer
slowness.. I added some code to my build of ParaView v5 in
vtkCompositePolyDataMapper2.cxx that std::cout's a message when the generic
renderer is triggered and why (e.g. heterogeneous Normals, TCoords,
Scalars, etc). I found that to be very helpful. Perhaps the render
annotation could show such a message (e.g. in vtkPVRenderView).

Thanks again for your help!!  And Happy New Year!! -- Adam

*--*

*Adam L. Lyon*
*Scientist; Associate Division Head for Systems for Scientific Applications*

Scientific Computing Division & Muon g-2 Experiment
Fermi National Accelerator Laboratory
630 840 5522 office
www.fnal.gov
l...@fnal.gov

Connect with us!
Newsletter <http://www.fnal.gov/pub/today/>  |  Facebook
<https://www.facebook.com/Fermilab>  |  Twitter
<https://twitter.com/Fermilab>

On Wed, Dec 16, 2015 at 1:46 PM, Ken Martin <ken.mar...@kitware.com> wrote:

> This code is all new hence the change. On the plus side if you moved from
> 4000 blocks of 10 triangles each to 4000 blocks of 1 triangles each the
> rendering performance would probably not slow down. The overhead is all in
> starting and stopping each of those 4000 mappers.
>
> The old backend wrote everything out into a displaylist and the OpenGL
> driver handled optimizing it and dealing with any inconsistencies. The new
> backend has to build vertex buffer objects and we currently only collapse
> all the blocks together into one VBO if the VBO structure is the same for
> every block.
>
> Thanks
> Ken
>
>
> On Wed, Dec 16, 2015 at 2:22 PM, Adam Lyon <l...@fnal.gov> wrote:
>
>> Hi Ken - thanks for your reply. It's looking like the last approach - I
>> figure out why I'm getting different blocks - is the way to go. It's
>> already clear that not all of the blocks have colors. Some of the blocks
>> are created by vtk sources (e.g. VtkConeSource) and others are created by
>> hand (me setting points and cells). The latter won't have normals. Maybe
>> some of the former do.  I'll look into this.
>>
>> I'm curious as to why I didn't have any of these problems in v4.4 -- or
>> is this two path multiblock rendering code all new for v5?  Thanks again!!
>> -- Adam
>>
>> *--*
>>
>> *Adam L. Lyon*
>> *Scientist; Associate Division Head for Systems for Scientific
>> Applications*
>>
>> Scientific Computing Division & Muon g-2 Experiment
>> Fermi National Accelerator Laboratory
>> 630 840 5522 office
>> www.fnal.gov
>> l...@fnal.gov
>>
>> Connect with us!
>> Newsletter <http://www.fnal.gov/pub/today/>  |  Facebook
>> <https://www.facebook.com/Fermilab>  |  Twitter
>> <https://twitter.com/Fermilab>
>>
>> On Wed, Dec 16, 2015 at 11:47 AM, Ken Martin <ken.mar...@kitware.com>
>> wrote:
>>
>>> I don't really have a solution planned for that case. The data size is
>>> trivially small but it falls into the slow path because each block of data
>>> may or may not have normals or colors or tcoords. The nature of the blocks
>>> is heterogeneous. So you end up with 4000 mappers each rendering 10
>>> triangles. Currently there are two paths for rendering multiblock data.
>>>
>>> 1) every block has the same properties (normals, tcoords, triangles)  In
>>> that 

Re: [Paraview] Differences between OpenGL and OpenGL2 versions of ParaView

[Adam Lyon]

Hi Ken and Utkarsh, Checking back in with this issue... I still find that
interaction with the g-2 ring in ParaView v5rc2 is very slow compared to
v4.4. It looks like you all have a solution in mind. I'm happy to build
from master to try it if the solution is there. Thanks again and Happy
Holidays!!!  I really appreciate you all looking at this problem. -- Adam

*--*

*Adam L. Lyon*
*Scientist; Associate Division Head for Systems for Scientific Applications*

Scientific Computing Division & Muon g-2 Experiment
Fermi National Accelerator Laboratory
630 840 5522 office
www.fnal.gov
l...@fnal.gov

Connect with us!
Newsletter   |  Facebook
  |  Twitter


On Fri, Nov 20, 2015 at 1:48 PM, Ken Martin  wrote:

> You could maybe have an actor per LOD and then swap actors in and out.
>
> Actor owns the property, backface property, and texture. Changes to those
> objects can cause VBO/IBO rebuilds (switching from surface to wireframe,
> adding a texture map, flat versus phong shading, edge visibility, line
> width, etc.) The old backend only looked at the actor's property which is
> sort of broken.
>
> For example in the old backend: create two properties, one set to
> wireframe, one set to surface. Then create an actor and mapper set to use
> display lists. Switching between the two properties will cause an actor
> mtime change, but the properties themselves would still have low mtimes I
> believe. In that case the old backend will end up stuck in one
> representation because it only looks at the property mtime not actor.
>
> To make the VBO/IBO rebuild safely (but less often than currently) I think
> the solution is to check the mtimes as is done currently, if those are
> modified then collect up the parameters that require a VBO or IBO rebuild
> and compare them to a stored value from the last build. If different force
> a rebuild. That is the best solution IMO just takes some time. I sort of
> wanted to do that anyhow but now I can say you forced me into it :-)
>
> Thanks
> Ken
>
>
>
>
> On Fri, Nov 20, 2015 at 1:57 PM, Utkarsh Ayachit <
> utkarsh.ayac...@kitware.com> wrote:
>
>> > I did notice PV is forcing the actor to be modified every time the LOD
>> > changes (which is a lot). Modifying the actor causes the VBO/IBOs to
>> rebuild
>> > so it would be better not to do that unless you really need to and in
>> this
>> > case I'm not sure why it is being done. Specifically I think it is in
>> > vtkPVLODActor::Modified where it calls this->Device->Modified() . The
>> LOD
>> > actor is being modified as a result of calling SetEnableLOD constantly
>> > flipping between true and false. That is not the cause of this issue
>> but it
>> > is something I noticed that will be a pain for large datasets.
>>
>> Ken, currently, there's no way around it. vtkPVLODActor works by
>> changing the mapper on the internal vtkActor aka Device when LOD mode
>> is toggled. That will indeed change the Device's MTime even if we stop
>> calling this->Device->Modiied() in the vtkPVLODActor::Modified(). The
>> question is why are VBO/IBOs rebuild if actor MTime changes? VBOs
>> would be data dependent right? Most of data-dependent properties are
>> on  the Mapper, not the actor. Shouldn't the code that re-creates
>> VBO/IBOs only depend on Mapper's MTime?
>>
>> Utkarsh
>>
>
>
>
> --
> Ken Martin PhD
> Chairman & CFO
> Kitware Inc.
> 28 Corporate Drive
> Clifton Park NY 12065
> 518 371 3971
>
> This communication, including all attachments, contains confidential and
> legally privileged information, and it is intended only for the use of the
> addressee.  Access to this email by anyone else is unauthorized. If you are
> not the intended recipient, any disclosure, copying, distribution or any
> action taken in reliance on it is prohibited and may be unlawful. If you
> received this communication in error please notify us immediately and
> destroy the original message.  Thank you.
>
___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] Differences between OpenGL and OpenGL2 versions of ParaView

[Adam Lyon]

Hi Ken - thanks for your reply. It's looking like the last approach - I
figure out why I'm getting different blocks - is the way to go. It's
already clear that not all of the blocks have colors. Some of the blocks
are created by vtk sources (e.g. VtkConeSource) and others are created by
hand (me setting points and cells). The latter won't have normals. Maybe
some of the former do.  I'll look into this.

I'm curious as to why I didn't have any of these problems in v4.4 -- or is
this two path multiblock rendering code all new for v5?  Thanks again!! --
Adam

*--*

*Adam L. Lyon*
*Scientist; Associate Division Head for Systems for Scientific Applications*

Scientific Computing Division & Muon g-2 Experiment
Fermi National Accelerator Laboratory
630 840 5522 office
www.fnal.gov
l...@fnal.gov

Connect with us!
Newsletter <http://www.fnal.gov/pub/today/>  |  Facebook
<https://www.facebook.com/Fermilab>  |  Twitter
<https://twitter.com/Fermilab>

On Wed, Dec 16, 2015 at 11:47 AM, Ken Martin <ken.mar...@kitware.com> wrote:

> I don't really have a solution planned for that case. The data size is
> trivially small but it falls into the slow path because each block of data
> may or may not have normals or colors or tcoords. The nature of the blocks
> is heterogeneous. So you end up with 4000 mappers each rendering 10
> triangles. Currently there are two paths for rendering multiblock data.
>
> 1) every block has the same properties (normals, tcoords, triangles)  In
> that case we use a fast path, the actual values of course may be different,
> but if one block has texture coordinates then all of them will.
>
> 2) blocks can be different, meaning that one block may be triangles with
> normals while the next could be lines with texture coordinates. In that
> case we fall back on just giving each block its own mapper. That is the
> slow path.
>
> What would benefit your case is a third path (or a better slow path) where
> the blocks can be different, but we combine the ones that are the same so
> that hopefully we end up with maybe 4 or 5 mappers each with 1000 or so
> triangles. Implementing that is not trivial though so I don't think anyone
> has plans for it yet.
>
> Another approach would be to look at what is generating your data and try
> to determine why some blocks have normals while others do not. because if
> you can get the blocks to be homogeneous then you will get the fast path.
>
> Thanks
> Ken
>
>
>
>
>
>
>
> On Wed, Dec 16, 2015 at 11:39 AM, Adam Lyon <l...@fnal.gov> wrote:
>
>> Hi Ken and Utkarsh, Checking back in with this issue... I still find that
>> interaction with the g-2 ring in ParaView v5rc2 is very slow compared to
>> v4.4. It looks like you all have a solution in mind. I'm happy to build
>> from master to try it if the solution is there. Thanks again and Happy
>> Holidays!!!  I really appreciate you all looking at this problem. -- Adam
>>
>> *--*
>>
>> *Adam L. Lyon*
>> *Scientist; Associate Division Head for Systems for Scientific
>> Applications*
>>
>> Scientific Computing Division & Muon g-2 Experiment
>> Fermi National Accelerator Laboratory
>> 630 840 5522 office
>> www.fnal.gov
>> l...@fnal.gov
>>
>> Connect with us!
>> Newsletter <http://www.fnal.gov/pub/today/>  |  Facebook
>> <https://www.facebook.com/Fermilab>  |  Twitter
>> <https://twitter.com/Fermilab>
>>
>> On Fri, Nov 20, 2015 at 1:48 PM, Ken Martin <ken.mar...@kitware.com>
>> wrote:
>>
>>> You could maybe have an actor per LOD and then swap actors in and out.
>>>
>>> Actor owns the property, backface property, and texture. Changes to
>>> those objects can cause VBO/IBO rebuilds (switching from surface to
>>> wireframe, adding a texture map, flat versus phong shading, edge
>>> visibility, line width, etc.) The old backend only looked at the actor's
>>> property which is sort of broken.
>>>
>>> For example in the old backend: create two properties, one set to
>>> wireframe, one set to surface. Then create an actor and mapper set to use
>>> display lists. Switching between the two properties will cause an actor
>>> mtime change, but the properties themselves would still have low mtimes I
>>> believe. In that case the old backend will end up stuck in one
>>> representation because it only looks at the property mtime not actor.
>>>
>>> To make the VBO/IBO rebuild safely (but less often than currently) I
>>> think the solution is to check the mtimes as is done currently, if those
>>> are modified then collect up the parameters that require a V

Re: [Paraview] Differences between OpenGL and OpenGL2 versions of ParaView

[Adam Lyon]

Indeed you are right! I see the rendering you show for 5.0. Interesting
change with regard to setting the solid color first.

One thing I should note is that image manipulation (pan, zoom, rotate) is
quite slow in 5.0 compared to 4.4. For example, rotating the ring with a
solid color, I get frame-rates  (from the annotation text) of over 100 fps
with 4.4. With 5.0 I generally see about 20-25fps.  Do you see this too?
Thanks again!! -- Adam

*--*

*Adam L. Lyon*
*Scientist; Associate Division Head for Systems for Scientific Applications*

Scientific Computing Division & Muon g-2 Experiment
Fermi National Accelerator Laboratory
630 840 5522 office
www.fnal.gov
l...@fnal.gov

Connect with us!
Newsletter   |  Facebook
  |  Twitter


On Tue, Nov 17, 2015 at 4:44 PM, Utkarsh Ayachit <
utkarsh.ayac...@kitware.com> wrote:

> Ken, what Adam has is a multiblock dataset with field data array named
> "Color" (with certain blocks missing this array). Now when you color by
> this array and then uncheck "Map Scalars", I get the attached images. I'd
> contend that 5.0 with OpenGL2 rendering is correct. In 4.4 it would just
> bleed some random color through for blocks with missing "Color" array. In
> 5.0, the color used is the "Solid Color" set before changing the array to
> color with.
>
> Adam, are you not seeing rendering as I am with 5.0? I no longer get
> rendering similar to the images you reported.
>
> Utkarsh
>
> ​
>
___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] Differences between OpenGL and OpenGL2 versions of ParaView

[Adam Lyon]

Hi Ken - Thanks for your e-mail. If you look at the first message in this
thread with the pictures, you'll see that the OpenGL2 image doesn't look
like the OpenGL1 image. The OpenGL1 image is correct. The OpenGL2 image
should be identical if things are working. That message has a link to my
dropbox directory with a file "gm2ring.zip" - that has the vtm file and its
components, so you should be able to try this yourself. At this point, I
think you can just compare how that file looks (hit the -Y button to get a
good top-down view) in ParaView 4.4 and in ParaView 5.0RC and see the
difference. The image in ParaView 4.4 is correct.

Let me know if that doesn't work or you need me to do anything. I'm happy
to help here! Though sorry I can't help with the code.

-- Adam

*--*

*Adam L. Lyon*
*Scientist; Associate Division Head for Systems for Scientific Applications*

Scientific Computing Division & Muon g-2 Experiment
Fermi National Accelerator Laboratory
630 840 5522 office
www.fnal.gov
l...@fnal.gov

Connect with us!
Newsletter <http://www.fnal.gov/pub/today/>  |  Facebook
<https://www.facebook.com/Fermilab>  |  Twitter
<https://twitter.com/Fermilab>

On Mon, Nov 16, 2015 at 8:11 AM, Ken Martin <ken.mar...@kitware.com> wrote:

> I'd be happy to address this if someone can explain to me what the problem
> is. A failing VTK test would be really nice as I'm a bit lost from the
> email. I just don't understand the specifics of what is going on here. It
> sounds like some sort of CompositePolyData2 with a field data where the
> field data contains block colors and the field data is on the
> first/last/all block of the dataset? Or maybe I'm confused :-) Do you know
> where the code to handle this for OpenGL1 is?
>
> Thanks
> Ken
>
> On Fri, Nov 13, 2015 at 2:16 AM, Adam Lyon <l...@fnal.gov> wrote:
>
>> Hi - I know you all are busy preparing for SC15, but this bug persists in
>> the ParaView v5 release candidate, which makes it difficult for me to use.
>> Is there a chance this problem can be looked at and resolved before the
>> final release? Thanks! Happy SC15!! -- A
>>
>> *--*
>>
>> *Adam L. Lyon*
>> *Scientist; Associate Division Head for Systems for Scientific
>> Applications*
>>
>> Scientific Computing Division & Muon g-2 Experiment
>> Fermi National Accelerator Laboratory
>> 630 840 5522 office
>> www.fnal.gov
>> l...@fnal.gov
>>
>> Connect with us!
>> Newsletter <http://www.fnal.gov/pub/today/>  |  Facebook
>> <https://www.facebook.com/Fermilab>  |  Twitter
>> <https://twitter.com/Fermilab>
>>
>> On Fri, Aug 7, 2015 at 12:32 PM, Utkarsh Ayachit <
>> utkarsh.ayac...@kitware.com> wrote:
>>
>>> Adam,
>>>
>>> The problem is that the OpenGL2 implementation doesn't work correctly
>>> for field-data arrays yet.
>>> I've reported a bug: http://www.paraview.org/Bug/view.php?id=15627
>>>
>>> We'll have in tracked down soon.
>>>
>>> Utkarsh
>>>
>>> On Mon, Aug 3, 2015 at 2:59 PM, Adam Lyon <l...@fnal.gov> wrote:
>>>
>>>> Hi Joachim, Do you want me to send in a bug report for these problems?
>>>> I assume there's no work-around that I can do to make things work. Using
>>>> OpenGL2 is quite a bit faster, so I'm hoping a fix can come out soon.
>>>> Thanks! -- Adam
>>>>
>>>> *--*
>>>>
>>>> *Adam L. Lyon*
>>>> *Scientist; Associate Division Head for Systems for Scientific
>>>> Applications*
>>>>
>>>> Scientific Computing Division & Muon g-2 Experiment
>>>> Fermi National Accelerator Laboratory
>>>> 630 840 5522 office
>>>> www.fnal.gov
>>>> l...@fnal.gov
>>>>
>>>> Connect with us!
>>>> Newsletter <http://www.fnal.gov/pub/today/>  |  Facebook
>>>> <https://www.facebook.com/Fermilab>  |  Twitter
>>>> <https://twitter.com/Fermilab>
>>>>
>>>> On Fri, Jul 31, 2015 at 10:53 AM, Adam L Lyon <l...@fnal.gov> wrote:
>>>>
>>>>> Hi Joachim - Yes, I noticed that the default color is now
>>>>> vtkBlockColors. However I changed that to the "color" vector in my data 
>>>>> and
>>>>> that change was not honored by the program. Thanks, Adam
>>>>>
>>>>> *--*
>>>>>
>>>>> *Adam L. Lyon*
>>>>> *Scientist; Associate Division Head for Systems for Scientific
>>>>> Applications*
>>>&

Re: [Paraview] Differences between OpenGL and OpenGL2 versions of ParaView

[Adam Lyon]

Hi - I know you all are busy preparing for SC15, but this bug persists in
the ParaView v5 release candidate, which makes it difficult for me to use.
Is there a chance this problem can be looked at and resolved before the
final release? Thanks! Happy SC15!! -- A

*--*

*Adam L. Lyon*
*Scientist; Associate Division Head for Systems for Scientific Applications*

Scientific Computing Division & Muon g-2 Experiment
Fermi National Accelerator Laboratory
630 840 5522 office
www.fnal.gov
l...@fnal.gov

Connect with us!
Newsletter <http://www.fnal.gov/pub/today/>  |  Facebook
<https://www.facebook.com/Fermilab>  |  Twitter
<https://twitter.com/Fermilab>

On Fri, Aug 7, 2015 at 12:32 PM, Utkarsh Ayachit <
utkarsh.ayac...@kitware.com> wrote:

> Adam,
>
> The problem is that the OpenGL2 implementation doesn't work correctly for
> field-data arrays yet.
> I've reported a bug: http://www.paraview.org/Bug/view.php?id=15627
>
> We'll have in tracked down soon.
>
> Utkarsh
>
> On Mon, Aug 3, 2015 at 2:59 PM, Adam Lyon <l...@fnal.gov> wrote:
>
>> Hi Joachim, Do you want me to send in a bug report for these problems? I
>> assume there's no work-around that I can do to make things work. Using
>> OpenGL2 is quite a bit faster, so I'm hoping a fix can come out soon.
>> Thanks! -- Adam
>>
>> *--*
>>
>> *Adam L. Lyon*
>> *Scientist; Associate Division Head for Systems for Scientific
>> Applications*
>>
>> Scientific Computing Division & Muon g-2 Experiment
>> Fermi National Accelerator Laboratory
>> 630 840 5522 office
>> www.fnal.gov
>> l...@fnal.gov
>>
>> Connect with us!
>> Newsletter <http://www.fnal.gov/pub/today/>  |  Facebook
>> <https://www.facebook.com/Fermilab>  |  Twitter
>> <https://twitter.com/Fermilab>
>>
>> On Fri, Jul 31, 2015 at 10:53 AM, Adam L Lyon <l...@fnal.gov> wrote:
>>
>>> Hi Joachim - Yes, I noticed that the default color is now
>>> vtkBlockColors. However I changed that to the "color" vector in my data and
>>> that change was not honored by the program. Thanks, Adam
>>>
>>> *--*
>>>
>>> *Adam L. Lyon*
>>> *Scientist; Associate Division Head for Systems for Scientific
>>> Applications*
>>>
>>> Scientific Computing Division & Muon g-2 Experiment
>>> Fermi National Accelerator Laboratory
>>> 630 840 5522 office
>>> www.fnal.gov
>>> l...@fnal.gov
>>>
>>> Connect with us!
>>> Newsletter <http://www.fnal.gov/pub/today/>  |  Facebook
>>> <https://www.facebook.com/Fermilab>  |  Twitter
>>> <https://twitter.com/Fermilab>
>>>
>>> On Fri, Jul 31, 2015 at 2:41 AM, Joachim Pouderoux <
>>> joachim.pouder...@kitware.com> wrote:
>>>
>>>> Adam,
>>>>
>>>> The color difference can be explained by the default coloring mode
>>>> introduced recently (before the git tag version you tested with).
>>>> Multiblocks are now automatically colored by blocks. Toggle the Color
>>>> Legend and see the coloring array, "vtkBlockColors" is selected wereas in
>>>> previous version it was Solid Color I guess.
>>>> Regarding the missing pieces, I can tell that with the same git version
>>>> and with the OpenGL backend 1 (the old), all pieces are correctly drawn.
>>>> What is specific is that this missing blocks (the data has like a global
>>>> gemetry block + all the internal pieces) are the last block if the first
>>>> level block hierarchy.
>>>>
>>>> Joachim
>>>>
>>>>
>>>> *Joachim Pouderoux*
>>>>
>>>> *PhD, Technical Expert*
>>>> *Kitware SAS <http://www.kitware.fr>*
>>>>
>>>>
>>>> 2015-07-30 22:19 GMT+02:00 Adam Lyon <l...@fnal.gov>:
>>>>
>>>>> Hi,  I'm trying to use ParaView built with OpenGL2, hoping to see some
>>>>> speed improvement when I interact with my visualization. Indeed for a
>>>>> complicated geometry I see significant speed up (e.g. ~25 fps with OpenGL2
>>>>> vs. 5 fps with regular ParaView). But I also see serious errors in the
>>>>> display. I've attached two images of our "g-2 muon storage ring" (never
>>>>> mind what it actually is, though it is very cool :-) ..
>>>>>
>>>>> [image: Inline image 1]
>>>>>
>>>>> The first, mostly blue image, is from regular Par

Re: [Paraview] Some questions about Catalyst Live Visualization

[Adam Lyon]

Hi Andy - I've pushed my "CatalystLiveButtons" plugin to
https://github.com/lyon-fnal/CatalystLiveButtons . It has a button for the
single step and a connection button that also sets the Paused state once
the connection is established. I hope you don't mind me "borrowing" your
icons. One day I'll make better ones.Don't hesitate to send me comments
or concerns for this code. Thanks! -- Adam

*--*

*Adam L. Lyon*
*Scientist; Associate Division Head for Systems for Scientific Applications*

Scientific Computing Division & Muon g-2 Experiment
Fermi National Accelerator Laboratory
630 840 5522 office
www.fnal.gov
l...@fnal.gov

Connect with us!
Newsletter   |  Facebook
  |  Twitter


On Mon, Nov 2, 2015 at 1:17 PM, Andy Bauer  wrote:

> Hi Adam,
>
> I just wanted to let you know that the gui name that's shown in the GUI
> when doing a live connection is now fixed in ParaView master. It will be in
> the upcoming 5.0 release.
>
> Please let me know when you have your plugin for the "continue to the next
> time step" available and we'll look into merging that into ParaView master.
>
> Best regards,
> Andy
>
> On Mon, Nov 2, 2015 at 10:42 AM, Dan Lipsa  wrote:
>
>> Hi Andy,
>>
>>
>>>  (e.g. images, data extracts or to Catalyst Live via a connected client)
>>> then RequestDataDescription() should return that there's no work to do so
>>> that no cycles are wasted generating the VTK object.
>>>
>>
>> This is a good idea. I think we could  indeed return that there is no
>> work on the test for execution frequencies so that the user does not have
>> to do another test.
>> Here is the bug report for this:
>>
>> http://www.vtk.org/Bug/view.php?id=15815
>>
>> Dan
>>
>>
>
___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] Some questions about Catalyst Live Visualization

[Adam Lyon]

HI Andy - I think you've got the right idea!  Thanks.   By the way, I've
written a little ParaView plugin that makes a Catalyst Live "single step"
button. If you have the simulation paused on a time step, clicking the
button will allow the simulation to advance to the next time step and will
pause again. I'll post the code to Github hopefully later today -- and make
a little movie. This will be really useful for us!!  Thanks again. -- Adam

*--*

*Adam L. Lyon*
*Scientist; Associate Division Head for Systems for Scientific Applications*

Scientific Computing Division & Muon g-2 Experiment
Fermi National Accelerator Laboratory
630 840 5522 office
www.fnal.gov
l...@fnal.gov

Connect with us!
Newsletter <http://www.fnal.gov/pub/today/>  |  Facebook
<https://www.facebook.com/Fermilab>  |  Twitter
<https://twitter.com/Fermilab>

On Sat, Oct 31, 2015 at 8:17 AM, Andy Bauer <andy.ba...@kitware.com> wrote:

> Hi Adam,
>
> In my opinion it is a bug. My thinking is this, if there's no Catalyst
> work to do then the performance penalty for using Catalyst should be
> negligible. The VTK grid should only be generated if there's Catalyst work
> to do (this will usually be quite fast but certainly may not be negligible)
> and if there aren't any outputs (e.g. images, data extracts or to Catalyst
> Live via a connected client) then RequestDataDescription() should return
> that there's no work to do so that no cycles are wasted generating the VTK
> object. If you don't mind wasting cycles, I can always have you compute
> some bitcoins for me instead :)
>
> Additionally, all of this should be automated (and can be) such that it
> just works for users without having to modify the Python scripts for
> something as simple as this.
>
> Best regards,
> Andy
>
> On Fri, Oct 30, 2015 at 1:47 PM, Dan Lipsa <dan.li...@kitware.com> wrote:
>
>> Hi Adam,
>>
>> On Fri, Oct 30, 2015 at 10:20 AM, Adam Lyon <l...@fnal.gov> wrote:
>>
>>> I'd like this code to only run if a ParaView client is actually
>>> connected (because if there's no client connected then it's making VTK
>>> objects that no human is looking at, so it's wasting time). So I'd like to
>>> know if there's a way that my code could ask the adapter if a client is
>>> connected. I hope I explained that better - let me know if not.
>>>
>>
>> Live was added as a way to support catalyst processing: the user can
>> examine down-sampled data produced by the simulation but also modify the
>> processing pipeline while the simulation is running. The processing
>> pipeline is mainly used to save data/images from the simulation. So I don't
>> think we considered your use case. Looking at the code it does not seem to
>> be a way to query if there is a connection to ParaView Live. I don't think
>> it would be too difficult to add it though.
>>
>> Dan
>>
>>
>
___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] Some questions about Catalyst Live Visualization

[Adam Lyon]

Hi Andy - thanks for the answers!! You misunderstood my question #2. I'm
not reporting a bug -- the adapter works fine and feeds data appropriately.
Right now my code to translate my data objects to VTK objects runs no
matter what. I'd like this code to only run if a ParaView client is
actually connected (because if there's no client connected then it's making
VTK objects that no human is looking at, so it's wasting time). So I'd like
to know if there's a way that my code could ask the adapter if a client is
connected. I hope I explained that better - let me know if not.

Yes - I'll post a YouTube video shortly!! Having this capability (live view
of processing) was an important thing on my list for making ParaView useful
to us High Energy Physicists -- we're excited that it works.

Thanks again,  Adam

*--*

*Adam L. Lyon*
*Scientist; Associate Division Head for Systems for Scientific Applications*

Scientific Computing Division & Muon g-2 Experiment
Fermi National Accelerator Laboratory
630 840 5522 office
www.fnal.gov
l...@fnal.gov

Connect with us!
Newsletter <http://www.fnal.gov/pub/today/>  |  Facebook
<https://www.facebook.com/Fermilab>  |  Twitter
<https://twitter.com/Fermilab>

On Fri, Oct 30, 2015 at 8:33 AM, Andy Bauer <andy.ba...@kitware.com> wrote:

> Hi Adam,
>
> To rename the objects in the pipeline, you should be able to do:
> simSteps = coprocessor.CreateProducer(datadescription, 'simSteps')
> RenameSource('simSteps', simSteps)
> simCalHits = coprocessor.CreateProducer(datadescription, 'simCalHits')
> RenameSource('simCalHits', simCalHits)
>
> Please let me know if this doesn't work for you. Also, now that you
> mention it, this should be done automatically anyway so I'll put in a
> feature request for this since I like the idea a lot.
>
> As for not generating the VTK polydata object when no client is connected,
> this might be due to the adaptor implementation or a bug in the live
> functionality. I can't say for sure at this point but will check it out on
> our end in the near future. For the adaptor, the execution flow is that
> first the adaptor should call RequestDataDescription() of any Catalyst
> pipelines to see if there's any work to be done. Check the result of
> RequestDataDescription() to see if anything needs to be done. If not,
> return control to the simulation. If there is work to be done, create the
> VTK data objects and then call DoCoprocessing(). In this use case it's
> possible that RequestDataDescription() isn't checking whether or not a
> client is connected to see if there's something to do. Realistically, it's
> here where it should see if the client is connected or if there are any
> other Catalyst outputs that need to be generated. I'm on travel this week
> so I can't check on this easily but hope to try it out next week. I'll get
> back to you when I do though.
>
> As for implementing an "advance to next time step" functionality, that
> makes sense to me as well. That will take a little bit of work (not much
> but nothing that can be fixed in the Python script alone).
>
> By the way, can you share any pictures or videos of this in action? This
> sounds really cool!
>
> Best regards,
> Andy
>
>
> On Thu, Oct 29, 2015 at 5:51 PM, Adam Lyon <l...@fnal.gov> wrote:
>
>> Hi, I have recently been successful in hooking up Catalyst to our
>> Particle Physics analysis framework that we use at Fermilab. Our main use
>> case is to make an "event display" - that is a visualization of a high
>> energy physics event (e.g. particle collision) in a simulated detector. The
>> Catalyst Live feature allows us to connect ParaView to a running analysis
>> or simulation job and visualize the events as they're being processed. It's
>> very cool. This is typically a program difficult to write - but Catalyst
>> and ParaView make this much easier.
>>
>> This is a bit different from CFD simulations -- for us each "time step"
>> in an independent event. But the system works really well and many here are
>> excited about it.
>>
>> I have three questions (so far) about the Catalyst Live system...
>>
>> 1) The VTK objects appear in the connected ParaView client as
>> "PVTrivialProducer0", "PVTrivialProducer1", etc. The catalyst pipeline
>> knows the real names of these objects. For example I have in my catalyst
>> pipeline python script,
>>
>> ...
>> simSteps = coprocessor.CreateProducer(datadescription, 'simSteps')
>> simCalHits = coprocessor.CreateProducer(datadescription, 'simCalHits')
>> ...
>> [that's the only stuff in the pipeline]
>>
>> Is there some way to have "simSteps" and "simCalHits" show u

[Paraview] Some questions about Catalyst Live Visualization

[Adam Lyon]

Hi, I have recently been successful in hooking up Catalyst to our Particle
Physics analysis framework that we use at Fermilab. Our main use case is to
make an "event display" - that is a visualization of a high energy physics
event (e.g. particle collision) in a simulated detector. The Catalyst Live
feature allows us to connect ParaView to a running analysis or simulation
job and visualize the events as they're being processed. It's very cool.
This is typically a program difficult to write - but Catalyst and ParaView
make this much easier.

This is a bit different from CFD simulations -- for us each "time step" in
an independent event. But the system works really well and many here are
excited about it.

I have three questions (so far) about the Catalyst Live system...

1) The VTK objects appear in the connected ParaView client as
"PVTrivialProducer0", "PVTrivialProducer1", etc. The catalyst pipeline
knows the real names of these objects. For example I have in my catalyst
pipeline python script,

...
simSteps = coprocessor.CreateProducer(datadescription, 'simSteps')
simCalHits = coprocessor.CreateProducer(datadescription, 'simCalHits')
...
[that's the only stuff in the pipeline]

Is there some way to have "simSteps" and "simCalHits" show up in my
ParaView client instead of "PVTrivialProducer0", etc?

2) Our analysis framework converts our data objects into VTK objects for
feeding to Catalyst (usually vtkPolyData). This is a potentially expensive
operation. If no ParaView client is connected to the Catalyst port, then
there's no reason for this translation to occur (we just using the Live
visualization feature at the moment). Is there a way for the adapter (e.g.
the vtkCPProcessor object) to discover if a ParaView client is connected?
That would save time if no one is connected.

3) In addition to setting breakpoints on time steps (events for us), it
would be nice to have a "single step" feature that would simply allow the
program to advance to the next one. Is that possible to do from python
within ParaView?

Thanks!!! -- Adam

*--*

*Adam L. Lyon*
*Scientist; Associate Division Head for Systems for Scientific Applications*

Scientific Computing Division & Muon g-2 Experiment
Fermi National Accelerator Laboratory
630 840 5522 office
www.fnal.gov
l...@fnal.gov

Connect with us!
Newsletter   |  Facebook
  |  Twitter

___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] Differences between OpenGL and OpenGL2 versions of ParaView

[Adam Lyon]

Awesome!  Thanks -- Adam

On Friday, August 7, 2015, Utkarsh Ayachit utkarsh.ayac...@kitware.com
wrote:

 Adam,

 The problem is that the OpenGL2 implementation doesn't work correctly for
 field-data arrays yet.
 I've reported a bug: http://www.paraview.org/Bug/view.php?id=15627

 We'll have in tracked down soon.

 Utkarsh

 On Mon, Aug 3, 2015 at 2:59 PM, Adam Lyon l...@fnal.gov
 javascript:_e(%7B%7D,'cvml','l...@fnal.gov'); wrote:

 Hi Joachim, Do you want me to send in a bug report for these problems? I
 assume there's no work-around that I can do to make things work. Using
 OpenGL2 is quite a bit faster, so I'm hoping a fix can come out soon.
 Thanks! -- Adam

 *--*

 *Adam L. Lyon*
 *Scientist; Associate Division Head for Systems for Scientific
 Applications*

 Scientific Computing Division  Muon g-2 Experiment
 Fermi National Accelerator Laboratory
 630 840 5522 office
 www.fnal.gov
 l...@fnal.gov javascript:_e(%7B%7D,'cvml','l...@fnal.gov');

 Connect with us!
 Newsletter http://www.fnal.gov/pub/today/  |  Facebook
 https://www.facebook.com/Fermilab  |  Twitter
 https://twitter.com/Fermilab

 On Fri, Jul 31, 2015 at 10:53 AM, Adam L Lyon l...@fnal.gov
 javascript:_e(%7B%7D,'cvml','l...@fnal.gov'); wrote:

 Hi Joachim - Yes, I noticed that the default color is now
 vtkBlockColors. However I changed that to the color vector in my data and
 that change was not honored by the program. Thanks, Adam

 *--*

 *Adam L. Lyon*
 *Scientist; Associate Division Head for Systems for Scientific
 Applications*

 Scientific Computing Division  Muon g-2 Experiment
 Fermi National Accelerator Laboratory
 630 840 5522 office
 www.fnal.gov
 l...@fnal.gov javascript:_e(%7B%7D,'cvml','l...@fnal.gov');

 Connect with us!
 Newsletter http://www.fnal.gov/pub/today/  |  Facebook
 https://www.facebook.com/Fermilab  |  Twitter
 https://twitter.com/Fermilab

 On Fri, Jul 31, 2015 at 2:41 AM, Joachim Pouderoux 
 joachim.pouder...@kitware.com
 javascript:_e(%7B%7D,'cvml','joachim.pouder...@kitware.com'); wrote:

 Adam,

 The color difference can be explained by the default coloring mode
 introduced recently (before the git tag version you tested with).
 Multiblocks are now automatically colored by blocks. Toggle the Color
 Legend and see the coloring array, vtkBlockColors is selected wereas in
 previous version it was Solid Color I guess.
 Regarding the missing pieces, I can tell that with the same git version
 and with the OpenGL backend 1 (the old), all pieces are correctly drawn.
 What is specific is that this missing blocks (the data has like a global
 gemetry block + all the internal pieces) are the last block if the first
 level block hierarchy.

 Joachim


 *Joachim Pouderoux*

 *PhD, Technical Expert*
 *Kitware SAS http://www.kitware.fr*


 2015-07-30 22:19 GMT+02:00 Adam Lyon l...@fnal.gov
 javascript:_e(%7B%7D,'cvml','l...@fnal.gov');:

 Hi,  I'm trying to use ParaView built with OpenGL2, hoping to see some
 speed improvement when I interact with my visualization. Indeed for a
 complicated geometry I see significant speed up (e.g. ~25 fps with OpenGL2
 vs. 5 fps with regular ParaView). But I also see serious errors in the
 display. I've attached two images of our g-2 muon storage ring (never
 mind what it actually is, though it is very cool :-) ..

 [image: Inline image 1]

 The first, mostly blue image, is from regular ParaView (downloaded Mac
 binary 4.3.1 64 bit)  and is what the ring is supposed to look like. There
 is a color vector selected and I've unchecked Map scalars so that the
 colors are true. And indeed the RGB color values in the vector are what
 is shown on the display.


 [image: Inline image 2]
 The next image, with a chunk on the left side missing, is from the
 OpenGL2 ParaView (Mac built from source 4.3.1-882-gbdceec7 64 bit)
 configured identically as the other ParaView. So it should look identical
 to the mostly blue picture. Along with the missing chunk, you see the
 colors look very wrong. What's even stranger is that the missing chunk is
 really missing - not invisible - the visualization is made of multiblock
 datasets, and right clicking where a structure should be only brings up 
 the
 link camera option.

 You can try this yourself -- see
 https://www.dropbox.com/sh/900ocfc90v0w3r6/AACmqz8kVrGPUMnJbpxAFOzBa?dl=0
 . The gm2ring.zip file has gm2ring.vtm (with the corresponding gm2ring
 directory) and gm2ring.pvsm to restore my configuration.

 I'm looking forward to using the OpenGL2 version when it works better.
 I hope this helps in working out its kinks (or hoping to find out I've
 built or configured something incorrectly). Let me know how I can help!
 Thanks! -- Adam
 *--*

 *Adam L. Lyon*
 *Scientist; Associate Division Head for Systems for Scientific
 Applications*

 Scientific Computing Division  Muon g-2 Experiment
 Fermi National Accelerator Laboratory
 630 840 5522 office
 www.fnal.gov
 l...@fnal.gov javascript:_e(%7B%7D,'cvml','l...@fnal.gov');

 Connect with us

Re: [Paraview] Differences between OpenGL and OpenGL2 versions of ParaView

[Adam Lyon]

Hi Joachim, Do you want me to send in a bug report for these problems? I
assume there's no work-around that I can do to make things work. Using
OpenGL2 is quite a bit faster, so I'm hoping a fix can come out soon.
Thanks! -- Adam

*--*

*Adam L. Lyon*
*Scientist; Associate Division Head for Systems for Scientific Applications*

Scientific Computing Division  Muon g-2 Experiment
Fermi National Accelerator Laboratory
630 840 5522 office
www.fnal.gov
l...@fnal.gov

Connect with us!
Newsletter http://www.fnal.gov/pub/today/  |  Facebook
https://www.facebook.com/Fermilab  |  Twitter
https://twitter.com/Fermilab

On Fri, Jul 31, 2015 at 10:53 AM, Adam L Lyon l...@fnal.gov wrote:

 Hi Joachim - Yes, I noticed that the default color is now vtkBlockColors.
 However I changed that to the color vector in my data and that change was
 not honored by the program. Thanks, Adam

 *--*

 *Adam L. Lyon*
 *Scientist; Associate Division Head for Systems for Scientific
 Applications*

 Scientific Computing Division  Muon g-2 Experiment
 Fermi National Accelerator Laboratory
 630 840 5522 office
 www.fnal.gov
 l...@fnal.gov

 Connect with us!
 Newsletter http://www.fnal.gov/pub/today/  |  Facebook
 https://www.facebook.com/Fermilab  |  Twitter
 https://twitter.com/Fermilab

 On Fri, Jul 31, 2015 at 2:41 AM, Joachim Pouderoux 
 joachim.pouder...@kitware.com wrote:

 Adam,

 The color difference can be explained by the default coloring mode
 introduced recently (before the git tag version you tested with).
 Multiblocks are now automatically colored by blocks. Toggle the Color
 Legend and see the coloring array, vtkBlockColors is selected wereas in
 previous version it was Solid Color I guess.
 Regarding the missing pieces, I can tell that with the same git version
 and with the OpenGL backend 1 (the old), all pieces are correctly drawn.
 What is specific is that this missing blocks (the data has like a global
 gemetry block + all the internal pieces) are the last block if the first
 level block hierarchy.

 Joachim


 *Joachim Pouderoux*

 *PhD, Technical Expert*
 *Kitware SAS http://www.kitware.fr*


 2015-07-30 22:19 GMT+02:00 Adam Lyon l...@fnal.gov:

 Hi,  I'm trying to use ParaView built with OpenGL2, hoping to see some
 speed improvement when I interact with my visualization. Indeed for a
 complicated geometry I see significant speed up (e.g. ~25 fps with OpenGL2
 vs. 5 fps with regular ParaView). But I also see serious errors in the
 display. I've attached two images of our g-2 muon storage ring (never
 mind what it actually is, though it is very cool :-) ..

 [image: Inline image 1]

 The first, mostly blue image, is from regular ParaView (downloaded Mac
 binary 4.3.1 64 bit)  and is what the ring is supposed to look like. There
 is a color vector selected and I've unchecked Map scalars so that the
 colors are true. And indeed the RGB color values in the vector are what
 is shown on the display.


 [image: Inline image 2]
 The next image, with a chunk on the left side missing, is from the
 OpenGL2 ParaView (Mac built from source 4.3.1-882-gbdceec7 64 bit)
 configured identically as the other ParaView. So it should look identical
 to the mostly blue picture. Along with the missing chunk, you see the
 colors look very wrong. What's even stranger is that the missing chunk is
 really missing - not invisible - the visualization is made of multiblock
 datasets, and right clicking where a structure should be only brings up the
 link camera option.

 You can try this yourself -- see
 https://www.dropbox.com/sh/900ocfc90v0w3r6/AACmqz8kVrGPUMnJbpxAFOzBa?dl=0
 . The gm2ring.zip file has gm2ring.vtm (with the corresponding gm2ring
 directory) and gm2ring.pvsm to restore my configuration.

 I'm looking forward to using the OpenGL2 version when it works better. I
 hope this helps in working out its kinks (or hoping to find out I've built
 or configured something incorrectly). Let me know how I can help!  Thanks!
 -- Adam
 *--*

 *Adam L. Lyon*
 *Scientist; Associate Division Head for Systems for Scientific
 Applications*

 Scientific Computing Division  Muon g-2 Experiment
 Fermi National Accelerator Laboratory
 630 840 5522 office
 www.fnal.gov
 l...@fnal.gov

 Connect with us!
 Newsletter http://www.fnal.gov/pub/today/  |  Facebook
 https://www.facebook.com/Fermilab  |  Twitter
 https://twitter.com/Fermilab

 ___
 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

 Search the list archives at: http://markmail.org/search/?q=ParaView

 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/mailman/listinfo/paraview




___
Powered by www.kitware.com

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Please

Re: [Paraview] Differences between OpenGL and OpenGL2 versions of ParaView

[Adam Lyon]

Hi Joachim - Yes, I noticed that the default color is now vtkBlockColors.
However I changed that to the color vector in my data and that change was
not honored by the program. Thanks, Adam

*--*

*Adam L. Lyon*
*Scientist; Associate Division Head for Systems for Scientific Applications*

Scientific Computing Division  Muon g-2 Experiment
Fermi National Accelerator Laboratory
630 840 5522 office
www.fnal.gov
l...@fnal.gov

Connect with us!
Newsletter http://www.fnal.gov/pub/today/  |  Facebook
https://www.facebook.com/Fermilab  |  Twitter
https://twitter.com/Fermilab

On Fri, Jul 31, 2015 at 2:41 AM, Joachim Pouderoux 
joachim.pouder...@kitware.com wrote:

 Adam,

 The color difference can be explained by the default coloring mode
 introduced recently (before the git tag version you tested with).
 Multiblocks are now automatically colored by blocks. Toggle the Color
 Legend and see the coloring array, vtkBlockColors is selected wereas in
 previous version it was Solid Color I guess.
 Regarding the missing pieces, I can tell that with the same git version
 and with the OpenGL backend 1 (the old), all pieces are correctly drawn.
 What is specific is that this missing blocks (the data has like a global
 gemetry block + all the internal pieces) are the last block if the first
 level block hierarchy.

 Joachim


 *Joachim Pouderoux*

 *PhD, Technical Expert*
 *Kitware SAS http://www.kitware.fr*


 2015-07-30 22:19 GMT+02:00 Adam Lyon l...@fnal.gov:

 Hi,  I'm trying to use ParaView built with OpenGL2, hoping to see some
 speed improvement when I interact with my visualization. Indeed for a
 complicated geometry I see significant speed up (e.g. ~25 fps with OpenGL2
 vs. 5 fps with regular ParaView). But I also see serious errors in the
 display. I've attached two images of our g-2 muon storage ring (never
 mind what it actually is, though it is very cool :-) ..

 [image: Inline image 1]

 The first, mostly blue image, is from regular ParaView (downloaded Mac
 binary 4.3.1 64 bit)  and is what the ring is supposed to look like. There
 is a color vector selected and I've unchecked Map scalars so that the
 colors are true. And indeed the RGB color values in the vector are what
 is shown on the display.


 [image: Inline image 2]
 The next image, with a chunk on the left side missing, is from the
 OpenGL2 ParaView (Mac built from source 4.3.1-882-gbdceec7 64 bit)
 configured identically as the other ParaView. So it should look identical
 to the mostly blue picture. Along with the missing chunk, you see the
 colors look very wrong. What's even stranger is that the missing chunk is
 really missing - not invisible - the visualization is made of multiblock
 datasets, and right clicking where a structure should be only brings up the
 link camera option.

 You can try this yourself -- see
 https://www.dropbox.com/sh/900ocfc90v0w3r6/AACmqz8kVrGPUMnJbpxAFOzBa?dl=0
 . The gm2ring.zip file has gm2ring.vtm (with the corresponding gm2ring
 directory) and gm2ring.pvsm to restore my configuration.

 I'm looking forward to using the OpenGL2 version when it works better. I
 hope this helps in working out its kinks (or hoping to find out I've built
 or configured something incorrectly). Let me know how I can help!  Thanks!
 -- Adam
 *--*

 *Adam L. Lyon*
 *Scientist; Associate Division Head for Systems for Scientific
 Applications*

 Scientific Computing Division  Muon g-2 Experiment
 Fermi National Accelerator Laboratory
 630 840 5522 office
 www.fnal.gov
 l...@fnal.gov

 Connect with us!
 Newsletter http://www.fnal.gov/pub/today/  |  Facebook
 https://www.facebook.com/Fermilab  |  Twitter
 https://twitter.com/Fermilab

 ___
 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

 Search the list archives at: http://markmail.org/search/?q=ParaView

 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

[Paraview] Differences between OpenGL and OpenGL2 versions of ParaView

[Adam Lyon]

Hi,  I'm trying to use ParaView built with OpenGL2, hoping to see some
speed improvement when I interact with my visualization. Indeed for a
complicated geometry I see significant speed up (e.g. ~25 fps with OpenGL2
vs. 5 fps with regular ParaView). But I also see serious errors in the
display. I've attached two images of our g-2 muon storage ring (never
mind what it actually is, though it is very cool :-) ..

[image: Inline image 1]

The first, mostly blue image, is from regular ParaView (downloaded Mac
binary 4.3.1 64 bit)  and is what the ring is supposed to look like. There
is a color vector selected and I've unchecked Map scalars so that the
colors are true. And indeed the RGB color values in the vector are what
is shown on the display.


[image: Inline image 2]
The next image, with a chunk on the left side missing, is from the OpenGL2
ParaView (Mac built from source 4.3.1-882-gbdceec7 64 bit) configured
identically as the other ParaView. So it should look identical to the
mostly blue picture. Along with the missing chunk, you see the colors look
very wrong. What's even stranger is that the missing chunk is really
missing - not invisible - the visualization is made of multiblock datasets,
and right clicking where a structure should be only brings up the link
camera option.

You can try this yourself -- see
https://www.dropbox.com/sh/900ocfc90v0w3r6/AACmqz8kVrGPUMnJbpxAFOzBa?dl=0 .
The gm2ring.zip file has gm2ring.vtm (with the corresponding gm2ring
directory) and gm2ring.pvsm to restore my configuration.

I'm looking forward to using the OpenGL2 version when it works better. I
hope this helps in working out its kinks (or hoping to find out I've built
or configured something incorrectly). Let me know how I can help!  Thanks!
-- Adam
*--*

*Adam L. Lyon*
*Scientist; Associate Division Head for Systems for Scientific Applications*

Scientific Computing Division  Muon g-2 Experiment
Fermi National Accelerator Laboratory
630 840 5522 office
www.fnal.gov
l...@fnal.gov

Connect with us!
Newsletter http://www.fnal.gov/pub/today/  |  Facebook
https://www.facebook.com/Fermilab  |  Twitter
https://twitter.com/Fermilab
___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] Can I parallelize different input files?

[Adam Lyon]

Cool! Thanks - I'll try that.  I tried just loading a few vti files anyway
running the pvserver under mpirun on the multi-core machine. This machine
has no GPU and I got a lot of swrast errors (one per core). So I think I
don't have a good OpenGL on this machine. I tried building my own Mesa
OpenGL according to
http://www.paraview.org/Wiki/ParaView/ParaView_And_Mesa_3D, but got
compilation errors using the newest version of llvm. Then I had to move on
to other things.  Not sure if you've tried this - maybe you have some
ideas. Anyway, I hope to try this again sometime this week.  --- Adam

*--*

*Adam L. Lyon*
*Scientist; Associate Division Head for Systems for Scientific Applications*

Scientific Computing Division  Muon g-2 Experiment
Fermi National Accelerator Laboratory
630 840 5522 office
www.fnal.gov
l...@fnal.gov

Connect with us!
Newsletter http://www.fnal.gov/pub/today/  |  Facebook
https://www.facebook.com/Fermilab  |  Twitter
https://twitter.com/Fermilab

On Sun, Jul 12, 2015 at 8:41 PM, Cory Quammen cory.quam...@kitware.com
wrote:

  Hi Adam,

  The PVTI file format should work perfectly for this application. The
 PVTI file is an XML file that specifies the different pieces in the whole
 image and points to the VTI images that contain the pieces. When loaded,
 each piece should land on a different CPU - if you are running 12 CPUs. The
 extents in your VTI files need to be defined in terms of the overall image
 extent - if they aren't you'll need to modify them so that they are.

  I have attached an example PVTI file with four associated VTI files that
 you can use as a model to define your own PVTI file.

  Please let us know if you have any trouble.

  Thanks,
 Cory


 On Fri, Jul 10, 2015 at 9:34 AM, Adam Lyon l...@fnal.gov wrote:

 Hi - I have 12 fairly large vti files (each one is a simulation of part
 of the magnetic field of my particle physics detector). Each file covers a
 distinct part of the total volume, so that all 12 together covers the whole
 thing. This would seem to be a perfect opportunity to try to parallelize
 Paraview's handling of these files - one CPU per vti file.  I have a
 machine with lots of cores at my disposal. Will Paraview recognize by
 itself that it can parallelize its operations, one CPU per vti file, or do
 I need to do something to make that happen? There's no overlap between the
 files - will that be a problem? My plan is to run a pvserver on the
 many-core CPU machine and connect to it via my Mac. Any advice would be
 helpful and appreciated!  Thanks! -- Adam
   *-*

  *Adam L. Lyon*
 *Scientist; Associate Division Head for Systems for Scientific
 Applications*

  Scientific Computing Division  Muon g-2 Experiment
 Fermi National Accelerator Laboratory
 630 840 5522 office
 www.fnal.gov
 l...@fnal.gov

  Connect with us!
 Newsletter http://www.fnal.gov/pub/today/  |  Facebook
 https://www.facebook.com/Fermilab  |  Twitter
 https://twitter.com/Fermilab

 ___
 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

 Search the list archives at: http://markmail.org/search/?q=ParaView

 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/mailman/listinfo/paraview




  --
 Cory Quammen
 RD Engineer
 Kitware, Inc.

___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

[Paraview] Can I parallelize different input files?

[Adam Lyon]

Hi - I have 12 fairly large vti files (each one is a simulation of part of
the magnetic field of my particle physics detector). Each file covers a
distinct part of the total volume, so that all 12 together covers the whole
thing. This would seem to be a perfect opportunity to try to parallelize
Paraview's handling of these files - one CPU per vti file.  I have a
machine with lots of cores at my disposal. Will Paraview recognize by
itself that it can parallelize its operations, one CPU per vti file, or do
I need to do something to make that happen? There's no overlap between the
files - will that be a problem? My plan is to run a pvserver on the
many-core CPU machine and connect to it via my Mac. Any advice would be
helpful and appreciated!  Thanks! -- Adam
*-*

*Adam L. Lyon*
*Scientist; Associate Division Head for Systems for Scientific Applications*

Scientific Computing Division  Muon g-2 Experiment
Fermi National Accelerator Laboratory
630 840 5522 office
www.fnal.gov
l...@fnal.gov

Connect with us!
Newsletter http://www.fnal.gov/pub/today/  |  Facebook
https://www.facebook.com/Fermilab  |  Twitter
https://twitter.com/Fermilab
___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

[Paraview] What is the numpy way?

[Adam Lyon]

Hi all, I've been debugging a simulation of particle physics experiment --
I usually have the program make a csv file of some data to visualize (for
example, x,y,z,time,Bx,By,Bz) where, e.g., Bx is a component of a magnetic
field. I can read that file straight into ParaView with its text file
reader, but I find it more convenient to run the csv file through a python
script that makes a vtp file and I load that into ParaView. These files
tend to be big, and having a compressed binary vtp file means that ParaView
can read it very quickly (e.g. I parse csv file once with my script instead
of loading it into ParaView to parse each time I open it).

The examples in the documentation show how to use the vtk-numpy interface
to make a vector of points and dump them into a vtkPoints object. For
example,

d = np.genfromtxt(fname, ...)  # more arguments not shown for brevity

coord = algs.make_vector(d[x], d[y], d[z])
pts = vtk.vtkPoints()
pts.SetData(dsa.numpyTovtkDataArray(coord, Points))

That looks very nice and must be very efficient.

I don't see an obvious way to do the same thing with point or cell data.
So, for example, I have...

numPts = pts.GetNumberOfPoints()
bfield = vtk.vtkFloatArray()
bfield.SetNumberOfComponents(3)
bfield.SetNumberOfTuples(numPts)
bfield.SetName(BField)

for a in xrange(numPts):
   bfield.InsertTuple(a, [ d[Bx][a], d[By][a], d[Bz][a] ])

polyData.GetPointData().AddArray(bfield)  # polyData is a vtkPolyData object

That loop and explicitly decomposing the d array to get at the magnetic
field components looks old fashioned to me.

What would be the numpy way to make that work? Thanks! -- Adam

*--*

*Adam L. Lyon*
*Scientist; Associate Division Head for Systems for Scientific Applications*

Scientific Computing Division  Muon g-2 Experiment
Fermi National Accelerator Laboratory
630 840 5522 office
www.fnal.gov
l...@fnal.gov

Connect with us!
Newsletter http://www.fnal.gov/pub/today/  |  Facebook
https://www.facebook.com/Fermilab  |  Twitter
https://twitter.com/Fermilab
___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] Python view

[Adam Lyon]

Great! Glad this is useful! -- A

*--*

*Adam L. Lyon*
*Scientist; Associate Division Head for Systems for Scientific Applications*

Scientific Computing Division  Muon g-2 Experiment
Fermi National Accelerator Laboratory
630 840 5522 office
www.fnal.gov
l...@fnal.gov

Connect with us!
Newsletter http://www.fnal.gov/pub/today/  |  Facebook
https://www.facebook.com/Fermilab  |  Twitter
https://twitter.com/Fermilab

On Wed, Apr 15, 2015 at 8:54 AM, Cory Quammen cory.quam...@kitware.com
wrote:

  Thanks for the report, Adam. This is helpful. We'll look at getting it
 fixed.

  Cory

 On Tue, Apr 14, 2015 at 8:19 PM, Adam Lyon l...@fnal.gov wrote:

 Hi Cory - I tried your little script and got an interesting response...

   /Applications/paraview4.3.1.app/Contents/Python/matplotlib/__init__.pyc

 /Applications/paraview4.3.1.app/Contents/Python/matplotlib/backends/__init__.pyc
 Traceback (most recent call last):
   File string, line 7, in module
   File
 /Applications/paraview4.3.1.app/Contents/Python/matplotlib/backends/backend_agg.py,
 line 38, in module
 from _backend_agg import RendererAgg as _RendererAgg
 ImportError:
 dlopen(/Applications/paraview4.3.1.app/Contents/Python/matplotlib/backends/_backend_agg.so,
 2): Library not loaded:
 /Users/kitware/Dashboards/MyTests/NightlyMaster/ParaViewSuperbuild-Release-Python27/install/lib/libfreetype.6.dylib
   Referenced from:
 /Applications/paraview4.3.1.app/Contents/Python/matplotlib/backends/_backend_agg.so
   Reason: image not found

  These files exist,

 /Applications/paraview4.3.1.app/Contents/Python/matplotlib/backends/_backend_agg.so

 /Applications/paraview4.3.1.app/Contents/Python/matplotlib/backends/backend_agg.py

 /Applications/paraview4.3.1.app/Contents/Python/matplotlib/backends/backend_agg.pyc


  Interestingly, these files exist, but don't seem to be used...
  /Applications/paraview4.3.1.app/Contents/Libraries/libfreetype.6.dylib
 /Applications/paraview4.3.1.app/Contents/Libraries/libfreetype.dylib

  If I run pvpython I see the same errors.

  BUT --- If I do,
 export
 DYLD_FALLBACK_LIBRARY_PATH=/Applications/paraview4.3.1.app/Contents/Libraries/

  and then start Paraview from the command line,

  /Applications/paraview4.3.1.app/Contents/MacOS/paraview

  ... and load the state file and the bluntfin.vts file ... Now I can see
 the matplotlib plots!!

  So it looks to me like you aren't setting a dynamic library path
 correctly within Paraview's python.

  Hope this helps. Thanks for the simple thing to try.

  -- Adam


   *--*

  *Adam L. Lyon*
 *Scientist; Associate Division Head for Systems for Scientific
 Applications*

  Scientific Computing Division  Muon g-2 Experiment
 Fermi National Accelerator Laboratory
  630 840 5522 office
 www.fnal.gov
 l...@fnal.gov

  Connect with us!
 Newsletter http://www.fnal.gov/pub/today/  |  Facebook
 https://www.facebook.com/Fermilab  |  Twitter
 https://twitter.com/Fermilab

 On Tue, Apr 14, 2015 at 6:12 PM, Cory Quammen cory.quam...@kitware.com
 wrote:

  Hi Adam,

  I am running the exact same version of ParaView (my About box has the
 same contents as yours), so this is a little bit puzzling.

  Could you try two things:

  1). Run ParaView, create a Python View, then enter this script:

   import matplotlib

 print matplotlib.__file__


  import matplotlib.backends

 print matplotlib.backends.__file__


  import matplotlib.backends.backend_agg

 print matplotlib.backends.backend_agg.__file__


  Please report what the Output Messages window says.


  2). Open the contents of your ParaView Mac bundle (right-click, Show
 Package Contents), open up Contents - Python - matplotlib - backends.
 Please let me know if you see a backend_agg.py file in there.


  Thanks,

 Cory

 On Tue, Apr 14, 2015 at 4:12 PM, Adam Lyon l...@fnal.gov wrote:

 Hi Cory and Utkarsh - So I never see a plot - just a black window. The
 error message I sent earlier repeats every time I move my mouse over the
 python view window.  I'm using Paraview 4.3.1 downloaded from
 paraview.org. Paraview's about box is below.

  Do you have a simple matplotlib plot I can try? Thanks! -- Adam


  [image: Inline image 1]

   *--*

  *Adam L. Lyon*
 *Scientist; Associate Division Head for Systems for Scientific
 Applications*

  Scientific Computing Division  Muon g-2 Experiment
 Fermi National Accelerator Laboratory
  630 840 5522 office
 www.fnal.gov
 l...@fnal.gov

  Connect with us!
 Newsletter http://www.fnal.gov/pub/today/  |  Facebook
 https://www.facebook.com/Fermilab  |  Twitter
 https://twitter.com/Fermilab

 On Tue, Apr 14, 2015 at 2:06 PM, Cory Quammen cory.quam...@kitware.com
  wrote:

  Hi Adam,

  I am trying to reproduce this with ParaView 4.3.1 64-bit on a Mac
 with Yosemite 10.10.2, but haven't been able to. This is the latest Mac
 binary available for download on paraview.org. The matplotlib pot
 shows up as in the blog post. Is your ParaView binary from
 paraview.org?

  Thanks,
 Cory

 On Tue, Apr

Re: [Paraview] Python view

[Adam Lyon]

Hi Cory - I wanted to try this -- I loaded the state file and the data file
(thanks for the link). But when the python view tries to render, I get,

Error: Cannot import matplotlib.backends.backend_agg.FigureCanvasAgg

and nothing appears. I'm running Paraview 4.3.1 64-bit on my Mac with
Yosemite.

Is this a Mac problem? Thanks! -- Adam

*--*

*Adam L. Lyon*
*Scientist; Associate Division Head for Systems for Scientific Applications*

Scientific Computing Division  Muon g-2 Experiment
Fermi National Accelerator Laboratory
___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] Python view

[Adam Lyon]

Hi Cory - I tried your little script and got an interesting response...

/Applications/paraview4.3.1.app/Contents/Python/matplotlib/__init__.pyc
/Applications/paraview4.3.1.app/Contents/Python/matplotlib/backends/__init__.pyc
Traceback (most recent call last):
  File string, line 7, in module
  File
/Applications/paraview4.3.1.app/Contents/Python/matplotlib/backends/backend_agg.py,
line 38, in module
from _backend_agg import RendererAgg as _RendererAgg
ImportError:
dlopen(/Applications/paraview4.3.1.app/Contents/Python/matplotlib/backends/_backend_agg.so,
2): Library not loaded:
/Users/kitware/Dashboards/MyTests/NightlyMaster/ParaViewSuperbuild-Release-Python27/install/lib/libfreetype.6.dylib
  Referenced from:
/Applications/paraview4.3.1.app/Contents/Python/matplotlib/backends/_backend_agg.so
  Reason: image not found

These files exist,
/Applications/paraview4.3.1.app/Contents/Python/matplotlib/backends/_backend_agg.so
/Applications/paraview4.3.1.app/Contents/Python/matplotlib/backends/backend_agg.py
/Applications/paraview4.3.1.app/Contents/Python/matplotlib/backends/backend_agg.pyc


Interestingly, these files exist, but don't seem to be used...
/Applications/paraview4.3.1.app/Contents/Libraries/libfreetype.6.dylib
/Applications/paraview4.3.1.app/Contents/Libraries/libfreetype.dylib

If I run pvpython I see the same errors.

BUT --- If I do,
export
DYLD_FALLBACK_LIBRARY_PATH=/Applications/paraview4.3.1.app/Contents/Libraries/

and then start Paraview from the command line,

/Applications/paraview4.3.1.app/Contents/MacOS/paraview

... and load the state file and the bluntfin.vts file ... Now I can see the
matplotlib plots!!

So it looks to me like you aren't setting a dynamic library path correctly
within Paraview's python.

Hope this helps. Thanks for the simple thing to try.

-- Adam


*--*

*Adam L. Lyon*
*Scientist; Associate Division Head for Systems for Scientific Applications*

Scientific Computing Division  Muon g-2 Experiment
Fermi National Accelerator Laboratory
630 840 5522 office
www.fnal.gov
l...@fnal.gov

Connect with us!
Newsletter http://www.fnal.gov/pub/today/  |  Facebook
https://www.facebook.com/Fermilab  |  Twitter
https://twitter.com/Fermilab

On Tue, Apr 14, 2015 at 6:12 PM, Cory Quammen cory.quam...@kitware.com
wrote:

  Hi Adam,

  I am running the exact same version of ParaView (my About box has the
 same contents as yours), so this is a little bit puzzling.

  Could you try two things:

  1). Run ParaView, create a Python View, then enter this script:

  import matplotlib

 print matplotlib.__file__


  import matplotlib.backends

 print matplotlib.backends.__file__


  import matplotlib.backends.backend_agg

 print matplotlib.backends.backend_agg.__file__


  Please report what the Output Messages window says.


  2). Open the contents of your ParaView Mac bundle (right-click, Show
 Package Contents), open up Contents - Python - matplotlib - backends.
 Please let me know if you see a backend_agg.py file in there.


  Thanks,

 Cory

 On Tue, Apr 14, 2015 at 4:12 PM, Adam Lyon l...@fnal.gov wrote:

 Hi Cory and Utkarsh - So I never see a plot - just a black window. The
 error message I sent earlier repeats every time I move my mouse over the
 python view window.  I'm using Paraview 4.3.1 downloaded from
 paraview.org. Paraview's about box is below.

  Do you have a simple matplotlib plot I can try? Thanks! -- Adam


  [image: Inline image 1]

   *--*

  *Adam L. Lyon*
 *Scientist; Associate Division Head for Systems for Scientific
 Applications*

  Scientific Computing Division  Muon g-2 Experiment
 Fermi National Accelerator Laboratory
  630 840 5522 office
 www.fnal.gov
 l...@fnal.gov

  Connect with us!
 Newsletter http://www.fnal.gov/pub/today/  |  Facebook
 https://www.facebook.com/Fermilab  |  Twitter
 https://twitter.com/Fermilab

 On Tue, Apr 14, 2015 at 2:06 PM, Cory Quammen cory.quam...@kitware.com
 wrote:

  Hi Adam,

  I am trying to reproduce this with ParaView 4.3.1 64-bit on a Mac with
 Yosemite 10.10.2, but haven't been able to. This is the latest Mac binary
 available for download on paraview.org. The matplotlib pot shows up as
 in the blog post. Is your ParaView binary from paraview.org?

  Thanks,
 Cory

 On Tue, Apr 14, 2015 at 11:49 AM, Adam Lyon l...@fnal.gov wrote:

 Hi Cory - I wanted to try this -- I loaded the state file and the data
 file (thanks for the link). But when the python view tries to render, I
 get,

  Error: Cannot import matplotlib.backends.backend_agg.FigureCanvasAgg

  and nothing appears. I'm running Paraview 4.3.1 64-bit on my Mac with
 Yosemite.

  Is this a Mac problem? Thanks! -- Adam

*--*

  *Adam L. Lyon*
 *Scientist; Associate Division Head for Systems for Scientific
 Applications*

  Scientific Computing Division  Muon g-2 Experiment
 Fermi National Accelerator Laboratory




  --
 Cory Quammen
 RD Engineer
 Kitware, Inc.





  --
 Cory Quammen
 RD Engineer
 Kitware, Inc

Re: [Paraview] Python view

[Adam Lyon]

Hi Cory and Utkarsh - So I never see a plot - just a black window. The
error message I sent earlier repeats every time I move my mouse over the
python view window.  I'm using Paraview 4.3.1 downloaded from paraview.org.
Paraview's about box is below.

Do you have a simple matplotlib plot I can try? Thanks! -- Adam


[image: Inline image 1]

*--*

*Adam L. Lyon*
*Scientist; Associate Division Head for Systems for Scientific Applications*

Scientific Computing Division  Muon g-2 Experiment
Fermi National Accelerator Laboratory
630 840 5522 office
www.fnal.gov
l...@fnal.gov

Connect with us!
Newsletter http://www.fnal.gov/pub/today/  |  Facebook
https://www.facebook.com/Fermilab  |  Twitter
https://twitter.com/Fermilab

On Tue, Apr 14, 2015 at 2:06 PM, Cory Quammen cory.quam...@kitware.com
wrote:

  Hi Adam,

  I am trying to reproduce this with ParaView 4.3.1 64-bit on a Mac with
 Yosemite 10.10.2, but haven't been able to. This is the latest Mac binary
 available for download on paraview.org. The matplotlib pot shows up as in
 the blog post. Is your ParaView binary from paraview.org?

  Thanks,
 Cory

 On Tue, Apr 14, 2015 at 11:49 AM, Adam Lyon l...@fnal.gov wrote:

 Hi Cory - I wanted to try this -- I loaded the state file and the data
 file (thanks for the link). But when the python view tries to render, I
 get,

  Error: Cannot import matplotlib.backends.backend_agg.FigureCanvasAgg

  and nothing appears. I'm running Paraview 4.3.1 64-bit on my Mac with
 Yosemite.

  Is this a Mac problem? Thanks! -- Adam

*--*

  *Adam L. Lyon*
 *Scientist; Associate Division Head for Systems for Scientific
 Applications*

  Scientific Computing Division  Muon g-2 Experiment
 Fermi National Accelerator Laboratory




  --
 Cory Quammen
 RD Engineer
 Kitware, Inc.

___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

Re: [Paraview] Using VTK Filters with Programmable Filter

[Adam Lyon]

Hi Utkarsh - Do you all update PDF from time to time or is it the same as
when it was first released? If you do update it, is there a way to find
that out (aside from downloading it again every so often). Thanks! -- Adam

*--*

*Adam L. Lyon*
*Scientist; Associate Division Head for Systems for Scientific Applications*

Scientific Computing Division  Muon g-2 Experiment
Fermi National Accelerator Laboratory
630 840 5522 office
www.fnal.gov
l...@fnal.gov

Connect with us!
Newsletter http://www.fnal.gov/pub/today/  |  Facebook
https://www.facebook.com/Fermilab  |  Twitter
https://twitter.com/Fermilab

On Wed, Apr 8, 2015 at 10:49 AM, Utkarsh Ayachit 
utkarsh.ayac...@kitware.com wrote:

 Livia,

 With VTK 6, there's no need create a shallow copy of the input.

 BTW, the ParaView Guide (http://www.paraview.org/paraview-guide/) is
 indeed the latest irrespective of the page count :).

 Utkarsh

 On Tue, Apr 7, 2015 at 3:47 AM,  livia.barazze...@istb.unibe.ch wrote:
  Hi,
 
  I have a question about the use of vtk filter. At page 91 of the paraview
  manual included in the binaries download,  it is suggested to make a
 copy of
  the input (
 
  input_copy = inputs[0].NewInstance()
 
  input_copy.UnRegister(None)
 
  input_copy.ShallowCopy(inputs[0].VTKObject) ) , but the reference is to
 the
  previous  version of VTK. Does this still hold for VTK 6?
 
  In the paraview guide available for download  under “documentation”, this
  issue is not mentioned (but the guide is also shorter). I have been using
  the filter without making copy of the input and I haven’t the impression
 of
  memory leaks in my code
 
  Livia
 
 
 
 
 
  Livia Barazzetti
  Ph.D. Student - Medical Image Analysis
  Institute for Surgical Technology and Biomechanics
  University of Bern
  Stauffacherstrasse 78
  CH-3014 Bern
  Tel +41 31 631 59 48
  http://www.istb.unibe.ch
 
 
 
 
  ___
  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
 
  Search the list archives at: http://markmail.org/search/?q=ParaView
 
  Follow this link to subscribe/unsubscribe:
  http://public.kitware.com/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

 Search the list archives at: http://markmail.org/search/?q=ParaView

 Follow this link to subscribe/unsubscribe:
 http://public.kitware.com/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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview

[Paraview] Trying example in Paraview manual section 13.2.2 - can't get it to work

[Adam Lyon]

Hi, I'm trying to write a Python Programmable Source that can read files
based on a time stamp (e.g. pick the file using the VCR buttons in
Paraview). I see a nice example in the new Paraview manual (PDF) in section
13.2.2 - CSV file series, but I can't get that example to work. The
UPDATE_TIME_STEP is always a value like 0.1, 0.2, 0.3, up to 1.
It's never from the set of times specified by the RequestInformation
script.   I'm using Paraview v4.3.1 64-bit Mac Yosemite. Here's what I
did...

I have a Programmable Source as the only item in my pipeline. The output
dataset type is vtkTable. The Script is,

# -- Script --
import numpy as np

def GetUpdateTimestep(algorithm):
executive = algorithm.GetExecutive()
outInfo = executive.GetOutputInformation(0)
print outInfo.Get(executive.TIME_STEPS())
return outInfo.Get(executive.UPDATE_TIME_STEP()) if
outInfo.Has(executive.UPDATE_TIME_STEP()) else None

req_time = GetUpdateTimestep(self)
a = np.array([req_time] )

output.RowData.append(a, Adam)
#---

And the RequestInformation script is (taken verbatim from the example in
the manual)...

# -- RequestInformation --
def setOutputTimesteps(algorithm , timesteps):
helper routine to set timestep information
executive = algorithm.GetExecutive()
outInfo = executive.GetOutputInformation(0)
outInfo.Remove(executive.TIME_STEPS())

for timestep in timesteps:
outInfo.Append(executive.TIME_STEPS(), timestep)

outInfo.Remove(executive.TIME_RANGE())
outInfo.Append(executive.TIME_RANGE(), timesteps[0])
outInfo.Append(executive.TIME_RANGE(), timesteps[-1])

setOutputTimesteps(self, (1.0, 2.0, 20.0, 30.0))


So as you can see, I'm just copying the value of UPDATE_TIME_STEP into the
output table, which I can look at in the spreadsheet view. When I hit the
VCR buttons, the values I get are 0.11, 0.22, ... -- not the
values that I had set in TIME_STEPS.

Note that in the top script I have a line,
print outInfo.Get(executive.TIME_STEPS())
which prints out the right thing ... (1.0, 2.0, 20.0, 30.0)
I can print out TIME_RANGE and that's correct too (1.0, 30.0)

So I think everything is set correctly, but for some reason Paraview is
ignoring the settings. Do I need to call something to tell Paraview to
notice my changing of TIME_STEPS/TIME_RANGE?

Thanks in advance for any help!  -- Adam
___
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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview