Re: [Paraview] [EXTERNAL] Time Synchronization for Case and Geometry Sequences

[Moreland, Kenneth]

I may have told you the wrong parameters. Try using 0.005 for the temporal 
shift rather than -0.005.

-Ken

On 12/1/16, 3:10 PM, "Huangrui Mo"  wrote:

Hello Ken,

Thank you for the provided solution, however, it seems like the solution 
does not work well: using the Paraview 5.2.0
(I just downloaded the latest version, and realizing that there is a 
modification on showing the max counter of time steps),
after applying the method you provided, it artificially works for the 
first 9 counts, but when you input "10", then you would realize that
the mismatch is still there :D

I have found the following weired situation:

1) The time values in field.case, field.pvd, geo_stl.pvd are all exactly 
the same and are all in ASCII format.
2) When paraview read in the field.pvd or geo_stl.pvd, it will change 
the floating point values slightly, however, it maintains consistence
if they are ".pvd" files. Therefore, it correctly synchronizes these two 
data sets.
3) When paraview read in the field.case, the floating point 
representation of the time values are changed slightly and are not 
consistently with ".pvd" files.
However, in this mixed case, the "0" value is the same, so paraview 
merges field.case and geo_stl.pvd for time "0", and reduces the total 
number of cases
from 11 + 11 to 21. (sorry for previous miscalculation of the counter, 
it's 11 rather than 10 for each data set.)

Is it because when reading Ensight format, paraview choose single 
precision, but using double  precision for .pvd file? Is there a way to 
fix this problem, since
the time values are all in ASCII format.

Thanks,
Huangrui

On 2016-12-01 03:35 PM, Moreland, Kenneth wrote:
> Huangrui,
>
> I found a work around that I think does what you want. After you load in 
your two data sets, right click on one of them in the Pipeline Browser and 
check on the “Ignore Time” option. This will tell ParaView to ignore the time 
in that data set, so will only visit the time steps in the other data set.
>
> Actually, this _almost_ works. There is in fact a problem (at least with 
the example data sets you sent us). The imprecision is not uniform. Sometimes 
the time for field.case is ahead, other times the time for geo_stl.pvd is 
ahead. So, when you play through the time steps, sometimes the data for which 
you are ignoring time are skipped because the time is first just before one 
step and then just after another.
>
> To fix this problem, you can use the Temporal Shift Scale filter to 
adjust the time of one of the data sets to subtract a bit to ensure that every 
time hits in between time steps. Here is specifically what I did with the test 
data that you sent to fix the problem.
>
> 1. Load in the field.case and geo_stl.pvd files. Apply both.
> 2. Add the Temporal Shift Scale filter to geo_stl.pvd. Set the Pre Shift 
to -0.005. Apply.
> 3. Right click on TemporalShiftScale1 in the pipeline browser and select 
“Ignore Time”
>
> Now when you hit play you should get the right amount of time steps with 
the data you expect loaded.
>
> -Ken
>
> On 12/1/16, 1:58 PM, "Huangrui Mo"  wrote:
>
>  Hello Alan and Ken,
>  
>  Thank you very much for your prompt response of my question.
>  
>  After testing your suggestions, I found both the Real Time Mode and
>  Sequence Mode can correctly synchronize the
>  two data sets with mixed formats, if a correct number of steps is 
given.
>  However, both of the above two methods
>  share a common subproblem: they give artificial time steps that are
>  different with the "true" time moments contained in
>  the case (or pvd) files, when a annotated time filter is used, even 
the
>  specified number of steps matches the true number of case files.
>  
>  Regarding the Snap to Timesteps mode and the numerical imprecision of
>  the different times problem raised by Ken, I provided an example
>  data set attached in this email. This data set contains the simulated
>  flow field of three airfoils running on a fixed Cartesian background 
grid.
>  Since the Cartesian grid is fixed, therefore, using Ensight format 
for
>  the field data has the advantage to avoid outputting the grid
>  coordinates in each
>  time step but only the physical quantities. To facilitate the 
testing, I
>  solved this problem exactly twice, the only difference is that one 
uses
>  Ensight for field data
>  and VTK for geometry, the other uses both VTK. Each data sets has 10
>  time sequences, and the time steps in each data sets are all the 
same.
>  
>  When loading the mixed data sets, the field.case + geo_stl.pvd gives 
20

Re: [Paraview] [EXTERNAL] Unable to rescale properly the color map

[Luigi R]

No problem Alan. Thanks for replying. I thought my issue was due to truncation. 
Anyhow, I had a look at the bug #16978 and, if I can, I would like to give my 
opinion. When min and max are the same or both zero, I expect as user to see an 
unique color in the color map either red or blue. If you add an eps to the max 
and still show the full rgb color map, I would think immediately that there are 
not enough digit in the label and I would start playing with that or rescaling 
to find where the differences are.


Best regards,


Luigi



Da: Scott, W Alan 
Inviato: giovedì 1 dicembre 2016 19.36
A: Luigi R
Oggetto: RE: [EXTERNAL] [Paraview] Unable to rescale properly the color map


Luigi - Since everyone mis-spells my name, and I don't like it, I should have 
been more careful with yours.



Sorry about that.



Alan







From: Scott, W Alan
Sent: Thursday, December 1, 2016 10:57 AM
To: 'Luigi R' ; paraview@paraview.org
Subject: RE: [EXTERNAL] [Paraview] Unable to rescale properly the color map



Lugi,

I am fairly sure you are seeing this bug: 
https://gitlab.kitware.com/paraview/paraview/issues/16978.  It is scheduled to 
be fixed in an upcoming release, but the solution isn't trivial.  I will add 
your example to the bug.

[https://gitlab.kitware.com/uploads/project/avatar/14/pvIcon-512x512.png]

color legend max wrong for zero (#16978) · Issues · ParaView / 
ParaView
gitlab.kitware.com
The color legend is wrong for any data that has a maximum value same as the 
minimum value. Here is how to replicate. * Local server, Linux, 5.2.0-rc2 * 
Open...





Alan



From: ParaView [mailto:paraview-boun...@paraview.org] On Behalf Of Luigi R
Sent: Thursday, December 1, 2016 6:39 AM
To: paraview@paraview.org
Subject: [EXTERNAL] [Paraview] Unable to rescale properly the color map



Dear developers,



I'm loading a vtp file in Paraview 5.2 containing the agglomerated mesh and a 
scalar field (INT32) for the global cellID. The coarsest mesh has few cells 
characterized by a high identification number (cellID ranges from 160 to 
1600010]. Paraview is not able to rescale properly the range of the color map 
even with the custom data range and everything is displayed with a blue color 
and it becomes useless. Is there a way to change the precision for the color 
map.



I have also tested the version 5.0.1 which scales better but still cannot go 
below a certain range.



Please let me know.



Best regards,



Luigi


___
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] Experimental Data Interpolate/Extrapolate to Custom Volume Mesh

[Gallagher, Timothy P]

If I understand you correctly, you were able to take each experimental plane 
and sample it in a the CFD data on the same plane? Now you would like to stack 
your experimental planes together and interpolate it onto the CFD grid?


I haven't done this, so I'm not sure if it's going to work, but can't you do a 
little preprocessing and then do the steps in reverse from before? What I mean 
is:


1. Take all your experimental planes (u, v, w, x, y) at a given z and 
concatenate the files together, adding the z coordinate at the end, to get (u, 
v, w, x, y, z)

2. Load this into Paraview and use the TableToPoints filter

3. Load your CFD grid

4. Select your TableToPoints filter and do:

a. ResampleWithDataset -- select the TableToPoints as the input and the CFD 
grid as the Source


This should then give you the data points from the experimental data 
interpolated onto the CFD grid.


Does that seem like what you are trying to do?


Tim



From: tree...@gmail.com  on behalf of Mike Tree 

Sent: Thursday, December 1, 2016 2:30 PM
To: Gallagher, Timothy P
Cc: paraview@paraview.org
Subject: Re: [Paraview] Experimental Data Interpolate/Extrapolate to Custom 
Volume Mesh

Tim,

I successfully used my experimental data planes to sample my CFD data for 
comparison, but now I've got another procedure to tackle.

I am looking to interpolate between my experimental planes and fill in the 
volumetric velocity data. I've spent significant time working with the 
GaussianResample filter, but it seems to eliminate some of my data. 
Specifically, GaussianResample can only interpolate scalars, so I have to 
decompose my velocity vector into its components. This seems to work fine, 
except that when the GaussianResample filter is applied the negative values of 
these components are eliminated. Then, when I re-calculate my velocity vector 
as a sum of the component it is obviously wrong because none of the components 
are permitted to be negative.

Are there any other filters in existence that I can use for interpolation?

Any help will be most appreciated.

-Mike Tree

On Tue, Nov 8, 2016 at 9:42 AM, Mike Tree 
mailto:tree...@gatech.edu>> wrote:
Tim,

Seems pretty straight forward. Thanks! I'll let you know if I have any issues.

-MT

On Mon, Nov 7, 2016 at 12:00 PM, Gallagher, Timothy P 
mailto:tim.gallag...@gatech.edu>> wrote:

Mike,


Your state file doesn't work without the data files that go along with it.


That said, here is how you can do it:


1. Load your .dat file and use the TableToPoints filter to create points from 
the data table -- select your x, y, z appropriately

2. Load your CFD data file

3. Select your CFD data file and then do:

a. ResampleWithDataset -- select the CFD data as the Input and the 
TableToPoints as the Source

4. This will give you the data interpolated to the points in the table, if you 
want a plane from this data, apply the Delaunay2D filter and select 
Best-Fitting Plane (if the points are not X-Y points only).


That should give you the data from your CFD simulation on the same plane as 
your PIV data.


I see you are at GT -- let me know if you are still unclear on these steps and 
would like to talk in person.


Tim



From: ParaView 
mailto:paraview-boun...@paraview.org>> on behalf 
of Mike Tree mailto:tree...@gatech.edu>>
Sent: Tuesday, November 17, 2015 5:32 PM
To: paraview@paraview.org
Subject: [Paraview] Experimental Data Interpolate/Extrapolate to Custom Volume 
Mesh

I have three planes of experimental PIV data with velocity point data in .dat 
format loaded in Paraview. I am hoping to use these planes to 
interpolate/extrapolate velocity values onto a custom volumetric mesh (i.e. 
from a CFD simulation) to compare experimental results with simulation results 
in hopes of validating the simulation. I have attached my Paraview state file. 
Any help will be much appreciated.

Thanks,
-MT

--
Mike Tree, PhD Student
Cardiovascular Fluid Mechanics Laboratory
Georgia Institute of Technology
Atlanta, GA
tree...@gatech.edu
678-249-0922
[https://mailfoogae.appspot.com/t?sender=adHJlZW0yMkBnbWFpbC5jb20%3D&type=zerocontent&guid=82092feb-f151-4b75-8a88-41da2f2b684b]?



--
Mike Tree, PhD Candidate
Cardiovascular Fluid Mechanics Laboratory
Georgia Institute of Technology
Atlanta, GA
tree...@gatech.edu
678-249-0922



--
Mike Tree, PhD Candidate
Cardiovascular Fluid Mechanics Laboratory
Georgia Institute of Technology
Atlanta, GA
tree...@gatech.edu
678-249-0922
___
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

Re: [Paraview] [EXTERNAL] Time Synchronization for Case and Geometry Sequences

[Huangrui Mo]

Hello Ken,

Thank you for the provided solution, however, it seems like the solution 
does not work well: using the Paraview 5.2.0
(I just downloaded the latest version, and realizing that there is a 
modification on showing the max counter of time steps),
after applying the method you provided, it artificially works for the 
first 9 counts, but when you input "10", then you would realize that

the mismatch is still there :D

I have found the following weired situation:

1) The time values in field.case, field.pvd, geo_stl.pvd are all exactly 
the same and are all in ASCII format.
2) When paraview read in the field.pvd or geo_stl.pvd, it will change 
the floating point values slightly, however, it maintains consistence
if they are ".pvd" files. Therefore, it correctly synchronizes these two 
data sets.
3) When paraview read in the field.case, the floating point 
representation of the time values are changed slightly and are not 
consistently with ".pvd" files.
However, in this mixed case, the "0" value is the same, so paraview 
merges field.case and geo_stl.pvd for time "0", and reduces the total 
number of cases
from 11 + 11 to 21. (sorry for previous miscalculation of the counter, 
it's 11 rather than 10 for each data set.)


Is it because when reading Ensight format, paraview choose single 
precision, but using double  precision for .pvd file? Is there a way to 
fix this problem, since

the time values are all in ASCII format.

Thanks,
Huangrui

On 2016-12-01 03:35 PM, Moreland, Kenneth wrote:

Huangrui,

I found a work around that I think does what you want. After you load in your 
two data sets, right click on one of them in the Pipeline Browser and check on 
the “Ignore Time” option. This will tell ParaView to ignore the time in that 
data set, so will only visit the time steps in the other data set.

Actually, this _almost_ works. There is in fact a problem (at least with the 
example data sets you sent us). The imprecision is not uniform. Sometimes the 
time for field.case is ahead, other times the time for geo_stl.pvd is ahead. 
So, when you play through the time steps, sometimes the data for which you are 
ignoring time are skipped because the time is first just before one step and 
then just after another.

To fix this problem, you can use the Temporal Shift Scale filter to adjust the 
time of one of the data sets to subtract a bit to ensure that every time hits 
in between time steps. Here is specifically what I did with the test data that 
you sent to fix the problem.

1. Load in the field.case and geo_stl.pvd files. Apply both.
2. Add the Temporal Shift Scale filter to geo_stl.pvd. Set the Pre Shift to 
-0.005. Apply.
3. Right click on TemporalShiftScale1 in the pipeline browser and select 
“Ignore Time”

Now when you hit play you should get the right amount of time steps with the 
data you expect loaded.

-Ken

On 12/1/16, 1:58 PM, "Huangrui Mo"  wrote:

 Hello Alan and Ken,
 
 Thank you very much for your prompt response of my question.
 
 After testing your suggestions, I found both the Real Time Mode and

 Sequence Mode can correctly synchronize the
 two data sets with mixed formats, if a correct number of steps is given.
 However, both of the above two methods
 share a common subproblem: they give artificial time steps that are
 different with the "true" time moments contained in
 the case (or pvd) files, when a annotated time filter is used, even the
 specified number of steps matches the true number of case files.
 
 Regarding the Snap to Timesteps mode and the numerical imprecision of

 the different times problem raised by Ken, I provided an example
 data set attached in this email. This data set contains the simulated
 flow field of three airfoils running on a fixed Cartesian background grid.
 Since the Cartesian grid is fixed, therefore, using Ensight format for
 the field data has the advantage to avoid outputting the grid
 coordinates in each
 time step but only the physical quantities. To facilitate the testing, I
 solved this problem exactly twice, the only difference is that one uses
 Ensight for field data
 and VTK for geometry, the other uses both VTK. Each data sets has 10
 time sequences, and the time steps in each data sets are all the same.
 
 When loading the mixed data sets, the field.case + geo_stl.pvd gives 20

 sequences, and the field.pvd + geo_stl.pvd  gives 10 synchronized 
sequences.
 
 Due to the artificial times steps in the Real Time Mode and Sequence

 Mod, is there a way to synchronize the mixed case in the Snap to
 Timesteps mode?
 
 Thanks a lot,

 Huangrui
 
 
 
 On 2016-12-01 01:54 PM, Moreland, Kenneth wrote:

 > Actually, I think Sequence mode is more appropriate than Real Time mode 
in this case, but I too think that is the answer.
 >
 > To explain more what (we think) is going on: Wh

Re: [Paraview] Fwd: Segfault reading polyhedral cells xdmf3 file

[Alessandro De Maio]

Both the cases are ok on the Windows PC.

On Thu, Dec 1, 2016 at 6:19 PM, Armin Wehrfritz  wrote:

> To follow up on this issue, I have done some more testing. From the link
> below you can find two datasets with polyhedral cells, where one is
> working just fine and the other one is crashing consistently when
> opening it in ParaView 5.2.
> The XDMF files are created form the respective .vtu files with ParaView
> 5.2 (Kitware binaries, Linux 64bit) using the Xdmf3 writer.
>
> The strange thing is that the dataset leading to the seg fault is a
> subset of the dataset that just works fine.
>
> Here the link:
> https://drive.google.com/file/d/0B5CHY8CFeTf2V09NVUhTRkpYSE0
> /view?usp=sharing
>
> Alessandro, can you test these files and report back which ones are
> working on your PC?
>
> Thanks,
> Armin
>
>
>
>
>
>
>
> On 11/30/2016 08:19 PM, Alessandro De Maio wrote:
>
>> You're right: the polyhedral cells of the cube.vtu example do not
>> guarantee the planarity of faces, but this is a typical case of a
>> polyhedral mesh automatically generated starting from a tetrahedral one
>> (this example has been built using the Ansys-Fluent converter) and I
>> think it's quite a usual situation.
>> But I'm not sure this could generate a segfault as the problem could be
>> in the algorythms applied by Paraview after the reading of the file that
>> could consider this hypothesis (as you remarked), while the VTK
>> topological description of a polyhedral cell doesn't seem to need it,
>> and the reading phase should only build the data structure compliant
>> with VTK data representation, as actually happens for vtu file format.
>> But this is only my opinion and of course it could be wrong as I don't
>> have a deep knowledge of all the involved procedures.
>> My idea is that the problem could be due to a memory error, as it's only
>> unfrequent with a small case (by the way the one cell mesh you attached
>> can be read also on the windows machine although with a randomic
>> connectivity error as the one I showed in the image attached to the
>> previous message) but very frequent with a quite bigger case as the cube.
>> Is it possible to use something like valgrind to check for memory errors
>> in Paraview ?
>>
>> On Wed, Nov 30, 2016 at 6:35 PM, Armin Wehrfritz > > wrote:
>>
>> In attach you can find the output of the saving of the
>> polyhedron.vtu
>> (saved.xmf and saved.h5) from the Windows machine.
>>
>> OK, I tested the "saved.xmf" file and I can open it on my Linux
>> machine
>> without issues. Also, I compared the files generated on windows and
>> linux machines, and the topology data is the same for both of them.
>> The
>> datatype in the h5 file is different (H5T_STD_I32LE for the file from
>> the Windows machine vs. H5T_STD_I64LE for the file from the Linux
>> machine). The end of line in the xmf file is different, but I don't
>> think either one of them should cause an issue.
>>
>> I've tried also to repeat the procedure (reading of your xmf
>> file) on a
>> Linux workstation and the behaviour is different: it seems that
>> randomically the crash happens again (once on about ten tries) and
>> sometimes it seems that the topology has a connectivity error
>> (see the
>> image in attachment), while for the most of the times it seems
>> to do the
>> right job.
>>
>> As said, on my Linux machine it works consistently.
>>
>> I've tried also another case, a little bit heavier: a polyhedral
>> mesh
>> read from the vtu in attach (cube.vtu) and saved with the Xdmf3
>> writer.
>> Trying to re-read the xmf version of this geometry always
>> produces a
>> crash also on the Linux machine.
>>
>> I can confirm that the xmf file produce from the cube.vtu (using the
>> Xdmf3 writer in ParaView 5.2) leads consistently to seg fault.
>> However, even though the .vtu file works correctly, I'm not entirely
>> sure if this is xmf specific problem. To be more precise, the
>> implementation of polyhedral cells requires the face polygons to be
>> planar (see http://www.vtk.org/Wiki/VTK/Polyhedron_Support
>> ). The example
>> file you send has a whole lot of faces that are not planar.
>>
>> I extracted a single cell with several non-planar faces from your
>> example and saved it as .xmf file (attached). I can read this
>> particular
>> file without issues on my Linux machine, whereas the original data
>> file
>> leads to a seg fault. One reason why the cube.vtu file works and the
>> respective .xmf doesn't, could be related to the different approaches
>> polyhedral cells are stored in vtu and xdmf files, but debugging this
>> would require quite a bit of work...
>>
>> Maybe somebody else has an idea here.
>>
>> -Armi

