Re: [Paraview] Still Render in PV5.2.0 takes longer time than in PV4.4.0

[Ken Martin]

For the first render of points your numbers seem reasonable. For subsequent
renders you will find different tradeoffs on the old backend. Display Lists
are typically slower for a first render but faster on subsequent renders.
With them turned off the first render is fast but subsequent renders are
not any faster. Subsequent renders with OpenGL2 should be fairly fast.

On Tue, Jan 3, 2017 at 8:13 PM, 张驭洲  wrote:

>
>
> Thank you all!
>
> I'm using Kitware's binaries and 4.4 is with OpenGL 1 and 5.2 is with
> OpenGL 2. Now that this option has no impact on OpenGL2 backend, is there
> any other option (besides those mentioned in the User's Guide) that can
> improve the performance of PV 5.2? In my case, by turning off the display
> list, the overall performance of PV 4.4 is similar to that of PV 5.2.
>
> -Zhang
>
> -原始邮件-
> *发件人:* "Ken Martin" 
> *发送时间:* 2017年1月3日 星期二
> *收件人:* "Utkarsh Ayachit" 
> *抄送:* "David E DeMarle" , "张驭洲" <
> yzhzh...@ipe.ac.cn>, "paraview@paraview.org" 
> *主题:* Re: [Paraview] Still Render in PV5.2.0 takes longer time than in
> PV4.4.0
>
> For the new OpenGL2 backend setting ImmediateModeRendering or
> UseDisplayLists or something similar has no impact. Those concepts are part
> of the legacy OpenGL API. So you should see no difference in timings with
> them turned on or off with the new OpenGL backend.
>
> On Tue, Jan 3, 2017 at 9:42 AM, Utkarsh Ayachit <
> utkarsh.ayac...@kitware.com> wrote:
>
>> On Tue, Jan 3, 2017 at 9:10 AM, David E DeMarle
>>  wrote:
>> > Is this with OpenGL1 or 2 back end? If you are using Kitware's binaries
>> 4.4
>> > will be OpenGL1 and 5.2 will be OpenGL2. If you built from source or
>> got it
>> > from a distro then it might be otherwise.
>>
>> A way to tell which type of build you're using is to loo at the title
>> bar. For OpenGL1, the title bar says "Legacy Rendering Backend". Such
>> a suffix is missing for OpenGL2 build.
>>
>> 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
>>
>
>
>
> --
> Ken Martin PhD
> Chairman & CFO
> Kitware Inc.
> 28 Corporate Drive
> Clifton Park NY 12065
> 518 371 3971 <(518)%20371-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.
>
>
>
>
>
>


-- 
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] Still Render in PV5.2.0 takes longer time than in PV4.4.0

[张驭洲]

Thank you all!

I'm using Kitware's binaries and 4.4 is with OpenGL 1 and 5.2 is with OpenGL 2. 
Now that this option has no impact on OpenGL2 backend, is there any other 
option (besides those mentioned in the User's Guide) that can improve the 
performance of PV 5.2? In my case, by turning off the display list, the overall 
performance of PV 4.4 is similar to that of PV 5.2.

-Zhang
-原始邮件-
发件人: "Ken Martin" 
发送时间: 2017年1月3日 星期二
收件人: "Utkarsh Ayachit" 
抄送: "David E DeMarle" , "张驭洲" , 
"paraview@paraview.org" 
主题: Re: [Paraview] Still Render in PV5.2.0 takes longer time than in PV4.4.0


For the new OpenGL2 backend setting ImmediateModeRendering or UseDisplayLists 
or something similar has no impact. Those concepts are part of the legacy 
OpenGL API. So you should see no difference in timings with them turned on or 
off with the new OpenGL backend.


On Tue, Jan 3, 2017 at 9:42 AM, Utkarsh Ayachit  
wrote:
On Tue, Jan 3, 2017 at 9:10 AM, David E DeMarle
 wrote:
> Is this with OpenGL1 or 2 back end? If you are using Kitware's binaries 4.4
> will be OpenGL1 and 5.2 will be OpenGL2. If you built from source or got it
> from a distro then it might be otherwise.

A way to tell which type of build you're using is to loo at the title
bar. For OpenGL1, the title bar says "Legacy Rendering Backend". Such
a suffix is missing for OpenGL2 build.

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






--

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] plugins with 5.2

[Burlen Loring]

sure, although I hope this isn't asking too much, as the build has a few 
dependencies, I think for this only NetCDF is needed.


here is the repo
https://github.com/LBL-EESA/TECA
plugin is in the ParaView dir.

On 01/03/2017 01:35 PM, Utkarsh Ayachit wrote:

Burlen,

Happy new year to you too!

Hmm, that's odd. Can you share the plugin code with me? Let's see if I
can reproduce the issue.

Utkarsh

On Tue, Jan 3, 2017 at 2:13 PM, Burlen Loring  wrote:

Hi Utkarsh, Happy new year!

I have a couple of questions about the new way.

Shouldn't this be automatically added by ADD_PARAVIEW_PLUGIN macro like the
rest of the PV related link dependencies?
Should you really need to link Qt to all plugins?

My plugin is a number of simple server side only classes, for ex a reader.
It has no need of Qt. I'd rather not have Qt as a dependency of my project.

Burlen


On 12/22/2016 12:17 PM, Utkarsh Ayachit wrote:

Burlen,

See Qt dependencies changes documented here:
http://www.paraview.org/ParaView3/Doc/Nightly/www/cxx-doc/MajorAPIChanges.html

include(ParaViewQt) # generally not needed, since auto-included
pv_find_package_qt(qt_targets
   QT4_COMPONENTS QtGui
   QT5_COMPONENTS Widgets)

pv_qt_wrap_cpp(moc_files ${headers})
pv_qt_wrap_ui(ui_files ${uis})

...
target_link_libraries(${target} LINK_PRIVATE ${qt_targets})


Utkarsh

On Wed, Dec 21, 2016 at 1:25 PM, Burlen Loring 
wrote:

After upgrading to 5.2 my plugin is not compiling. When I configure the
plugin I see a few pages of the following:

