Re: [Paraview] [Camera Control] - Clipping Range

[David E DeMarle]

Try LockBounds.

For example:
view = GetActiveView()
view.MaxClipBounds = [x0,x1,y0,y1,z0,z1]
view.LockBounds = 1

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

On Fri, Jul 7, 2017 at 2:51 PM, Utkarsh Ayachit  wrote:

> Currently, you can't. ParaView doesn't let user change ClippingRange. It
> resets it internally before each render.
>
> On Fri, Jul 7, 2017 at 2:44 PM, Mariam  wrote:
>
>> Hi,
>>
>> I am trying to control the camera attributes from pvpython, I noticed
>> that if I modified Clipping Range & Thickness then called Render() the
>> values are reset to the original values. However, changes in camera
>> position, focal point, view up and viewing angle take effect after Render().
>>
>>
>>
>> Here is a snippet of the code:
>>
>> *from *paraview.simple *import **
>> paraview.simple._DisableFirstRenderCameraReset()
>>
>> sphere = Sphere()
>> Show()
>> Render()
>>
>> camera = GetActiveCamera()
>> camera.GetFocalPoint()
>> (0.0, 0.0, 0.0)
>>
>> camera.GetPosition()
>> (0.0, 0.0, 6.69)
>>
>> camera.GetClippingRange()
>> (5.6281001, 8.0428501)
>>
>> camera.SetPosition(0,0,3)
>> Render()
>>
>>
>> camera.GetPosition()
>> (0.0, 0.0, 3.0)
>>
>>
>> camera.GetClippingRange()
>> (1.975, 4.2975)
>>
>> camera.SetClippingRange(3,8)
>> camera.GetClippingRange()
>> (3.0, 8.0)
>>
>> Render()
>>
>>
>> *camera.GetClippingRange()(1.975, 4.2975)*
>>
>>
>>
>>
>>
>> How can I force changes on Clipping Range & Thickness values?
>>
>>
>>
>> Regards,
>>
>> ___
>> 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] [Camera Control] - Clipping Range

[Utkarsh Ayachit]

Currently, you can't. ParaView doesn't let user change ClippingRange. It
resets it internally before each render.

On Fri, Jul 7, 2017 at 2:44 PM, Mariam  wrote:

> Hi,
>
> I am trying to control the camera attributes from pvpython, I noticed that
> if I modified Clipping Range & Thickness then called Render() the values
> are reset to the original values. However, changes in camera position,
> focal point, view up and viewing angle take effect after Render().
>
>
>
> Here is a snippet of the code:
>
> *from *paraview.simple *import **
> paraview.simple._DisableFirstRenderCameraReset()
>
> sphere = Sphere()
> Show()
> Render()
>
> camera = GetActiveCamera()
> camera.GetFocalPoint()
> (0.0, 0.0, 0.0)
>
> camera.GetPosition()
> (0.0, 0.0, 6.69)
>
> camera.GetClippingRange()
> (5.6281001, 8.0428501)
>
> camera.SetPosition(0,0,3)
> Render()
>
>
> camera.GetPosition()
> (0.0, 0.0, 3.0)
>
>
> camera.GetClippingRange()
> (1.975, 4.2975)
>
> camera.SetClippingRange(3,8)
> camera.GetClippingRange()
> (3.0, 8.0)
>
> Render()
>
>
> *camera.GetClippingRange()(1.975, 4.2975)*
>
>
>
>
>
> How can I force changes on Clipping Range & Thickness values?
>
>
>
> Regards,
>
> ___
> 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] [Camera Control] - Clipping Range

[Mariam]

Hi,

I am trying to control the camera attributes from pvpython, I noticed that if I 
modified Clipping Range & Thickness then called Render() the values are reset 
to the original values. However, changes in camera position, focal point, view 
up and viewing angle take effect after Render().

 

Here is a snippet of the code:

from paraview.simple import *
paraview.simple._DisableFirstRenderCameraReset()

sphere = Sphere()
Show()
Render()

camera = GetActiveCamera()
camera.GetFocalPoint()
(0.0, 0.0, 0.0)

camera.GetPosition()
(0.0, 0.0, 6.69)

camera.GetClippingRange()
(5.6281001, 8.0428501)

camera.SetPosition(0,0,3)
Render()


camera.GetPosition()
(0.0, 0.0, 3.0)


camera.GetClippingRange()
(1.975, 4.2975)

camera.SetClippingRange(3,8)
camera.GetClippingRange()
(3.0, 8.0)

Render()

camera.GetClippingRange()
(1.975, 4.2975)

 

 

How can I force changes on Clipping Range & Thickness values?

 

Regards,

___
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] Compute animation in parallel using pvbatch

[Gregory Zaccaro]

Hi all,

Currently I have a .pvsm being loaded on pvbacth with python.

Each time step of the animation is independant and generate a single file for 
that time step.

Now, my goal is to run multiple time steps of this state file in parallel with 
pvbatch.

Is it possible ?

I built Paraview 5.3 from sources on Windows 10.
I enabled some useful options that I think could help :
- PARAVIEW_ENABLE_PYTHON
- PARAVIEW_USE_MPI

Gregory Zaccaro

___
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] Coloring isocontour by the coordinates outputted from a Transform filter and some other questions