Re: [Paraview] [EXTERNAL] Time Synchronization for Case and Geometry Sequences

[Moreland, Kenneth]

Huangrui,

I found a work around that I think does what you want. After you load in your 
two data sets, right click on one of them in the Pipeline Browser and check on 
the “Ignore Time” option. This will tell ParaView to ignore the time in that 
data set, so will only visit the time steps in the other data set.

Actually, this _almost_ works. There is in fact a problem (at least with the 
example data sets you sent us). The imprecision is not uniform. Sometimes the 
time for field.case is ahead, other times the time for geo_stl.pvd is ahead. 
So, when you play through the time steps, sometimes the data for which you are 
ignoring time are skipped because the time is first just before one step and 
then just after another.

To fix this problem, you can use the Temporal Shift Scale filter to adjust the 
time of one of the data sets to subtract a bit to ensure that every time hits 
in between time steps. Here is specifically what I did with the test data that 
you sent to fix the problem.

1. Load in the field.case and geo_stl.pvd files. Apply both.
2. Add the Temporal Shift Scale filter to geo_stl.pvd. Set the Pre Shift to 
-0.005. Apply.
3. Right click on TemporalShiftScale1 in the pipeline browser and select 
“Ignore Time”

Now when you hit play you should get the right amount of time steps with the 
data you expect loaded.