CMake Warning (dev) at io/CMakeLists.txt:54 (add_library):
   Policy CMP0028 is not set: Double colon in target name means ALIAS or
   IMPORTED target.  Run "cmake --help-policy CMP0028" for policy details.
   Use the cmake_policy command to set the policy and suppress this
warning.

   Target "teca_io" links to target "Qt4::QtCore" but the target was not
   found.  Perhaps a find_package() call is missing for an IMPORTED target,
or
   an ALIAS target is missing?
This warning is for project developers.  Use -Wno-dev to suppress it.

then linker errors

[ 32%] Linking CXX shared library ../lib/libteca_io.so
/bin/ld: cannot find -lQt4::QtCore
/bin/ld: cannot find -lQt4::QtGui
collect2: error: ld returned 1 exit status
io/CMakeFiles/teca_io.dir/build.make:402: recipe for target
'lib/libteca_io.so' failed
make[2]: *** [lib/libteca_io.so] Error 1
CMakeFiles/Makefile2:196: recipe for target
'io/CMakeFiles/teca_io.dir/all' failed
make[1]: *** [io/CMakeFiles/teca_io.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2

It's not a library so I set  the policy to new,  and the cmake configure
errors out. Any idea what's missing?


___
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

Re: [Paraview] slicing a large VTK_POLYHEDRON

[Pierre Van Hauwaert]

Hi Mathieu and Thomas,

Thank you for the suggestions.

1) I tried the tetrahedralize filter on my data but I did not get the 
results I was expecting. I have a polyhedron which is not convex 
(https://postimg.org/image/9s3egl8rz/) and the filter fill the gap as 
you can see here (https://postimg.org/image/5u1nt6d2h/) and it is not 
what I was expecting. Indeed, the initial purpose of the slice was to 
visualize the hole.


2) I tried this fix: 
https://gitlab.kitware.com/vtk/vtk/merge_requests/2088 

only modifying the 2 files (*Common/DataModel/vtkPolyhedron.cxx* 
 
*Common/Core/vtkSetGet.h) * 

And compile VTK alone. I used a python script (activating the python VTK 
wrapping) to do the test with the vtkCutter function but I ended having 
the same exact issue (segfault, no error message) with only the 
polyhedron that have more than 1024 faces. I am not sure I should get 
the same results if I manage to compile paraview. When I will manage I 
will get back to you.


Thanks,

Pierre


On 03-01-17 16:51, Mathieu Westphal wrote:

Hi

Indeed, incorrect copy paste. thanks for pointing it out.

Mathieu Westphal

On Tue, Jan 3, 2017 at 4:46 PM, T.J. Corona > wrote:


Hi Mathieu and Pierre,

Perhaps you meant to point to this “work in progress” branch?

https://gitlab.kitware.com/vtk/vtk/merge_requests/2088


Sincerely,
T.J.

Thomas J. Corona, Ph.D.
Kitware, Inc.
R Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4443 


On Jan 3, 2017, at 10:18 AM, Mathieu Westphal
> wrote:

Hello

for your information there is a bug in the slicing of
vtkPolyHedron that can cause a segfault.
It looks very much like your error. It has yet to be corrected.
https://gitlab.kitware.com/vtk/vtk/issues/16877


You can already test this "work in progress" branch to see if
this fixes your issue  :
https://gitlab.kitware.com/vtk/vtk/merge_requests/2304


You could of course modify your data to tetrahedron with
tetrahedralize filter.

Regards,

Mathieu Westphal

On Tue, Jan 3, 2017 at 4:10 PM, Pierre Van Hauwaert
> wrote:

Hi,

I am using paraview to visualise my data. I generate my data
using a combination of the 2 following types
(http://www.vtk.org/doc/nightly/html/vtkCellType_8h_source.html
)
VTK_VOXEL

=
11
VTK_POLYHEDRON = 42 I can visualize that data with parview
without a problem. But, because I ended up having a segfault
without any error message when slicing (Z=0) the data. I
decomposed my data in separate files for each VTK_POLYHEDRON
in order to investigate the problem.

I found out that only the polyhedrons with the largest size
were having the problem. The limit is somewhere between the 2
files:
- poly-F1000-2395.vtu : working: 466 points, 928 faces
- poly-F1000-2987.vtu : segfault when slicing: 546 points,
1088 faces

So my guess is that there is a limit for the number of points
or the number of faces that can have the polyhedron (1024 ?)
if I want to be able to use the slice function.

My questions are :
1) Is there actually a limitation in Paraview (VTK?)
regarding the number of faces or the number of the point that
the slice function can handle for a polyhedron ?
2) If there is this limitation, is there an option to remove
it in Paraview ? (specific version, compilation option, etc)
3) If there is this limitation, is there any work around that
exist so I am able to slice my data ? For example a different
format ?


I attached the data to be able to back up my statement:

poly-F1000-*.vtu : files describing a polyhedron each:
poly-F1000.pvd : load all those files

Biggest file for which the slicing works (size, name):
34K poly-F1000-2395.vtu

The 8 biggest files triggering the crash when doing a slice:
(size, name)
38K poly-F1000-2987.vtu
39K 

Re: [Paraview] plugins with 5.2

[Utkarsh Ayachit]

Burlen,

Happy new year to you too!

Hmm, that's odd. Can you share the plugin code with me? Let's see if I
can reproduce the issue.

Utkarsh