[Shuhao Wu]

Is there documentation on how the Box clip type work? I'm not quite sure 
how to do the math to convert the threshold values to the position/scale 
values.


Thanks,
Shuhao

On 2017-07-03 10:03 AM, Cory Quammen wrote:

On Tue, Jun 20, 2017 at 9:33 PM, Shuhao Wu  wrote:


Hello Cory,

I've been playing around a little bit more and followed your suggestion
with using the calculator to "expose" the transformed coordinates. However,
my understanding is that this Calculator will duplicate the memory usage
for that coordinate and be an additional step in the filtering process,
slowing it down.



Yes, that's true unfortunately. By the way, if you need X, Y, and Z, you
can use one Calculator filter to produce all three with the expression

iHat*coordsX + jHat*coordsY + kHat*coordsZ

This produces a 3-component array - you can then color your isosurface by
just one of the components or by the magnitude.

I have to use the Calculator filter to expose all 3 coordinates before

using a threshold to filter for only a subset region that I want to plt,
which results in a filtering chain as follows:

ExposeX (Calculator) -> ExposeY (Calculator) -> ExposeZ (Calculator) ->
ThresholdX (Threshold) -> ThresholdY (Threshold) -> ThresholdZ (Threshold).






This is 6 filters, which is very slow with my data set (>29M nodes in a

rectlinear grid). Is there a way to speed this up?



You could instead use a Clip filter with Clip Type set to Box. You have to
do a little math to convert from your threshold values to the box Scale and
Position properties, but it shouldn't be too bad, and will make your
pipeline simpler and faster.

Cory



Thanks,
Shuhao


On 2017-06-07 03:29 PM, Cory Quammen wrote:


Shuhao,

Welcome to ParaView!

On Sun, Jun 4, 2017 at 6:33 PM, Shuhao Wu  wrote:


Hello all,

Is there a way to color an isocontour via the coordinates outputted from
a
Transform filter? I'm using the Transform filter to "normalize" my
coordinate systems and I want to display the isocontour colored by the
normalized Y coordinates. Do I have to create yet another Calculator
filter
to recalculate the normalized Y value that is already calculated by the
Transform filter?



There is currently no direct way to color surfaces by coordinate
value. You can, however, add a Calculator after the Transform filter
and simply set the expression to coordsY - no recomputation of the
normalization is needed. This will copy your normalized Y coordinate
values to a new array named "Result", and you can then color the
isosurface by "Result". "Result" is just the default name - you can
change it however you wish.

Also: is there a way to turn off one axis on the axis grid (so turn off

the
Y axis display and leave only X and Z)?



Click the Edit button next to the Axes Grid option. Click the gear
icon in the top right of the dialog that appears. Under Face
Properties, click on the "Faces to Render" combo box. Turn off the
sides you do not wish to see by selecting them in the combo box.

What about changing the interval on

the axis itself (instead of incrementing by 100 as it chooses, increment
by
250).



In the same dialog described above, check the "X Axis Use Custom
Labels", and you can specify exactly the labels you want. There is no
property to directly change the increment.

Best,
Cory

I'm pretty new to Paraview (coming from Tecplot). Please bear with me as I

likely will have more question.

Thanks,
Shuhao
___
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] Error handling in a programmable filter.

[Jonathan Borduas]

Added as Issue #17591

Thanks

From: Utkarsh Ayachit [mailto:utkarsh.ayac...@kitware.com]
Sent: Friday, July 7, 2017 10:19 AM
To: Jonathan Borduas 
Cc: paraview@paraview.org
Subject: Re: [Paraview] Error handling in a programmable filter.

We would like to block the updating of the pipeline upon an error in the 
programmable filter (just like a C++ filter).


Raising an exception in the Python script should a interupt your script, 
however from the code I see that that wouln't exactly do what `return 0` in 
RequestData for C++ filter would. Please feel to report a bug on the issue 
tracker. Should be fairly easy to address in  a future release of ParaView.

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] Error handling in a programmable filter.

[Utkarsh Ayachit]

>
> We would like to block the updating of the pipeline upon an error in the
> programmable filter (just like a C++ filter).
>
>
>
Raising an exception in the Python script should a interupt your script,
however from the code I see that that wouln't exactly do what `return 0` in
RequestData for C++ filter would. Please feel to report a bug on the issue
tracker. Should be fairly easy to address in  a future release of ParaView.

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] multiple visualization pipeline at a time with co-processing

[Andy Bauer]

Hi Ufuk,

It's looking to me like the issue is in the adaptor some place. I tried
running your scripts (modified slightly) with the CxxFullExample
(./CxxFullExample script_1.py script_2.py) and was able to get image_s1*
and image_s2* files out of it and did not see the warning you mention. I
also modified that example to use atm_input2d instead of input for the
input/grid identifier to make sure that wasn't the case. I've attached this
example with the scripts modified to print out some debug information.

Some questions (these are pretty basic things that you've probably already
gotten working properly but maybe there's some small thing that was
forgotten):

   - Does your g_coprocessor only get created in your initialization
   routine and deleted in the finalization step? That should not be created
   and deleted during each in situ processing step.
   - Do the vtkCPPythonScriptPipelines only get added during
   initialization? They should not be added and removed from g_coprocessor
   every time step.