-Ken

On 12/1/16, 1:58 PM, "Huangrui Mo"  wrote:

Hello Alan and Ken,

Thank you very much for your prompt response of my question.

After testing your suggestions, I found both the Real Time Mode and 
Sequence Mode can correctly synchronize the
two data sets with mixed formats, if a correct number of steps is given. 
However, both of the above two methods
share a common subproblem: they give artificial time steps that are 
different with the "true" time moments contained in
the case (or pvd) files, when a annotated time filter is used, even the 
specified number of steps matches the true number of case files.

Regarding the Snap to Timesteps mode and the numerical imprecision of 
the different times problem raised by Ken, I provided an example
data set attached in this email. This data set contains the simulated 
flow field of three airfoils running on a fixed Cartesian background grid.
Since the Cartesian grid is fixed, therefore, using Ensight format for 
the field data has the advantage to avoid outputting the grid 
coordinates in each
time step but only the physical quantities. To facilitate the testing, I 
solved this problem exactly twice, the only difference is that one uses 
Ensight for field data
and VTK for geometry, the other uses both VTK. Each data sets has 10 
time sequences, and the time steps in each data sets are all the same.

When loading the mixed data sets, the field.case + geo_stl.pvd gives 20 
sequences, and the field.pvd + geo_stl.pvd  gives 10 synchronized sequences.