On Tue, Jan 3, 2017 at 2:13 PM, Burlen Loring  wrote:
> Hi Utkarsh, Happy new year!
>
> I have a couple of questions about the new way.
>
> Shouldn't this be automatically added by ADD_PARAVIEW_PLUGIN macro like the
> rest of the PV related link dependencies?
> Should you really need to link Qt to all plugins?
>
> My plugin is a number of simple server side only classes, for ex a reader.
> It has no need of Qt. I'd rather not have Qt as a dependency of my project.
>
> Burlen
>
>
> On 12/22/2016 12:17 PM, Utkarsh Ayachit wrote:
>
> Burlen,
>
> See Qt dependencies changes documented here:
> http://www.paraview.org/ParaView3/Doc/Nightly/www/cxx-doc/MajorAPIChanges.html
>
> include(ParaViewQt) # generally not needed, since auto-included
> pv_find_package_qt(qt_targets
>   QT4_COMPONENTS QtGui
>   QT5_COMPONENTS Widgets)
>
> pv_qt_wrap_cpp(moc_files ${headers})
> pv_qt_wrap_ui(ui_files ${uis})
>
> ...
> target_link_libraries(${target} LINK_PRIVATE ${qt_targets})
>
>
> Utkarsh
>
> On Wed, Dec 21, 2016 at 1:25 PM, Burlen Loring 
> wrote:
>>
>> After upgrading to 5.2 my plugin is not compiling. When I configure the
>> plugin I see a few pages of the following:
>>
>> CMake Warning (dev) at io/CMakeLists.txt:54 (add_library):
>>   Policy CMP0028 is not set: Double colon in target name means ALIAS or
>>   IMPORTED target.  Run "cmake --help-policy CMP0028" for policy details.
>>   Use the cmake_policy command to set the policy and suppress this
>> warning.
>>
>>   Target "teca_io" links to target "Qt4::QtCore" but the target was not
>>   found.  Perhaps a find_package() call is missing for an IMPORTED target,
>> or
>>   an ALIAS target is missing?
>> This warning is for project developers.  Use -Wno-dev to suppress it.
>>
>> then linker errors
>>
>> [ 32%] Linking CXX shared library ../lib/libteca_io.so
>> /bin/ld: cannot find -lQt4::QtCore
>> /bin/ld: cannot find -lQt4::QtGui
>> collect2: error: ld returned 1 exit status
>> io/CMakeFiles/teca_io.dir/build.make:402: recipe for target
>> 'lib/libteca_io.so' failed
>> make[2]: *** [lib/libteca_io.so] Error 1
>> CMakeFiles/Makefile2:196: recipe for target
>> 'io/CMakeFiles/teca_io.dir/all' failed
>> make[1]: *** [io/CMakeFiles/teca_io.dir/all] Error 2
>> Makefile:127: recipe for target 'all' failed
>> make: *** [all] Error 2
>>
>> It's not a library so I set  the policy to new,  and the cmake configure
>> errors out. Any idea what's missing?
>>
>>
>> ___
>> 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

Re: [Paraview] Animating a function of a field

[Samuel Key]

Aleksejs,

Using brute strength and awkwardness, three conditions are needed:

(1) if your datum set is defined as f(x,y,z,t) & g(x,y,z,t),

(2) if both f(.) and g(.) are either cell values or point values, and

(3) if the variable 'time(.)' has been explicitly added as a datum set 
item (a name and a value),


then add PV's Calculator Filter to the pipeline where 'results' is 
replaced by 'h' and the equation is set as f*sin(time)+g*cos(time).


After selecting the 'APPLY' button, 'h(.) will be added to your datum-set.

(To the best my knowledge, 'time' is not available in the PV Calculator 
filter.)


Sam Key

On 1/3/2017 8:13 AM, Aleksejs Fomins wrote:

Dear Paraview,

I have a 3d unstructured mesh with two fields defined over it - f(x,y,z) and 
g(x,y,z)
I want to create a movie of a following function

h(t) = f * sin(t) + g * cos(t)

where t is time. How would you do it?

Best regards,
Aleksejs Fomins

PhD Student in Nanophotonics, EPF Lausanne, Switzerland
___
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

Re: [Paraview] slicing a large VTK_POLYHEDRON

[T.J. Corona]

Hi Mathieu and Pierre,

Perhaps you meant to point to this “work in progress” branch?

https://gitlab.kitware.com/vtk/vtk/merge_requests/2088

Sincerely,
T.J.

Thomas J. Corona, Ph.D.
Kitware, Inc.
R Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4443

> On Jan 3, 2017, at 10:18 AM, Mathieu Westphal  
> wrote:
> 
> Hello
> 
> for your information there is a bug in the slicing of vtkPolyHedron that can 
> cause a segfault.
> It looks very much like your error. It has yet to be corrected.
> https://gitlab.kitware.com/vtk/vtk/issues/16877 
> 
> 
> You can already test this "work in progress" branch to see if this fixes your 
> issue  :
> https://gitlab.kitware.com/vtk/vtk/merge_requests/2304 
> 
> 
> You could of course modify your data to tetrahedron with tetrahedralize 
> filter.
> 
> Regards,
> 
> Mathieu Westphal
> 
> On Tue, Jan 3, 2017 at 4:10 PM, Pierre Van Hauwaert 
> > wrote:
> Hi,
> 
> I am using paraview to visualise my data. I generate my data using a 
> combination of the 2 following types ( 
> http://www.vtk.org/doc/nightly/html/vtkCellType_8h_source.html
>  )
> VTK_VOXEL 
> 
>   = 11
> VTK_POLYHEDRON = 42
> I can visualize that data with parview without a problem. But, because I 
> ended up having a segfault without any error message when slicing (Z=0) the 
> data. I decomposed my data in separate files for each VTK_POLYHEDRON in order 
> to investigate the problem.
> 
> I found out that only the polyhedrons with the largest size were having the 
> problem. The limit is somewhere between the 2 files:
> - poly-F1000-2395.vtu : working: 466 points, 928 faces 
> - poly-F1000-2987.vtu : segfault when slicing: 546 points, 1088 faces 
> 
> So my guess is that there is a limit for the number of points or the number 
> of faces that can have the polyhedron (1024 ?) if I want to be able to use 
> the slice function.
> 
> My questions are : 
> 1) Is there actually a limitation in Paraview (VTK?) regarding the number of 
> faces or the number of the point that the slice function can handle for a 
> polyhedron ?
> 2) If there is this limitation, is there an option to remove it in Paraview ? 
> (specific version, compilation option, etc)   
> 3) If there is this limitation, is there any work around that exist so I am 
> able to slice my data ? For example a different format ?
> 
> 
> I attached the data to be able to back up my statement:
> 
> poly-F1000-*.vtu : files describing a polyhedron each:  
> poly-F1000.pvd : load all those files
> 
> Biggest file for which the slicing works (size, name):
> 34K poly-F1000-2395.vtu
> 
> The 8 biggest files triggering the crash when doing a slice: (size, name)
> 38K poly-F1000-2987.vtu
> 39K poly-F1000-2983.vtu
> 39K poly-F1000-2935.vtu
> 39K poly-F1000-2988.vtu
> 39K poly-F1000-2931.vtu
> 40K poly-F1000-2937.vtu
> 40K poly-F1000-2981.vtu
> 40K poly-F1000-2930.vtu
> fail.pvd: load those 8 files
> 
> the other files can be sliced without any issues
> 
> 
> Thanks,  
> 
> Pierre 
> 
> -- 
> R.Tech Engineering B.V. 
> Eekholt 42 - 1112 XH Diemen - the Netherlands 
> Tel: +31 (0) 2 04 95 02 22 
> 
> ___
> 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 