Also, could you try running with the scripts that I included in the cat.tgz
tarball? The print statements there will print out the time and time steps
during the simulation run to help me diagnose (both need to be increasing
between calls to Catalyst). Also, if you share your adaptor code with me I
can take a quick look.

Cheers,
Andy



On Fri, Jul 7, 2017 at 7:30 AM, Ufuk Utku Turuncoglu (BE) <
u.utku.turunco...@be.itu.edu.tr> wrote:

> Hi Andy,
>
> Strange! To test the idea and eliminate other problems i am using same
> script twice with little mods (i just changed the name of the output png
> file). So, if i pass script_1.py and script_2.py to the model, it gives
> warning like before and creates output just for second script
> (script_2.py). If i pass only one of them then the code is working without
> any problem and produces desired output.
>
> Thanks,
> Regards,
>
> --ufuk
>
>
>
> On 06/07/2017 18:09, Andy Bauer wrote:
>
> Hi Ufuk,
>
> I'm guessing the issue is that the calls to Catalyst are not consistent.
> Could you share your Python scripts? Also, did you modify them manually?
>
> I tried with PV 5.3. with the 
> ../ParaView-v5.3.0/Examples/Catalyst/CxxFullExample/
> example with the attached scripts simultaneously by running with
> "./CxxFullExample doubleoutputs.py output3.py image11.py" and got the
> correct output and no warnings.
>
> Cheers,
> Andy
>
> On Tue, Jul 4, 2017 at 7:04 AM, Ufuk Utku Turuncoglu (BE) <
> u.utku.turunco...@be.itu.edu.tr> wrote:
>
>> Hi Andy,
>>
>> I tested you suggestion about using multiple script in co-processing. In
>> this case, i used following code in the adaptor side to add multiple
>> pipeline
>>
>>   for (int i = 0; i < *nscript; i++) {
>> pipeline->Initialize(pythonScriptNames[i]);
>> g_coprocessor->AddPipeline(pipeline);
>>   }
>>
>> When i run the simulation, i am getting following warning
>>
>> Warning: In /okyanus/users/uturuncoglu/progs/paraview-5.3.0/src/ParaView
>> Core/VTKExtensions/Core/vtkPVTrivialProducer.cxx, line 66
>> vtkPVTrivialProducer (0x13816760): New time step is not after last time
>> step.
>>
>> the output seems not correct and it is zoom out version of second
>> pipeline (png file). The first pipeline is not even triggered. Do i missing
>> something in here? BTW, i am using PV 5.3.
>>
>> Thanks,
>>
>> --ufuk
>>
>>
>> On 16/05/2017 16:08, Andy Bauer wrote:
>>
>> Hi Ufuk,
>>
>> If you create a vtkCPythonScriptPipeline, when you initialize it with the
>> script file name (which has to be done on each process) everything will be
>> taken care of with respect to broadcasting the file contents from process 0
>> to the others. We aren't sophisticated enough to parse the Python script to
>> see if it imports other scripts that are not part of ParaView (e.g.
>> paraview.simple) or Python (e.g. sys). That is why I recommended the first
>> approach as opposed to the second approach above. Depending on the compute
>> platform and how many MPI processes are in the run the difference may be
>> negligible but having 100K processes or more trying to access the same file
>> can seriously slow down an HPC machine.
>>
>> Cheers,
>> Andy
>>
>> On Tue, May 16, 2017 at 8:24 AM, Ufuk Utku Turuncoglu (BE) <
>> u.utku.turunco...@be.itu.edu.tr> wrote:
>>
>>> Thanks Andy. That is exactly what i am looking for. The broadcasting
>>> mechanism is not clear to me yet. Do i need to broadcast only the file
>>> names? Anyway, i will try to implement it and see what is going on there.
>>>
>>> Thanks again,
>>> Regards,
>>>
>>> --ufuk
>>>
>>>
>>> On 16/05/2017 14:58, Andy Bauer wrote:
>>>
>>> Hi Ufuk,
>>>
>>> Unless I'm not understanding your question correctly, I think you can
>>> get what you want by adding in multiple vtkCPPythonScriptPipelines to your
>>> vtkCPProcessor object in your adaptor. Alternatively if you want to have a
>>> single, master Catalyst script handling other Catalyst scripts you can do
>>> something like the following:

Re: [Paraview] Paraview segfault on (orthographic) slice view

[Cory Quammen]

Dorian,

Thanks for clarifying the source. Sorry I didn't understand from your
earlier email.

I just tried again with the official ParaView 5.4.0 binary and was
able to reproduce your crash.

I'll write up a bug report.

Thanks!
Cory