Due to the artificial times steps in the Real Time Mode and Sequence 
Mod, is there a way to synchronize the mixed case in the Snap to 
Timesteps mode?

Thanks a lot,
Huangrui



On 2016-12-01 01:54 PM, Moreland, Kenneth wrote:
> Actually, I think Sequence mode is more appropriate than Real Time mode 
in this case, but I too think that is the answer.
>
> To explain more what (we think) is going on: When you load data with time 
in ParaView, it goes to a Snap to Timesteps mode where it will visit each 
unique timestep once regardless of how far apart they are. Thus, ParaView is 
treating the numerical imprecision of the different times as unique time steps. 
If you switch to Sequence or Real Time mode, ParaView uses its own time units 
and will provide an even temporal spacing.
>
> There is more information about the different animation modes in the 
ParaView tutorial.
>
> -Ken
>
> Sent from my iPad so blame autocorrect.
>
>> On Dec 1, 2016, at 11:35 AM, Scott, W Alan  wrote:
>>
>> Not sure if this is the correct answer, but try view/ animation View.  
Then, change the Mode to Real Time.  Enter your start time and end time, and 
number of time steps of interest (i.e., 500).
>>
>> Is that what you are looking for?
>>
>> alan
>>
>> -Original Message-
>> From: ParaView [mailto:paraview-boun...@paraview.org] On Behalf Of 
Huangrui Mo
>> Sent: Thursday, December 1, 2016 9:54 AM
>> To: paraview@paraview.org
>> Subject: [EXTERNAL] [Paraview] Time Synchronization for Case and 
Geometry Sequences
>>
>> Dear Paraview Developer,
>>
>> May you please help me with the following issue:
>>
>> Suppose when a solver writes data out, the field data is written in 
Ensight format, and the time sequence is streamed in "ensight.case".
>> Meanwhile, the geometry data is written in VTK format, and the time 
sequence is streamed in "paraview