Re: [Paraview] difference in the output of co-processing

[Andy Bauer]

Hi Ufuk,

Thanks for checking this out. Did you try out saving the trace as a pvsm
file? Did you get the correct result when loading the pvsm file back or not?

Can you share the data set and the generated pvsm file and the Python state
file?

Thanks,
Andy



On Tue, Jan 3, 2017 at 3:50 AM, Ufuk Utku Turuncoglu (BE) <
u.utku.turunco...@be.itu.edu.tr> wrote:

> Hi Andy,
>
> No, i am using same PV installation in both case under same server.
>
> As you suggested, i saved the state in Python format and run under GUI
> (Tools > Python Shell > Run Script). It basically opens a new RenderView
> and places the color bars like in co-processing output (misplaced, thinner
> and smaller) and does not show anything about the rest of the
> visualization. It just have color bars but i could see the correct pipeline
> in the pipeline browser. It is little bit weird. If i am doing something
> wrong, please let me know.
>
> Also, i did not modify the default config settings of the GUI and if you
> want me to check any specific option, please let me know.
>
> Thank for your help,
> Regards,
>
> --ufuk
>
> On 02/01/2017 18:50, Andy Bauer wrote:
>
> Hi Ufuk,
>
> I'm not sure what is causing the difference. I'm guessing not all of the
> information for the view is saved in the state. Any chance that you're
> using different versions of ParaView for the GUI and Catalyst generated
> images? I see that the Python script is specifying that it was generated in
> a PV 5.2 release candidate.
>
> If it's the same version of PV then you can test the state mechanism in PV
> by saving the state as both a Python script as well as a pvsm file. After
> that, try generating the image by loading the pvsm state file and running
> the Python state file in the GUI.
>
> Another possibility is that there are some config settings in the GUI that
> aren't used in Catalyst. If you don't mind helping narrow down the cause of
> the issue we can put in a bug report for this.
>
> Thanks,
> Andy
>
>
> On Mon, Jan 2, 2017 at 5:27 AM, Ufuk Utku Turuncoglu (BE) <
> u.utku.turunco...@be.itu.edu.tr> wrote:
>
>> Hi,
>>
>> I am trying to use Paraview co-processing component to create
>> visualization from custom model. The problem is that the color bars are
>> misplaced and also smaller and thinner in the co-processing output (saved
>> png file) if i compare it with direct visualization from Paraview. I am
>> attaching sample png files for both case and also Python file that is used
>> for the co-processing. I just wonder that is it possible to fix it easily?
>> It might be a bug but i am not sure.
>>
>> Thanks,
>> Regards,
>>
>> --ufuk
>>
>>
>> ___
>> 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

Re: [Paraview] some more questions about Catalyst

[Andy Bauer]

Hi,

There have been a lot of rendering improvements between 4.4 and 5.2 so
you'll definitely want to use 5.2 for the best performance. Also, 5.2 has a
lot of Catalyst and Live improvements. You shouldn't need to output images
or Cinema data bases in order to get the Live functionality.

Andy

On Tue, Jan 3, 2017 at 3:38 AM, 张驭洲  wrote:

>
> Hi Andy,
>
> Thanks for your reply! Now I can run the CxxFullExample, but I've
> encountered some more problems about it.
>
> 1.The CxxFullExample has a 70x60x44 unstructured grid, and it runs
> relatively quickly. A truncated sample output of Timer Log is as follows:
>
> RenderView::Update,  0.161069 seconds
> PVTrivialProducer::GatherInformation,  0.051133 seconds
> vtkSMDataDeliveryManager: Deliver Geome,  0.336371 seconds
> FullRes Data Migration,  0.336246 seconds
> Still Render,  0.034509 seconds
> RenderView::Update,  0.149692 seconds
> PVTrivialProducer::GatherInformation,  0.051577 seconds
> vtkSMDataDeliveryManager: Deliver Geome,  0.322268 seconds
> FullRes Data Migration,  0.322144 seconds
> Still Render,  0.033618 seconds
> RenderView::Update,  0.156578 seconds
> PVTrivialProducer::GatherInformation,  0.051578 seconds
> vtkSMDataDeliveryManager: Deliver Geome,  0.342933 seconds
> FullRes Data Migration,  0.342809 seconds
> Still Render,  0.033976 seconds
>
> However, after I modified the grid to a 700x60x44 one and nothing else
> were modified, it became fairly slow when running. Also, a truncated sample
> output of Timer Log:
>
> RenderView::Update,  1.48987 seconds
> PVTrivialProducer::GatherInformation,  0.493497 seconds
> vtkSMRepresentationProxy::GetRepresente,  2.44198 seconds
> vtkSMDataDeliveryManager: Deliver Geome,  0.480933 seconds
> FullRes Data Migration,  0.480786 seconds
> Still Render,  0.116726 seconds
> OpenGL Dev Render,  0.020361 seconds
> RenderView::Update,  1.51507 seconds
> PVTrivialProducer::GatherInformation,  0.493821 seconds
> vtkSMRepresentationProxy::GetRepresente,  2.47383 seconds
> vtkSMDataDeliveryManager: Deliver Geome,  0.481844 seconds
> FullRes Data Migration,  0.481686 seconds
> Still Render,  0.116896 seconds
> OpenGL Dev Render,  0.020697 seconds
> RenderView::Update,  1.50415 seconds
> PVTrivialProducer::GatherInformation,  0.491896 seconds
> vtkSMRepresentationProxy::GetRepresente,  2.44277 seconds
> vtkSMDataDeliveryManager: Deliver Geome,  0.474105 seconds
> FullRes Data Migration,  0.473959 seconds
> Still Render,  0.114223 seconds
> OpenGL Dev Render,  0.020254 seconds
>
> Comparing the two outputs, I find that the time spent in some processes
> became about 10  times longer, as the dataset became 10 times larger, but
> some other processes didn't  take 10 times longer time. The biggest
> difference is  vtkSMRepresentationProxy::GetRepresente, which takes more
> than 2.4s per frame in the bigger dataset example while in the smaller
> dataset example it takes less than 0.01s per frame. I don't know what the
> program does in the vtkSMRepresentationProxy::GetRepresente method.
> Actually I only know about Still Render. Could you please give me a brief
> introduction to these items? And, as Catalyst is designed for in situ
> visualization of very large dataset, is there any method to make the
> example run faster?
>
> 2.When I create Catelyst Python scripts in the ParaView GUI, I have to
> enable all of the *Live Visualization, Output to Cinema *and *Output
> rendering components i.e. views *options to get live visualization of the
> simulation in the PV GUI, but under this setting, it generates lots of
> pictures, which I don't need. If I don't enable either of *Output to
> Cinema *or *Output rendering components i.e. views, *I could not get the
> live visualization, and of course no picture is generated. But what's the
> function of the *Live Visualization *option?
>
> All of the above are situations in the PV 4.4.0 in the client-server mode.
> As for PV 5.2, I have some problems in using it in the client-server mode.
> Hope you can help me. Thank you again!
>
> -Zhang
>
> -原始邮件-
> *发件人:* "Andy Bauer" 
> *发送时间:* 2017年1月2日 星期一
> *收件人:* "张驭洲" 
> *抄送:* "paraview@paraview.org" 
> *主题:* Re: [Paraview] How to start the Catalyst example: CxxFullExample
>
> Hi,
>
> The Catalyst examples have been moved to the ParaView source repo. I'd
> recommend using the newest version of ParaView as well as Catalyst since
> there have been a lot of improvements since PV 4.4.
>
> For the  CxxFullExample, if you've built it with Catalyst enabled you can
> run it as you've done as well as pass in Catalyst Python scripts to use
> through command line arguments.
>
> Andy
>
> On Fri, Dec 30, 2016 at 10:08 PM, 张驭洲  wrote:
>
>>
>>
>> Hello everyone,
>>
>> I'm learning the ParaView Catalyst by starting at the CxxFullExample,
>> which is one of the Catalyst examples from 

Re: [Paraview] Error while launching Paraview (and Paraview Web) in Window 10

[Sebastien Jourdain]

Ok that mean there is still a path issue when loading a file within
ParaViewWeb on Windows.

Did you look at the log of that given session to see if any error is
printed?

You can try to edit the file [lib/site-packages]/paraview/web/protocols.py
within the ParaView application (The [...] part is for the path section
that I'm not sure of).

In the function

@exportRpc("pv.proxy.manager.create.reader")
def open(self, relativePath):
"""
Open relative file paths, attempting to use the file extension to
select
from the configured readers.
"""
fileToLoad = []
if type(relativePath) == list:
for file in relativePath:
validPath = self.getAbsolutePath(file)
if validPath:
fileToLoad.append(validPath)
else:
validPath = self.getAbsolutePath(relativePath)
if validPath:
fileToLoad.append(validPath)

if len(fileToLoad) == 0:
return { 'success': False, 'reason': 'No valid path name' }

print "=" * 80# <-- ADD THAT LINE TO SEE THE PATH YOU
TRY TO LOAD
print fileToLoad   # <-- ADD THAT LINE TO SEE THE PATH YOU TRY
TO LOAD
print "=" * 80   # <-- ADD THAT LINE TO SEE THE PATH YOU
TRY TO LOAD

[...]

Then look at the log to see which path is used to load that file.

Seb

On Tue, Jan 3, 2017 at 6:36 AM, Debopam Ghoshal  wrote:

> Hi Seb,
>
> 1. We are able to see the orientation axis and also able to rotate them.
> For example, when we click on can.ex2, we see a blank black screen. Then
> after we hide the left panel, we are able to see the orientation axis and
> also rotate them.
>
> 2. When we select the Wavelet we were able to view it properly, and was
> also able to rotate the scene.
>
> 3. We tried with both / and \\ but there is no change. The command we are
> using to launch paraview is as below:
>
> a: .\bin\pvpython.exe "C:\\ParaView-5.2.0-Qt4-OpenGL2-MPI-Windows-64bit\\
> share\\paraview-5.2\\web\\visualizer\\server\\pvw-visualizer.py"
> --content "C:\\ParaView-5.2.0-Qt4-OpenGL2-MPI-Windows-64bit\\
> share\\paraview-5.2\\web\\visualizer\\www" --data "C:\\ParaView-5.2.0-Qt4-
> OpenGL2-MPI-Windows-64bit\\data" --port 8080
>
> b: .\bin\pvpython.exe "C:/ParaView-5.2.0-Qt4-OpenGL2-MPI-Windows-64bit/
> share/paraview-5.2/web/visualizer/server/pvw-visualizer.py" --content
> "C:/ParaView-5.2.0-Qt4-OpenGL2-MPI-Windows-64bit/share/paraview-5.2/web/visualizer/www"
> --data "C:/ParaView-5.2.0-Qt4-OpenGL2-MPI-Windows-64bit/data" --port 8080
>
>
> Cheers & Best Wishes,
> Debopam
> ---
> Cell: +91 98304 10041 <+91%2098304%2010041>
>
> On Mon, Jan 2, 2017 at 9:36 PM, Sebastien Jourdain <
> sebastien.jourd...@kitware.com> wrote:
>
>> Hi Debopam,
>>
>> Do you see the orientation axis? Does it move when you rotate the scene?
>> What happen when you click on "+" and choose the Wavelet? Do you see
>> something?
>>
>> I'm wondering if you still run into an invalid path issue due to / or \.
>>
>> Seb
>>
>> On Mon, Jan 2, 2017 at 6:38 AM, Debopam Ghoshal 
>> wrote:
>>
>>> Hi Seb,
>>>
>>> 1. "C:/ParaView-5.2.0-Qt4-OpenGL2-MPI-Windows-64bit/data" works fine.
>>> Now we can see the list of files in the data folder.
>>>
>>> However, there seems to be some problem with the ParaviewWeb Application
>>> (or may be with the graphics driver?). Because we cannot render the sample
>>> mesh files (eg: can.ex2) in the visualizer. When we tried to view the files
>>> in the desktop application they are displayed without any problems. A
>>> screenshot of the graphics driver is attached for your reference.
>>>
>>> 2. Ok.
>>>
>>>
>>> Cheers & Best Wishes,
>>> Debopam
>>> ---
>>>
>>> On Fri, Dec 30, 2016 at 9:02 PM, Sebastien Jourdain <
>>> sebastien.jourd...@kitware.com> wrote:
>>>
 Hi Debopam,

 1) I'm not sure to know what is the issue with the path but try with
 either:

 "C:/ParaView-5.2.0-Qt4-OpenGL2-MPI-Windows-64bit/data"
 or
 "C:\\ParaView-5.2.0-Qt4-OpenGL2-MPI-Windows-64bit\\data"

 2) paraview_console_error.jpg is not an error since you are not using
 the launcher. So that part is actually expected.
 For the second error when you try to delete the TimeAnnotation, I'm not
 sure to know what is the issue. You should know more by looking at the
 output of the command line.

 Seb


 On Fri, Dec 30, 2016 at 12:53 AM, Debopam Ghoshal 
 wrote:

> (Reposting for a larger audience)
>
> Hi Ken,
>
> When we start paraview web we noted two things:
>
> 1. In the Visualizer, the Files tab is not showing any files. Please
> refer to the attached screenshot (paraview_home.jpg)
> 2. There is an error showing up at the browser console
> (paraview_console_error.jpg, 

[Paraview] Animating a function of a field

[Aleksejs Fomins]

Dear Paraview,

I have a 3d unstructured mesh with two fields defined over it - f(x,y,z) and 
g(x,y,z)
I want to create a movie of a following function

h(t) = f * sin(t) + g * cos(t)

where t is time. How would you do it?

Best regards,
Aleksejs Fomins

PhD Student in Nanophotonics, EPF Lausanne, Switzerland
___
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] slicing a large VTK_POLYHEDRON

[Mathieu Westphal]

Hello

for your information there is a bug in the slicing of vtkPolyHedron that
can cause a segfault.
It looks very much like your error. It has yet to be corrected.
https://gitlab.kitware.com/vtk/vtk/issues/16877

You can already test this "work in progress" branch to see if this fixes
your issue  :
https://gitlab.kitware.com/vtk/vtk/merge_requests/2304

You could of course modify your data to tetrahedron with tetrahedralize
filter.

Regards,

Mathieu Westphal

On Tue, Jan 3, 2017 at 4:10 PM, Pierre Van Hauwaert <
pie...@rtech-engineering.nl> wrote:

> Hi,
>
> I am using paraview to visualise my data. I generate my data using a
> combination of the 2 following types (
> 
> http://www.vtk.org/doc/nightly/html/vtkCellType_8h_source.html)
> VTK_VOXEL
> 
> = 11
> VTK_POLYHEDRON = 42 I can visualize that data with parview without a
> problem. But, because I ended up having a segfault without any error
> message when slicing (Z=0) the data. I decomposed my data in separate files
> for each VTK_POLYHEDRON in order to investigate the problem.
>
> I found out that only the polyhedrons with the largest size were having
> the problem. The limit is somewhere between the 2 files:
> - poly-F1000-2395.vtu : working: 466 points, 928 faces
> - poly-F1000-2987.vtu : segfault when slicing: 546 points, 1088 faces
>
> So my guess is that there is a limit for the number of points or the
> number of faces that can have the polyhedron (1024 ?) if I want to be able
> to use the slice function.
>
> My questions are :
> 1) Is there actually a limitation in Paraview (VTK?) regarding the number
> of faces or the number of the point that the slice function can handle for
> a polyhedron ?
> 2) If there is this limitation, is there an option to remove it in
> Paraview ? (specific version, compilation option, etc)
> 3) If there is this limitation, is there any work around that exist so I
> am able to slice my data ? For example a different format ?
>
>
> I attached the data to be able to back up my statement:
>
> poly-F1000-*.vtu : files describing a polyhedron each:
> poly-F1000.pvd : load all those files
>
> Biggest file for which the slicing works (size, name):
> 34K poly-F1000-2395.vtu
>
> The 8 biggest files triggering the crash when doing a slice: (size, name)
> 38K poly-F1000-2987.vtu
> 39K poly-F1000-2983.vtu
> 39K poly-F1000-2935.vtu
> 39K poly-F1000-2988.vtu
> 39K poly-F1000-2931.vtu
> 40K poly-F1000-2937.vtu
> 40K poly-F1000-2981.vtu
> 40K poly-F1000-2930.vtu
> fail.pvd: load those 8 files
>
> the other files can be sliced without any issues
>
>
> Thanks,
>
> Pierre
>
> --
> R.Tech Engineering B.V.
> Eekholt 42 - 1112 XH Diemen - the Netherlands
> Tel: +31 (0) 2 04 95 02 22
>
> ___
> 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

Re: [Paraview] Still Render in PV5.2.0 takes longer time than in PV4.4.0

[Ken Martin]