On Fri, Jul 7, 2017 at 9:23 AM, Vogel Dorian  wrote:
> Hi Cory,
>
>
>
> I am actually using the "Box" source, and just let the default settings for
> it: X/Y/Z length = 1, center = (0,0,0).
>
> Btw: It still occurs on a freshly compiled Paraview v5.4.0 with up-to-date
> mesa.
>
>
>
> Best,
>
>
> --
>
> Dorian Vogel
>
>
> On Friday, July 7, 2017 3:17:00 PM CEST Cory Quammen wrote:
>
>> Dorian,
>
>>
>
>> Thanks for the followup and workaround. If you could share the data
>
>> set with me or tell me how to create it with a ParaView source, I can
>
>> take a closer look.
>
>>
>
>> Thanks,
>
>> Cory
>
>>
>
>> On Fri, Jul 7, 2017 at 4:33 AM, Vogel Dorian  wrote:
>
>> > Hello Cory,
>
>> >
>
>> > Thanks for the follow-up.
>
>> >
>
>> >
>
>> >
>
>> > Unfortunately I do still experience this issue, I gathered a bit more
>
>> > information on the behavior of the issue:
>
>> >
>
>> > Still using a 1x1x1 @(0,0,0) box:
>
>> >
>
>> > -open second layout as tab
>
>> >
>
>> > -open orthographic sliceview
>
>> >
>
>> > -I can scroll on all slice views but ONLY in one direction. As soon as I
>
>> > scroll in the other direction on any of the views, Paraview crashes.
>
>> >
>
>> >
>
>> >
>
>> > ==> this only appends on Polygonal Meshes: If I apply the AppendDatasets
>
>> > filter (outputting an Unstructured Grid) to the same box, everything
>> > seems
>
>> > to work as expected.
>
>> >
>
>> > This is pretty much the Hack I used for my data, convert all the object
>
>> > that I wanted to slice to unstructured grid. While not optimal it does
>
>> > the job.
>
>> >
>
>> >
>
>> >
>
>> > Best,
>
>> >
>
>> >
>
>> > --
>
>> >
>
>> > Dorian Vogel
>
>> >
>
>> > On Thursday, July 6, 2017 10:54:47 PM CEST Cory Quammen wrote:
>
>> >> On Mon, Jun 19, 2017 at 7:18 AM, Vogel Dorian 
>
>> >>
>
>> >> wrote:
>
>> >> > Hi all,
>
>> >> >
>
>> >> >
>
>> >> >
>
>> >> > I've had a serious issue since last week now:
>
>> >> >
>
>> >> >
>
>> >> >
>
>> >> > Whenever I visualize a polygonal Mesh in the Slice View or orthogonal
>
>> >> >
>
>> >> > slice
>
>> >> >
>
>> >> > view:
>
>> >> >
>
>> >> >
>
>> >> >
>
>> >> > - in slice view: Paraview crashes as soon as I click on any of the
>
>> >> > slice
>
>> >> >
>
>> >> > cursors to grab it to another position.
>
>> >> >
>
>> >> >
>
>> >> >
>
>> >> > - in orthographic slice view: I can scroll in one direction on each
>> >> > of
>
>> >> > the
>
>> >> >
>
>> >> > slice views, however, when I scroll in the second direction, Paraview
>
>> >> >
>
>> >> > crashes.
>
>> >>
>
>> >> I could not reproduce either the "Slice View" crash or "Orthographic
>
>> >>
>
>> >> Slice View" crash you report in ParaView 5.4 on macOS.
>
>> >>
>
>> >> > Version 5.3 compiled from source was working fine until I hit this
>
>> >> > error,
>
>> >> >
>
>> >> > I
>
>> >> >
>
>> >> > suspected a package upgrade to be the source of the problem, and
>
>> >> >
>
>> >> > downgraded
>
>> >> >
>
>> >> > Mesa (17.1.2-1 -> 17.1.1-1) and the Intel driver on laptop (17.1.2-1
>> >> > ->
>
>> >> >
>
>> >> > 17.1.1-1) however, this did not help, and I am sure Paraview 5.3 used
>
>> >> > to
>
>> >> >
>
>> >> > work on those versions of mesa and Intel driver.
>
>> >>
>
>> >> Judging by the stack traces you included (very helpful, by the way)
>
>> >>
>
>> >> this looks more like a memory access problem within ParaView. That
>
>> >>
>
>> >> problem seems to have been fixed in ParaView 5.4, though.
>
>> >>
>
>> >>
>
>> >>
>
>> >> HTH,
>
>> >>
>
>> >> Cory
>
>> >>
>
>> >> > Systems:
>
>> >> >
>
>> >> >
>
>> >> >
>
>> >> > -laptop (Archlinux) using Intel IGP or Nvidia discrete GPU using
>
>> >> >
>
>> >> > open-source driver (DRI_PRIME). Crash can be reproduced on both GPU.
>
>> >> >
>
>> >> >
>
>> >> >
>
>> >> > -desktop (Majaro, Arch based): using Nvidia GPU, proprietary driver.
>
>> >> >
>
>> >> >
>
>> >> >
>
>> >> >
>
>> >> >
>
>> >> >
>
>> >> >
>
>> >> > Please find attached the gdb traces. I just started Paraview with
>> >> > each
>
>> >> >
>
>> >> > GPU,
>
>> >> >
>
>> >> > created a box, created a orthographic slice view, and tried to
>> >> > scroll.
>
>> >> >
>
>> >> >
>
>> >> >
>
>> >> >
>
>> >> >
>
>> >> >
>
>> >> >
>
>> >> > Did anyone else observe that ?
>
>> >> >
>
>> >> >
>
>> >> >
>
>> >> >
>
>> >> >
>
>> >> >
>
>> >> >
>
>> >> > Best regards,
>
>> >> >
>
>> >> > --
>
>> >> >
>
>> >> >
>
>> >> >
>
>> >> > Dorian Vogel
>
>> >> >
>
>> >> >
>
>> >> >
>
>> >> >
>
>> >> >
>
>> >> > ___
>
>> >> >
>
>> >> > 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 ParaVi