Re: [Paraview] [EXTERNAL] Time Synchronization for Case and Geometry Sequences

[Moreland, Kenneth]

Actually, I think Sequence mode is more appropriate than Real Time mode in this 
case, but I too think that is the answer. 

To explain more what (we think) is going on: When you load data with time in 
ParaView, it goes to a Snap to Timesteps mode where it will visit each unique 
timestep once regardless of how far apart they are. Thus, ParaView is treating 
the numerical imprecision of the different times as unique time steps. If you 
switch to Sequence or Real Time mode, ParaView uses its own time units and will 
provide an even temporal spacing. 

There is more information about the different animation modes in the ParaView 
tutorial. 

-Ken

Sent from my iPad so blame autocorrect.

> On Dec 1, 2016, at 11:35 AM, Scott, W Alan  wrote:
> 
> Not sure if this is the correct answer, but try view/ animation View.  Then, 
> change the Mode to Real Time.  Enter your start time and end time, and number 
> of time steps of interest (i.e., 500).
> 
> Is that what you are looking for?
> 
> alan
> 
> -Original Message-
> From: ParaView [mailto:paraview-boun...@paraview.org] On Behalf Of Huangrui Mo
> Sent: Thursday, December 1, 2016 9:54 AM
> To: paraview@paraview.org
> Subject: [EXTERNAL] [Paraview] Time Synchronization for Case and Geometry 
> Sequences
> 
> Dear Paraview Developer,
> 
> May you please help me with the following issue:
> 
> Suppose when a solver writes data out, the field data is written in Ensight 
> format, and the time sequence is streamed in "ensight.case".
> Meanwhile, the geometry data is written in VTK format, and the time sequence 
> is streamed in "paraview.pvd".
> At last, let's assume the number of time sequences is 500.
> 
> Then, when loading into paraview, it does not synchronize the cases in a 
> perfect sense and would show up with 1000 cases. When animating, there is a 
> slight mismatch in time for the field data and geometry data. 
> However, if I use the VTK format for both the field and geometry data, then 
> paraview does a great job to synchronize the data sets.
> 
> Therefore, my question would be that is it possible to handle time 
> synchronization even for different formats?
> 
> Thank you very much for your time and help, Huangrui
> 
> --
> *
> Huangrui Mo, PhD Candidate
> Fluid Mechanics
> Department of Mechanical & Mechatronics Engineering University of Waterloo 
> Waterloo, Ontario N2L 3G1, Canada
> E-mail: huangrui...@uwaterloo.ca
> *
> 
> ___
> 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] Memory-saving method for data passing

[David Lonie]

Many VTK objects have a ShallowCopy method that does what you want. You can
shallow copy the entire datasets (which just copies pointers to data into a
new dataset container), or selectively copy e.g. points.

Datasets can easily share components. For instance, if you have two grids
that have the same points, you can do something like:

grid1->SetPoints(grid2->GetPoints());

and both grids will share the same vtkPoints object and its associated
memory buffers.

HTH,
Dave

On Thu, Dec 1, 2016 at 12:47 PM, Straub, Alexander <
inf76...@stud.uni-stuttgart.de> wrote:

> Good day,
>
> I am currently developping a bunch of plugins (filters) for Paraview in
> the following setup:
>
>
> I have input data as a rectilinear grid, including an array of scalar
> values per cell (volume-of-fluid data (vof)). On this data I now want to
> perform some calculations. First, a plugin calculates the gradient. Then,
> another plugin takes the grid with the vof-data and the gradients to
> calculate other vectors. This goes on for a few plugins.
>
> The problem I get is that every time another filter is applied onto the
> last one, I copy all the data and add another array with the filter's own
> results. Thus, the second filter stores its own calculation and the source
> data, the third filter stores its own calculation, the calculation of the
> previous plugin and the source data.
>
> You can see, that this results in a huge increase of memory usage.
>
> Now to my question: Is there a possibility or method which passes along a
> pointer, or a copy pointing to the input of the plugin to which I then only
> need to add another array? Additionally I might add that the grid itself
> always stays the same, only each filter appends another array.
>
> I hope you can help me, or at least quickly tell me if it is not possible
> at all.
>
> Kind regards,
> Alexander Straub
>
> ___
> 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] [EXTERNAL] Unable to rescale properly the color map