For the new OpenGL2 backend setting ImmediateModeRendering or
UseDisplayLists or something similar has no impact. Those concepts are part
of the legacy OpenGL API. So you should see no difference in timings with
them turned on or off with the new OpenGL backend.

On Tue, Jan 3, 2017 at 9:42 AM, Utkarsh Ayachit  wrote:

> On Tue, Jan 3, 2017 at 9:10 AM, David E DeMarle
>  wrote:
> > Is this with OpenGL1 or 2 back end? If you are using Kitware's binaries
> 4.4
> > will be OpenGL1 and 5.2 will be OpenGL2. If you built from source or got
> it
> > from a distro then it might be otherwise.
>
> A way to tell which type of build you're using is to loo at the title
> bar. For OpenGL1, the title bar says "Legacy Rendering Backend". Such
> a suffix is missing for OpenGL2 build.
>
> 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
>



-- 
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] Still Render in PV5.2.0 takes longer time than in PV4.4.0

[Utkarsh Ayachit]

On Tue, Jan 3, 2017 at 9:10 AM, David E DeMarle
 wrote:
> Is this with OpenGL1 or 2 back end? If you are using Kitware's binaries 4.4
> will be OpenGL1 and 5.2 will be OpenGL2. If you built from source or got it
> from a distro then it might be otherwise.

A way to tell which type of build you're using is to loo at the title
bar. For OpenGL1, the title bar says "Legacy Rendering Backend". Such
a suffix is missing for OpenGL2 build.

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] Still Render in PV5.2.0 takes longer time than in PV4.4.0

[David E DeMarle]

Is this with OpenGL1 or 2 back end? If you are using Kitware's binaries 4.4
will be OpenGL1 and 5.2 will be OpenGL2. If you built from source or got it
from a distro then it might be otherwise.

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

On Tue, Jan 3, 2017 at 6:08 AM, 张驭洲  wrote:

>
>
> Hi,
>
> I'm using PV 5.2.0 and PV 4.4.0 in the standalone mode rendering a
> dataset, which contains 10M random points and is just for test. I found
> after I turned off  the display list as the PV User's Guide told me, the
> Still Render process in PV5.2.0 takes longer time than in PV4.4.0.
>
> First, there is a NVIDIA GeForce GT 730 GPU in my computer, so I don't use
> mesa. When rendering with the display list on as default, PV 5.2.0 is
> faster than 4.4.0, which is reasonable. A truncated sample output of Timer
> Log of PV 5.2.0 is as follows:
>
> RenderView::Update,  2.28551 seconds
> vtkPVView::Update,  2.28539 seconds
> Execute vtkFileSeriesReader id: 5063,  1.98558 seconds
> Execute vtkGeometryRepresentationWithFa,  0.298828 seconds
> LegacyVTKFileReader::GatherInformation,  0.300355 seconds
> Still Render,  0.43975 seconds
> & nbsp;   OpenGL Dev Render,  0.334455 seconds
>
> And the counterpart in PV 4.4.0 is:
>
> RenderView::Update,  2.34043 seconds
> vtkPVView::Update,  2.34034 seconds
> Execute vtkFileSeriesReader id: 4734,  1.90546 seconds
> Execute vtkGeometryRepresentationWithFa,  0.43377 seconds
> LegacyVTKFileReader::GatherInformation,  0.440593 seconds
> Still Render,  0.963793 seconds
> OpenGL Dev Render,  0.806468 seconds
>
> While other processes take similar time, the Still Render process in PV
> 5.2.0 takes less than half of that in PV 4.4.0.
> The PV User's Guide recommends that when dealing with very large data,
> turning off display list may help. I tried it and found in this situation
> the Still Render process in PV 5.2.0 takes longer time than in PV 4.4.0.
>
> A truncated sample output of Timer Log of PV 5.2.0 when turning off
> display list is as follows:
>
> RenderView::Update,  2.23385 seconds
> vtkPVView::Update,  2.23374 seconds
> Execute vtkFileSeriesReader id: 4914,  1.93566 seconds
> Execute vtkGeometryRepresentationWithFa,  0.297103 seconds
> LegacyVTKFileReader::GatherInformation,  0.301925 seconds
> Still Render,  0.440343 seconds
> OpenGL Dev Render,  0.335149 seconds
>
> And the counterpart in PV 4.4.0 is:
>
> RenderView::Update,  2.4048 seconds
> vtkPVView::Update,  2.4047 seconds
> Execute vtkFileSeriesReader id: 4733,  1.97007 seconds
> Execute vtkGeometryRepresentationWithFa,  0.433521 seconds
> LegacyVTKFileReader::GatherInformation,  0.440413 seconds
> Still Render,  0.211394 seconds
> OpenGL Dev Render,  0.205734 seconds
>
> While in PV 5.2.0 turning that option off had little effect on the running
> time, it significantly reduced the Still Render time in PV 4.4.0 and made
> the time less than half of that in PV 5.2.0.
>
> Could anyone tell me why this happening? Thanks a lot!
>
> -Zhang
>
>
>
>
>
> ___
> 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

Re: [Paraview] difference in the output of co-processing

[Ufuk Utku Turuncoglu (BE)]

Hi Andy,

No, i am using same PV installation in both case under same server.

As you suggested, i saved the state in Python format and run under GUI 
(Tools > Python Shell > Run Script). It basically opens a new RenderView 
and places the color bars like in co-processing output (misplaced, 
thinner and smaller) and does not show anything about the rest of the 
visualization. It just have color bars but i could see the correct 
pipeline in the pipeline browser. It is little bit weird. If i am doing 
something wrong, please let me know.


Also, i did not modify the default config settings of the GUI and if you 
want me to check any specific option, please let me know.


Thank for your help,
Regards,

--ufuk

On 02/01/2017 18:50, Andy Bauer wrote:

Hi Ufuk,

I'm not sure what is causing the difference. I'm guessing not all of 
the information for the view is saved in the state. Any chance that 
you're using different versions of ParaView for the GUI and Catalyst 
generated images? I see that the Python script is specifying that it 
was generated in a PV 5.2 release candidate.