Re: [Paraview] Paraview python - loop to run through multiple files

[Cory Quammen]

Rebekah,

I think you want to write

LoadState("/home/sophy/Desktop/%s.pvsm" % x)

to properly substitute your filename held in x into the path.

Also, you may want to clear out the loaded state after saving the
image, which you can do by calling

Disconnect()
Connect()

HTH,
Cory


On Fri, Jul 7, 2017 at 6:51 AM, Rebekah L  wrote:
> Hey :)
> I'm trying to script some code so that I can load a file in and then
> WriteImage and then I want this to loop through multiple files so I don't
> have to change the code each time for the new path. My problem is that
> paraview won't recognise a path unless it is the exact path, so I can't get
> it to change automatically. Any help would be greatly appreciated. Here is
> my current code:
>
> sso2_load_python
> from paraview.simple import *
> fname = '/home/sophy/Desktop'
> #I put the files on the desktop so the path was shorter
> filenames = ["c1", "c2"]
> for x in filenames:
>  Loadstate("/home/sophy/Desktop/x.pvsm")
>   WriteImage("/home/sophy/Desktop/image.png")
>
> #the previous two lines have the four space indent but my phone won't let me
> type it like that
>
>
>
> Thanks - Rebekah
>
> ___
> 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
Staff R&D 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] Paraview segfault on (orthographic) slice view

[Vogel Dorian]

Hi Cory,



I am actually using the "Box" source, and just let the default settings for it: 
X/Y/Z length = 1, center = (0,0,0).

Btw: It still occurs on a freshly compiled Paraview v5.4.0 with up-to-date mesa.



Best,

--

Dorian Vogel

On Friday, July 7, 2017 3:17:00 PM CEST Cory Quammen wrote:

> Dorian,

>

> Thanks for the followup and workaround. If you could share the data

> set with me or tell me how to create it with a ParaView source, I can

> take a closer look.

>

> Thanks,

> Cory

>

> On Fri, Jul 7, 2017 at 4:33 AM, Vogel Dorian  wrote:

> > Hello Cory,

> >

> > Thanks for the follow-up.

> >

> >

> >

> > Unfortunately I do still experience this issue, I gathered a bit more

> > information on the behavior of the issue:

> >

> > Still using a 1x1x1 @(0,0,0) box:

> >

> > -open second layout as tab

> >

> > -open orthographic sliceview

> >

> > -I can scroll on all slice views but ONLY in one direction. As soon as I

> > scroll in the other direction on any of the views, Paraview crashes.

> >

> >

> >

> > ==> this only appends on Polygonal Meshes: If I apply the AppendDatasets

> > filter (outputting an Unstructured Grid) to the same box, everything seems

> > to work as expected.

> >

> > This is pretty much the Hack I used for my data, convert all the object

> > that I wanted to slice to unstructured grid. While not optimal it does

> > the job.

> >

> >

> >

> > Best,

> >

> >

> > --

> >

> > Dorian Vogel

> >

> > On Thursday, July 6, 2017 10:54:47 PM CEST Cory Quammen wrote:

> >> On Mon, Jun 19, 2017 at 7:18 AM, Vogel Dorian 

> >>

> >> wrote:

> >> > Hi all,

> >> >

> >> >

> >> >

> >> > I've had a serious issue since last week now:

> >> >

> >> >

> >> >

> >> > Whenever I visualize a polygonal Mesh in the Slice View or orthogonal

> >> >

> >> > slice

> >> >

> >> > view:

> >> >

> >> >

> >> >

> >> > - in slice view: Paraview crashes as soon as I click on any of the

> >> > slice

> >> >

> >> > cursors to grab it to another position.

> >> >

> >> >

> >> >

> >> > - in orthographic slice view: I can scroll in one direction on each of

> >> > the

> >> >

> >> > slice views, however, when I scroll in the second direction, Paraview

> >> >

> >> > crashes.

> >>

> >> I could not reproduce either the "Slice View" crash or "Orthographic

> >>

> >> Slice View" crash you report in ParaView 5.4 on macOS.

> >>

> >> > Version 5.3 compiled from source was working fine until I hit this

> >> > error,

> >> >

> >> > I

> >> >

> >> > suspected a package upgrade to be the source of the problem, and

> >> >

> >> > downgraded

> >> >

> >> > Mesa (17.1.2-1 -> 17.1.1-1) and the Intel driver on laptop (17.1.2-1 ->

> >> >

> >> > 17.1.1-1) however, this did not help, and I am sure Paraview 5.3 used

> >> > to

> >> >

> >> > work on those versions of mesa and Intel driver.

> >>

> >> Judging by the stack traces you included (very helpful, by the way)

> >>

> >> this looks more like a memory access problem within ParaView. That

> >>

> >> problem seems to have been fixed in ParaView 5.4, though.

> >>

> >>

> >>

> >> HTH,

> >>

> >> Cory

> >>

> >> > Systems:

> >> >

> >> >

> >> >