[Scott, W Alan]

Lugi,
I am fairly sure you are seeing this bug: 
https://gitlab.kitware.com/paraview/paraview/issues/16978.  It is scheduled to 
be fixed in an upcoming release, but the solution isn't trivial.  I will add 
your example to the bug.

Alan

From: ParaView [mailto:paraview-boun...@paraview.org] On Behalf Of Luigi R
Sent: Thursday, December 1, 2016 6:39 AM
To: paraview@paraview.org
Subject: [EXTERNAL] [Paraview] Unable to rescale properly the color map


Dear developers,



I'm loading a vtp file in Paraview 5.2 containing the agglomerated mesh and a 
scalar field (INT32) for the global cellID. The coarsest mesh has few cells 
characterized by a high identification number (cellID ranges from 160 to 
1600010]. Paraview is not able to rescale properly the range of the color map 
even with the custom data range and everything is displayed with a blue color 
and it becomes useless. Is there a way to change the precision for the color 
map.



I have also tested the version 5.0.1 which scales better but still cannot go 
below a certain range.



Please let me know.



Best regards,



Luigi

___
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] Unable to load binary or vplot files

[Martin Huarte Espinosa]

Dear Joachim: thanks for the help.


My best, Martín

On Wed, Nov 30, 2016 at 12:20 PM, Joachim Pouderoux <
joachim.pouder...@kitware.com> wrote:

> Hi Martin,
>
> Unfortunately there is no reader for this format in VTK/ParaView.
> Moreoever, VPL looks like a
> vector graphics format and there is no such similar reader in VTK. However
> it looks like
> Madagascar can convert them to raster format (PNG, JPEG etc).
>
> i) A way to go would be to develop a new C++ or Python reader for VPL that
> wiil on the fly convert them to a
> raster file and load them as a 2D image. As this is a animated file the
> reader will have to
> declare the number of frames in the animation as the number time steps of
> the data and then
> be able to provide the conversion of the frame requested by the pipeline.
>
> ii) Simpler : if conversion cannot be performed on the fly or if you can
> create a series of PNG/JPG files
> from Madagascar, you can just load them as a time series with ParaView
> (all files should be suffixed with the frame id (eg: frame0.png, frame1.png
> etc.)
> then in the Open File dialog of ParaView just select "frame*.png" item.
> Thus each file will be considered
> as a timestep of the time serie.
>
> Hope it is clear,
> Best
>
> *Joachim Pouderoux*, PhD
>
> *Technical Expert - Scientific Computing Team*
> *Kitware SAS *
>
>
> 2016-11-30 13:15 GMT-04:00 Martin Huarte Espinosa <
> martin.huar...@gmail.com>:
>
>> Dear Paraview enthusiasts: good day. We are trying to visualize
>> madagascar-created (http://www.ahay.org/wiki/Main_Page) data files using
>> paraview (4.3.1). These output files are either binaries or .vpl (
>> http://www.ahay.org/wiki/Tutorial#VPLOT). When using madagascar's viz
>> tool they look "like a movie"; 2D representation of a moving field. We are
>> however unable to visualize this using paraview but we really would like to.
>>
>> Has any of you encountered this problem? Any suggestions will be very
>> appreciated.
>>
>> Thank you very much.
>>
>> My best, Martín
>>
>>
>> *Martín Huarte-Espinosa, Ph.D.*
>> *Physicist *
>> *Expert Numerical Modeler and Code Developer*
>> *High Performance Computing Specialist*
>>
>> * 
>> *
>>
>>
>> ___
>> 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] Memory-saving method for data passing

[Straub, Alexander]

Good day,

I am currently developping a bunch of plugins (filters) for Paraview in the 
following setup:



I have input data as a rectilinear grid, including an array of scalar values 
per cell (volume-of-fluid data (vof)). On this data I now want to perform some 
calculations. First, a plugin calculates the gradient. Then, another plugin 
takes the grid with the vof-data and the gradients to calculate other vectors. 
This goes on for a few plugins.

The problem I get is that every time another filter is applied onto the last 
one, I copy all the data and add another array with the filter's own results. 
Thus, the second filter stores its own calculation and the source data, the 
third filter stores its own calculation, the calculation of the previous plugin 
and the source data.

You can see, that this results in a huge increase of memory usage.

Now to my question: Is there a possibility or method which passes along a 
pointer, or a copy pointing to the input of the plugin to which I then only 
need to add another array? Additionally I might add that the grid itself always 
stays the same, only each filter appends another array.

I hope you can help me, or at least quickly tell me if it is not possible at 
all.

Kind regards,
Alexander Straub

___
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] [EXTERNAL] Time Synchronization for Case and Geometry Sequences

[Scott, W Alan]

Not sure if this is the correct answer, but try view/ animation View.  Then, 
change the Mode to Real Time.  Enter your start time and end time, and number 
of time steps of interest (i.e., 500).

Is that what you are looking for?

alan

-Original Message-
From: ParaView [mailto:paraview-boun...@paraview.org] On Behalf Of Huangrui Mo
Sent: Thursday, December 1, 2016 9:54 AM
To: paraview@paraview.org
Subject: [EXTERNAL] [Paraview] Time Synchronization for Case and Geometry 
Sequences

Dear Paraview Developer,

May you please help me with the following issue:

Suppose when a solver writes data out, the field data is written in Ensight 
format, and the time sequence is streamed in "ensight.case".
Meanwhile, the geometry data is written in VTK format, and the time sequence is 
streamed in "paraview.pvd".
At last, let's assume the number of time sequences is 500.

Then, when loading into paraview, it does not synchronize the cases in a 
perfect sense and would show up with 1000 cases. When animating, there is a 
slight mismatch in time for the field data and geometry data. 
However, if I use the VTK format for both the field and geometry data, then 
paraview does a great job to synchronize the data sets.

Therefore, my question would be that is it possible to handle time 
synchronization even for different formats?

Thank you very much for your time and help, Huangrui

--
*
Huangrui Mo, PhD Candidate
Fluid Mechanics
Department of Mechanical & Mechatronics Engineering University of Waterloo 
Waterloo, Ontario N2L 3G1, Canada
E-mail: huangrui...@uwaterloo.ca
*

___
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] Time Synchronization for Case and Geometry Sequences