If it's the same version of PV then you can test the state mechanism 
in PV by saving the state as both a Python script as well as a pvsm 
file. After that, try generating the image by loading the pvsm state 
file and running the Python state file in the GUI.


Another possibility is that there are some config settings in the GUI 
that aren't used in Catalyst. If you don't mind helping narrow down 
the cause of the issue we can put in a bug report for this.


Thanks,
Andy


On Mon, Jan 2, 2017 at 5:27 AM, Ufuk Utku Turuncoglu (BE) 
> wrote:


Hi,

I am trying to use Paraview co-processing component to create
visualization from custom model. The problem is that the color
bars are
misplaced and also smaller and thinner in the co-processing output
(saved
png file) if i compare it with direct visualization from Paraview.
I am
attaching sample png files for both case and also Python file that
is used
for the co-processing. I just wonder that is it possible to fix it
easily?
It might be a bug but i am not sure.

Thanks,
Regards,

--ufuk


___
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] some more questions about Catalyst

[张驭洲]

Hi Andy,

Thanks for your reply! Now I can run the CxxFullExample, but I've encountered 
some more problems about it.

1.The CxxFullExample has a 70x60x44 unstructured grid, and it runs relatively 
quickly. A truncated sample output of Timer Log is as follows:


RenderView::Update,  0.161069 seconds
PVTrivialProducer::GatherInformation,  0.051133 seconds
vtkSMDataDeliveryManager: Deliver Geome,  0.336371 seconds
FullRes Data Migration,  0.336246 seconds
Still Render,  0.034509 seconds
RenderView::Update,  0.149692 seconds
PVTrivialProducer::GatherInformation,  0.051577 seconds
vtkSMDataDeliveryManager: Deliver Geome,  0.322268 seconds
FullRes Data Migration,  0.322144 seconds
Still Render,  0.033618 seconds
RenderView::Update,  0.156578 seconds
PVTrivialProducer::GatherInformation,  0.051578 seconds
vtkSMDataDeliveryManager: Deliver Geome,  0.342933 seconds
FullRes Data Migration,  0.342809 seconds
Still Render,  0.033976 seconds

However, after I modified the grid to a 700x60x44 one and nothing else were 
modified, it became fairly slow when running. Also, a truncated sample output 
of Timer Log:

RenderView::Update,  1.48987 seconds
PVTrivialProducer::GatherInformation,  0.493497 seconds
vtkSMRepresentationProxy::GetRepresente,  2.44198 seconds
vtkSMDataDeliveryManager: Deliver Geome,  0.480933 seconds
FullRes Data Migration,  0.480786 seconds
Still Render,  0.116726 seconds
OpenGL Dev Render,  0.020361 seconds
RenderView::Update,  1.51507 seconds
PVTrivialProducer::GatherInformation,  0.493821 seconds
vtkSMRepresentationProxy::GetRepresente,  2.47383 seconds
vtkSMDataDeliveryManager: Deliver Geome,  0.481844 seconds
FullRes Data Migration,  0.481686 seconds
Still Render,  0.116896 seconds
OpenGL Dev Render,  0.020697 seconds
RenderView::Update,  1.50415 seconds
PVTrivialProducer::GatherInformation,  0.491896 seconds
vtkSMRepresentationProxy::GetRepresente,  2.44277 seconds
vtkSMDataDeliveryManager: Deliver Geome,  0.474105 seconds
FullRes Data Migration,  0.473959 seconds
Still Render,  0.114223 seconds
OpenGL Dev Render,  0.020254 seconds

Comparing the two outputs, I find that the time spent in some processes became 
about 10  times longer, as the dataset became 10 times larger, but some other 
processes didn't  take 10 times longer time. The biggest difference is  
vtkSMRepresentationProxy::GetRepresente, which takes more than 2.4s per frame 
in the bigger dataset example while in the smaller dataset example it takes 
less than 0.01s per frame. I don't know what the program does in the 
vtkSMRepresentationProxy::GetRepresente method. Actually I only know about 
Still Render. Could you please give me a brief introduction to these items? 
And, as Catalyst is designed for in situ visualization of very large dataset, 
is there any method to make the example run faster?

2.When I create Catelyst Python scripts in the ParaView GUI, I have to enable 
all of the Live Visualization, Output to Cinema and Output rendering components 
i.e. views options to get live visualization of the simulation in the PV GUI, 
but under this setting, it generates lots of pictures, which I don't need. If I 
don't enable either of Output to Cinema or Output rendering components i.e. 
views, I could not get the live visualization, and of course no picture is 
generated. But what's the function of the Live Visualization option?

All of the above are situations in the PV 4.4.0 in the client-server mode. As 
for PV 5.2, I have some problems in using it in the client-server mode. Hope 
you can help me. Thank you again!

-Zhang

-原始邮件-
发件人: "Andy Bauer" 
发送时间: 2017年1月2日 星期一
收件人: "张驭洲" 
抄送: "paraview@paraview.org" 
主题: Re: [Paraview] How to start the Catalyst example: CxxFullExample


Hi,


The Catalyst examples have been moved to the ParaView source repo. I'd 
recommend using the newest version of ParaView as well as Catalyst since there 
have been a lot of improvements since PV 4.4.


For the  CxxFullExample, if you've built it with Catalyst enabled you can run 
it as you've done as well as pass in Catalyst Python scripts to use through 
command line arguments.


Andy



On Fri, Dec 30, 2016 at 10:08 PM, 张驭洲  wrote:


Hello everyone,

I'm learning the ParaView Catalyst by starting at the CxxFullExample, which is 
one of the Catalyst examples from 
https://github.com/Kitware/ParaViewCatalystExampleCode-MOVED-. I have compiled 
and built it and got the CxxFullExample executable. It is said that it's a full 
example of a simulation code interfacing with Catalyst, but I don't know how to 
execute it. I typed "./CxxFullExample" in the command line under the build 
directory of the example and nothing happened. I read the Chapter 2 of the 
Catalyst User's Guide and found what's  mainly discussed is about creating 
ParaView Catalyst scripts in ParaView. It is said that to create ParaView 
Catalyst scripts in