> >> > -laptop (Archlinux) using Intel IGP or Nvidia discrete GPU using

> >> >

> >> > open-source driver (DRI_PRIME). Crash can be reproduced on both GPU.

> >> >

> >> >

> >> >

> >> > -desktop (Majaro, Arch based): using Nvidia GPU, proprietary driver.

> >> >

> >> >

> >> >

> >> >

> >> >

> >> >

> >> >

> >> > Please find attached the gdb traces. I just started Paraview with each

> >> >

> >> > GPU,

> >> >

> >> > created a box, created a orthographic slice view, and tried to scroll.

> >> >

> >> >

> >> >

> >> >

> >> >

> >> >

> >> >

> >> > Did anyone else observe that ?

> >> >

> >> >

> >> >

> >> >

> >> >

> >> >

> >> >

> >> > Best regards,

> >> >

> >> > --

> >> >

> >> >

> >> >

> >> > Dorian Vogel

> >> >

> >> >

> >> >

> >> >

> >> >

> >> > ___

> >> >

> >> > 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.kitw

[Paraview] Error handling in a programmable filter.

[Jonathan Borduas]

Hi Everybody,

Is there a equivalent of "Return 1" in the python programmable filter ?

We would like to block the updating of the pipeline upon an error in the 
programmable filter (just like a C++ filter).

Jonathan Borduas
___
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] Paraview segfault on (orthographic) slice view

[Cory Quammen]

Dorian,

Thanks for the followup and workaround. If you could share the data
set with me or tell me how to create it with a ParaView source, I can
take a closer look.

Thanks,
Cory

On Fri, Jul 7, 2017 at 4:33 AM, Vogel Dorian  wrote:
> Hello Cory,
>
> Thanks for the follow-up.
>
>
>
> Unfortunately I do still experience this issue, I gathered a bit more
> information on the behavior of the issue:
>
> Still using a 1x1x1 @(0,0,0) box:
>
> -open second layout as tab
>
> -open orthographic sliceview
>
> -I can scroll on all slice views but ONLY in one direction. As soon as I
> scroll in the other direction on any of the views, Paraview crashes.
>
>
>
> ==> this only appends on Polygonal Meshes: If I apply the AppendDatasets
> filter (outputting an Unstructured Grid) to the same box, everything seems
> to work as expected.
>
> This is pretty much the Hack I used for my data, convert all the object that
> I wanted to slice to unstructured grid. While not optimal it does the job.
>
>
>
> Best,
>
>
> --
>
> Dorian Vogel
>
>
> On Thursday, July 6, 2017 10:54:47 PM CEST Cory Quammen wrote:
>
>> On Mon, Jun 19, 2017 at 7:18 AM, Vogel Dorian 
>> wrote:
>
>> > Hi all,
>
>> >
>
>> > I've had a serious issue since last week now:
>
>> >
>
>> > Whenever I visualize a polygonal Mesh in the Slice View or orthogonal
>
>> > slice
>
>> > view:
>
>> >
>
>> > - in slice view: Paraview crashes as soon as I click on any of the slice
>
>> > cursors to grab it to another position.
>
>> >
>
>> > - in orthographic slice view: I can scroll in one direction on each of
>> > the
>
>> > slice views, however, when I scroll in the second direction, Paraview
>
>> > crashes.
>
>>
>
>> I could not reproduce either the "Slice View" crash or "Orthographic
>
>> Slice View" crash you report in ParaView 5.4 on macOS.
>
>>
>
>> > Version 5.3 compiled from source was working fine until I hit this
>> > error,
>
>> > I
>
>> > suspected a package upgrade to be the source of the problem, and
>
>> > downgraded
>
>> > Mesa (17.1.2-1 -> 17.1.1-1) and the Intel driver on laptop (17.1.2-1 ->
>
>> > 17.1.1-1) however, this did not help, and I am sure Paraview 5.3 used to
>
>> > work on those versions of mesa and Intel driver.
>
>>
>
>> Judging by the stack traces you included (very helpful, by the way)
>
>> this looks more like a memory access problem within ParaView. That
>
>> problem seems to have been fixed in ParaView 5.4, though.
>
>>
>
>> HTH,
>
>> Cory
>
>>
>
>> > Systems:
>
>> >
>
>> > -laptop (Archlinux) using Intel IGP or Nvidia discrete GPU using
>
>> > open-source driver (DRI_PRIME). Crash can be reproduced on both GPU.
>
>> >
>
>> > -desktop (Majaro, Arch based): using Nvidia GPU, proprietary driver.
>
>> >
>
>> >
>
>> >
>
>> > Please find attached the gdb traces. I just started Paraview with each
>
>> > GPU,
>
>> > created a box, created a orthographic slice view, and tried to scroll.
>
>> >
>
>> >
>
>> >
>
>> > Did anyone else observe that ?
>
>> >
>
>> >
>
>> >
>
>> > Best regards,
>
>> > --
>
>> >
>
>> > Dorian Vogel
>
>> >
>
>> >
>
>> > ___
>
>> > 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
Staff R&D 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] multiple visualization pipeline at a time with co-processing

[Ufuk Utku Turuncoglu (BE)]

Hi Andy,