[Huangrui Mo]

Dear Paraview Developer,

May you please help me with the following issue:

Suppose when a solver writes data out, the field data is written in 
Ensight format, and the time sequence is streamed in "ensight.case".
Meanwhile, the geometry data is written in VTK format, and the time 
sequence is streamed in "paraview.pvd".

At last, let's assume the number of time sequences is 500.

Then, when loading into paraview, it does not synchronize the cases in a 
perfect sense and would show up with 1000 cases. When animating,
there is a slight mismatch in time for the field data and geometry data. 
However, if I use the VTK format for both the field and geometry data,

then paraview does a great job to synchronize the data sets.

Therefore, my question would be that is it possible to handle time 
synchronization even for different formats?


Thank you very much for your time and help,
Huangrui

--
*
Huangrui Mo, PhD Candidate
Fluid Mechanics
Department of Mechanical & Mechatronics Engineering
University of Waterloo
Waterloo, Ontario N2L 3G1, Canada
E-mail: huangrui...@uwaterloo.ca
*

___
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] Fwd: Segfault reading polyhedral cells xdmf3 file

[Armin Wehrfritz]

To follow up on this issue, I have done some more testing. From the link
below you can find two datasets with polyhedral cells, where one is
working just fine and the other one is crashing consistently when
opening it in ParaView 5.2.
The XDMF files are created form the respective .vtu files with ParaView
5.2 (Kitware binaries, Linux 64bit) using the Xdmf3 writer.

The strange thing is that the dataset leading to the seg fault is a
subset of the dataset that just works fine.

Here the link:
https://drive.google.com/file/d/0B5CHY8CFeTf2V09NVUhTRkpYSE0/view?usp=sharing

Alessandro, can you test these files and report back which ones are
working on your PC?

Thanks,
Armin







On 11/30/2016 08:19 PM, Alessandro De Maio wrote:

You're right: the polyhedral cells of the cube.vtu example do not
guarantee the planarity of faces, but this is a typical case of a
polyhedral mesh automatically generated starting from a tetrahedral one
(this example has been built using the Ansys-Fluent converter) and I
think it's quite a usual situation.
But I'm not sure this could generate a segfault as the problem could be
in the algorythms applied by Paraview after the reading of the file that
could consider this hypothesis (as you remarked), while the VTK
topological description of a polyhedral cell doesn't seem to need it,
and the reading phase should only build the data structure compliant
with VTK data representation, as actually happens for vtu file format.
But this is only my opinion and of course it could be wrong as I don't
have a deep knowledge of all the involved procedures.
My idea is that the problem could be due to a memory error, as it's only
unfrequent with a small case (by the way the one cell mesh you attached
can be read also on the windows machine although with a randomic
connectivity error as the one I showed in the image attached to the
previous message) but very frequent with a quite bigger case as the cube.
Is it possible to use something like valgrind to check for memory errors
in Paraview ?

On Wed, Nov 30, 2016 at 6:35 PM, Armin Wehrfritz mailto:dkxl...@gmail.com>> wrote:

In attach you can find the output of the saving of the
polyhedron.vtu
(saved.xmf and saved.h5) from the Windows machine.

OK, I tested the "saved.xmf" file and I can open it on my Linux machine
without issues. Also, I compared the files generated on windows and
linux machines, and the topology data is the same for both of them. The
datatype in the h5 file is different (H5T_STD_I32LE for the file from
the Windows machine vs. H5T_STD_I64LE for the file from the Linux
machine). The end of line in the xmf file is different, but I don't
think either one of them should cause an issue.

I've tried also to repeat the procedure (reading of your xmf
file) on a
Linux workstation and the behaviour is different: it seems that
randomically the crash happens again (once on about ten tries) and
sometimes it seems that the topology has a connectivity error
(see the
image in attachment), while for the most of the times it seems
to do the
right job.

As said, on my Linux machine it works consistently.

I've tried also another case, a little bit heavier: a polyhedral
mesh
read from the vtu in attach (cube.vtu) and saved with the Xdmf3
writer.
Trying to re-read the xmf version of this geometry always
produces a
crash also on the Linux machine.

I can confirm that the xmf file produce from the cube.vtu (using the
Xdmf3 writer in ParaView 5.2) leads consistently to seg fault.
However, even though the .vtu file works correctly, I'm not entirely
sure if this is xmf specific problem. To be more precise, the
implementation of polyhedral cells requires the face polygons to be
planar (see http://www.vtk.org/Wiki/VTK/Polyhedron_Support
). The example
file you send has a whole lot of faces that are not planar.

I extracted a single cell with several non-planar faces from your
example and saved it as .xmf file (attached). I can read this particular
file without issues on my Linux machine, whereas the original data file
leads to a seg fault. One reason why the cube.vtu file works and the
respective .xmf doesn't, could be related to the different approaches
polyhedral cells are stored in vtu and xdmf files, but debugging this
would require quite a bit of work...

Maybe somebody else has an idea here.

-Armin




___
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 subscrib

[Paraview] Unable to rescale properly the color map

[Luigi R]

Dear developers,