Strange! To test the idea and eliminate other problems i am using same 
script twice with little mods (i just changed the name of the output png 
file). So, if i pass script_1.py and script_2.py to the model, it gives 
warning like before and creates output just for second script 
(script_2.py). If i pass only one of them then the code is working 
without any problem and produces desired output.


Thanks,
Regards,

--ufuk


On 06/07/2017 18:09, Andy Bauer wrote:

Hi Ufuk,

I'm guessing the issue is that the calls to Catalyst are not 
consistent. Could you share your Python scripts? Also, did you modify 
them manually?


I tried with PV 5.3. with 
the ../ParaView-v5.3.0/Examples/Catalyst/CxxFullExample/ example with 
the attached scripts simultaneously by running with "./CxxFullExample 
doubleoutputs.py output3.py image11.py" and got the correct output and 
no warnings.


Cheers,
Andy

On Tue, Jul 4, 2017 at 7:04 AM, Ufuk Utku Turuncoglu (BE) 
> wrote:


Hi Andy,

I tested you suggestion about using multiple script in
co-processing. In this case, i used following code in the adaptor
side to add multiple pipeline

  for (int i = 0; i < *nscript; i++) {
pipeline->Initialize(pythonScriptNames[i]);
g_coprocessor->AddPipeline(pipeline);
  }

When i run the simulation, i am getting following warning

Warning: In

/okyanus/users/uturuncoglu/progs/paraview-5.3.0/src/ParaViewCore/VTKExtensions/Core/vtkPVTrivialProducer.cxx,
line 66
vtkPVTrivialProducer (0x13816760): New time step is not after last
time step.

the output seems not correct and it is zoom out version of second
pipeline (png file). The first pipeline is not even triggered. Do
i missing something in here? BTW, i am using PV 5.3.

Thanks,

--ufuk


On 16/05/2017 16:08, Andy Bauer wrote:

Hi Ufuk,

If you create a vtkCPythonScriptPipeline, when you initialize it
with the script file name (which has to be done on each process)
everything will be taken care of with respect to broadcasting the
file contents from process 0 to the others. We aren't
sophisticated enough to parse the Python script to see if it
imports other scripts that are not part of ParaView (e.g.
paraview.simple) or Python (e.g. sys). That is why I recommended
the first approach as opposed to the second approach above.
Depending on the compute platform and how many MPI processes are
in the run the difference may be negligible but having 100K
processes or more trying to access the same file can seriously
slow down an HPC machine.

Cheers,
Andy

On Tue, May 16, 2017 at 8:24 AM, Ufuk Utku Turuncoglu (BE)
mailto:u.utku.turunco...@be.itu.edu.tr>> wrote:

Thanks Andy. That is exactly what i am looking for. The
broadcasting mechanism is not clear to me yet. Do i need to
broadcast only the file names? Anyway, i will try to
implement it and see what is going on there.

Thanks again,
Regards,

--ufuk


On 16/05/2017 14:58, Andy Bauer wrote:

Hi Ufuk,

Unless I'm not understanding your question correctly, I
think you can get what you want by adding in multiple
vtkCPPythonScriptPipelines to your vtkCPProcessor object in
your adaptor. Alternatively if you want to have a single,
master Catalyst script handling other Catalyst scripts you
can do something like the following:

import script_a
import script_b
import script_c

def RequestDataDescription(datadescription):
script_a.RequestDataDescription(datadescription)
script_b.RequestDataDescription(datadescription)
script_c.RequestDataDescription(datadescription)

def DoCoProcessing(datadescription):
script_a.DoCoProcessing(datadescription)
script_b.DoCoProcessing(datadescription)
script_c.DoCoProcessing(datadescription)
===

The first way is the recommended way though as that should
be more efficient by having process 0 read the scripts and
broadcasting the script contents to the other  processes for
use. The second method will only do that for the master script.

Please let me know if this doesn't answer your question.

Cheers,
Andy

On Tue, May 16, 2017 at 5:46 AM, Ufuk Utku Turuncoglu (BE)
mailto:u.utku.turunco...@be.itu.edu.tr>> wrote:

Hi All,

I just wonder that is it possible to trigger multiple
visualization pipeline in the same time with
co-processing. The co-processing script generator plugin
mainly outputs only single pipeline at a time and that
is fine but what about combining multiple Python script
(generated by plugin) us

[Paraview] Paraview python - loop to run through multiple files

[Rebekah L]

Hey :)
I'm trying to script some code so that I can load a file in and then
WriteImage and then I want this to loop through multiple files so I don't
have to change the code each time for the new path. My problem is that
paraview won't recognise a path unless it is the exact path, so I can't get
it to change automatically. Any help would be greatly appreciated. Here is
my current code:

sso2_load_python
from paraview.simple import *
fname = '/home/sophy/Desktop'
#I put the files on the desktop so the path was shorter
filenames = ["c1", "c2"]
for x in filenames:
 Loadstate("/home/sophy/Desktop/x.pvsm")
  WriteImage("/home/sophy/Desktop/image.png")

#the previous two lines have the four space indent but my phone won't let
me type it like that



Thanks - Rebekah
___
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] Paraview segfault on (orthographic) slice view

[Vogel Dorian]

Hello Cory,

Thanks for the follow-up.



Unfortunately I do still experience this issue, I gathered a bit more 
information on the behavior of the issue:

Still using a 1x1x1 @(0,0,0) box:

-open second layout as tab

-open orthographic sliceview

-I can scroll on all slice views but ONLY in one direction. As soon as I scroll 
in the other direction on any of the views, Paraview crashes.



==> this only appends on Polygonal Meshes: If I apply the AppendDatasets filter 
(outputting an Unstructured Grid) to the same box, everything seems to work as 
expected.

This is pretty much the Hack I used for my data, convert all the object that I 
wanted to slice to unstructured grid. While not optimal it does the job.



Best,

--

Dorian Vogel

On Thursday, July 6, 2017 10:54:47 PM CEST Cory Quammen wrote:

> On Mon, Jun 19, 2017 at 7:18 AM, Vogel Dorian  wrote:

> > Hi all,

> >

> > I've had a serious issue since last week now:

> >

> > Whenever I visualize a polygonal Mesh in the Slice View or orthogonal

> > slice

> > view:

> >

> > - in slice view: Paraview crashes as soon as I click on any of the slice

> > cursors to grab it to another position.

> >

> > - in orthographic slice view: I can scroll in one direction on each of the

> > slice views, however, when I scroll in the second direction, Paraview

> > crashes.

>

> I could not reproduce either the "Slice View" crash or "Orthographic

> Slice View" crash you report in ParaView 5.4 on macOS.

>

> > Version 5.3 compiled from source was working fine until I hit this error,

> > I

> > suspected a package upgrade to be the source of the problem, and

> > downgraded

> > Mesa (17.1.2-1 -> 17.1.1-1) and the Intel driver on laptop (17.1.2-1 ->

> > 17.1.1-1) however, this did not help, and I am sure Paraview 5.3 used to

> > work on those versions of mesa and Intel driver.

>

> Judging by the stack traces you included (very helpful, by the way)

> this looks more like a memory access problem within ParaView. That

> problem seems to have been fixed in ParaView 5.4, though.

>

> HTH,

> Cory

>

> > Systems:

> >

> > -laptop (Archlinux) using Intel IGP or Nvidia discrete GPU using

> > open-source driver (DRI_PRIME). Crash can be reproduced on both GPU.

> >

> > -desktop (Majaro, Arch based): using Nvidia GPU, proprietary driver.

> >

> >

> >

> > Please find attached the gdb traces. I just started Paraview with each

> > GPU,

> > created a box, created a orthographic slice view, and tried to scroll.

> >

> >

> >

> > Did anyone else observe that ?

> >

> >

> >

> > Best regards,

> > --

> >

> > Dorian Vogel

> >

> >

> > ___

> > 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] Two issues with time-dependent data

[Schuld, Heinrich]

Thanks Cory for your idea. The problem is, that I would have to set the end of 
the TIME_RANGE dependently on the timesteps requested by ParaView. Otherwise 
the delta t between timesteps will not be equal. I could modify my filter so 
that the user has to select the number of timesteps in it. But I was hoping to 
use the already present functionalities of ParaView.

Cheers,
Heinrich


-Ursprüngliche Nachricht-
Von: Cory Quammen [mailto:cory.quam...@kitware.com] 
Gesendet: Donnerstag, 6. Juli 2017 21:54
An: Schuld, Heinrich 
Cc: paraview@paraview.org
Betreff: Re: [Paraview] Two issues with time-dependent data

[snip]
> 1.   In RequestInformation of the filter, we provide the pipeline just
> with a TIME_RANGE. This is so far working without problem, we can go through
> the range by Sequence or Real Time. When running the Animation as a loop
> though, we encounter the issue that the beginning and the end of the time
> range are both displayed. Since our data is periodic and the TIME_RANGE is a
> cycle duration, these two steps are identical. As you can guess, it is not
> desired to see the same step two times right behind each other. Is there a
> way to prevent this behaviour?

Can you just set the upper end of the TIME_RANGE to one timestep
before what you have now? In other words, instead of having the first
and last timesteps provide the same data, end the TIME_RANGE earlier
by one timestep. That will prevent the doubling of the timestep when
the animation resets.

> 2.   When we save the filter in a state file and load it afterwards with
> a different dataset, the displayed time range in ParaView shows the wrong
> data. Although in RequestInformation the correct TIME_RANGE of the new
> dataset is set to the pipeline, ParaView/the Animation View still shows the
> time data of the state file. It only changes, if after loading the state
> file, a different TIME_RANGE with different values is set in
> RequestInformation. We can live with this issue, but maybe it is a bug that
> is easy to fix.

I'm not sure about this one. Maybe someone else can chime in.

Thanks,
Cory

>
>
> We will be grateful for any advice or suggestion!
>
>
>
> Thanks in advance and cheers,
>
> Heinrich
>
>
>
> --
>
> Dipl.-Ing. Heinrich Schuld
>
> Institute of Jet Propulsion and Turbomachinery
>
> RWTH Aachen
>
> Templergraben 55
>
> 52062 Aachen
>
> Germany
>
>
>
> Tel: +49 241 80 99652
>
> Fax:+49 241 80 92229
>
> E-Mail:   sch...@ist.rwth-aachen.de
>
> www: http://www.ist.rwth-aachen.de
>
>
>
>
> ___
> 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
Staff R&D 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