I'm loading a vtp file in Paraview 5.2 containing the agglomerated mesh and a 
scalar field (INT32) for the global cellID. The coarsest mesh has few cells 
characterized by a high identification number (cellID ranges from 160 to 
1600010]. Paraview is not able to rescale properly the range of the color map 
even with the custom data range and everything is displayed with a blue color 
and it becomes useless. Is there a way to change the precision for the color 
map.


I have also tested the version 5.0.1 which scales better but still cannot go 
below a certain range.


Please let me know.


Best regards,


Luigi

___
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] [EXTERNAL] Duplicate Layouts

[postgurke]

Hi Tobias

You could get the DisplayProperties of all your objects and then set them
accordingly in the new render window using the Python Shell. I have written a
short script for myself for this task --- however something is not quite
correct, as strange colorings sometimes appear after turning the model in the
second view. It can be fixed by making that object invisible and visible again,
but still Maybe someone more experienced can correct my answer in that
respect or has a better idea to tackle this problem...?

Here is my code:

rv1=GetActiveViewOrCreate('RenderView')
ALL=GetSources()

dispProps=list()
for i in range(len(ALL.keys())):
dispProps.append(GetDisplayProperties(ALL.values()[i]))

viewLayout1 = GetLayout()
viewLayout1.SplitHorizontal(0, 0.5)

rv2=CreateView('RenderView')
viewLayout1.AssignView(2, rv2)

SetActiveView(rv2)

for j in range(len(ALL.keys())):
SetDisplayProperties(ALL.values()[j],Visibility=dispProps[j].Visibility)

SetDisplayProperties(ALL.values()[j],ColorArrayName=dispProps[j].ColorArrayName[1])

SetDisplayProperties(ALL.values()[j],LookupTable=dispProps[j].LookupTable)

SetDisplayProperties(ALL.values()[j],DiffuseColor=dispProps[j].DiffuseColor)
SetDisplayProperties(ALL.values()[j],Scale=dispProps[j].Scale)

SetDisplayProperties(ALL.values()[j],Representation=dispProps[j].Representation)
SetDisplayProperties(ALL.values()[j],Texture=dispProps[j].Texture)



Cheers
Venke



> "Mondry, Tobias"  hat am 1. Dezember 2016 um 08:46
> geschrieben:
> 
> 
> Camera link is nice, but not what I want.
> 
> Example:
> - load a stl file
> - make a clip and use red as solid color
> - open a new view or layout
> 
> Now it would be useful to have the same "image" in the new view or layout:
> - the clip is in show
> - the clipped geometry has the color red
> 
> It's like a copy and paste of all settings of a view.
> 
> 
> Tobias
> 
> 
> Von: Scott, W Alan [wasc...@sandia.gov]
> Gesendet: Mittwoch, 30. November 2016 18:48
> An: Mondry, Tobias; paraview@paraview.org
> Betreff: RE: [EXTERNAL] [Paraview] Duplicate Layouts
> 
> You mean link the cameras for two views?  Right click on the background, then
> left click in the other view.
> 
> Alan
> 
> From: ParaView [mailto:paraview-boun...@paraview.org] On Behalf Of Mondry,
> Tobias
> Sent: Wednesday, November 30, 2016 8:39 AM
> To: paraview@paraview.org
> Subject: [EXTERNAL] [Paraview] Duplicate Layouts
> 
> Hi,
> 
> do you know a way to duplicate a Layout, in GUI or python?
> This would be useful when you want to have different Layouts with slightly
> different color bar settings, for example.
> 
> Kind regards
> 
> Tobias
> 
> 
> Pfinder KG
> Rudolf-Diesel-Strasse 14
> 71032 Böblingen / Germany
> Telefon: + 49 (7031) 27 01 0 / Telefax: + 49 (7031) 28 05 00 / Internet:
> www.pfinder.de
> Handelsregister: Amtsgericht Stuttgart, Registergericht HRA 240702
> 
> Diese E-Mail kann Betriebs- und Geschäftsgeheimnisse oder sonstige
> vertrauliche und /oder rechtlich geschützte Informationen enthalten. Sollten
> Sie diese eMail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des
> Inhalts, eine Vervielfältigung oder Weitergabe der eMail ausdrücklich
> untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die eMail. Der
> Absender hat alle erdenklichen Vorsichtsmaßnahmen getroffen, dass die Anlagen
> dieser eMail frei von Computerviren o.ä. sind. Gleichwohl schließen wir die
> Haftung für jeden Schaden aus, der durch Computerviren o.ä. verursacht wurde,
> soweit wir nicht vorsätzlich oder grob fahrlässig gehandelt haben. Wir raten
> Ihnen, dass Sie in jedem Fall Ihre eigene Virenprüfung vornehmen, bevor Sie
> die Anlagen öffnen. Vielen Dank !
> 
> The information contained in this email message may be confidential, and may
> also be the subject of legal professional privilege. If you are not the
> intended recipient, any use, interference with, disclosure or copying of this
> material is unauthorised and prohibited. Please inform us immediately and
> destroy the email. We have taken every reasonable precaution to ensure that
> any attachment to this email has been swept for viruses. However, we cannot
> accept liability for any damage sustained as a result of software viruses and
> would advise that you carry out your own virus checks before opening any
> attachment. Thank you for your cooperation !
> 
> 
> Pfinder KG
> Rudolf-Diesel-Strasse 14
> 71032 Böblingen / Germany
> Telefon: + 49 (7031) 27 01 0 / Telefax: + 49 (7031) 28 05 00 / Internet:
> www.pfinder.de
> Handelsregister: Amtsgericht Stuttgart, Registergericht HRA 240702
> 
> Diese E-Mail kann Betriebs- und Geschäftsgeheimnisse oder sonstige
> vertrauliche und /oder rechtlich geschützte Informationen enthalten. Sollten
> Sie diese eMail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des
> Inhalts, eine Verviel