[Paraview] Bug in Color Scale
Hi there, I just upgraded my paraview from 3.10 to 3.40. Immediately I found that the same data was not colored correctly with the new version. It turned out that in the Display Tab, Rescale to Data Range button actually does nothing. If I clicked on Edit Color Map.., I found that the maximum of data range is always 1 (minimum always 0), no matter what the real range is. I can of course uncheck Automatically Rescale to Fit Data Range, and set the range using Rescale Range button by hand. However, I think this is not what it is supposed to be. I tried both the Linux-64bit binary found online and my own build on an ubuntu box and they have the same problem. Please let me know if it is indeed a bug or just something I didn't get right. Thanks a lot. Thanks a lot. Shi ___ ParaView mailing list ParaView@paraview.org http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] Bug in Color Scale
Thank you Ken.
This is really strange then. I just downloaded the 32-bit version for Linux and
had the same problems. It sounds like a problem of my linux box.
By the way, I did change the color map to HSV earlier but I am sure I didn't
change anything else. And the new 32bit binary, I didn't do anything to it and
still get the [0,1] range. I guess I have to use some other machines to see
the problems.
Thank you for your quick response and I will keep you updated on my findings.
Shi
From: "Moreland, Kenneth" <[EMAIL PROTECTED]>
To: Shi Jin <[EMAIL PROTECTED]>; "paraview@paraview.org"
Sent: Tuesday, November 25, 2008 12:27:47 PM
Subject: Re: [Paraview] Bug in Color Scale
Re: [Paraview] Bug in Color Scale Nope. I still can’t replicate the problem.
I downloaded the binary you specify, loaded the data set you sent, and it set
the range fine.
I notice from the image you sent that the color bar does not have the default
colors. Are you sure that you are actually using the version of ParaView you
downloaded as opposed to another version that might be in your path? Earlier
versions of ParaView used that rainbow scalar bar as a default. Either that or
you have been playing with color scale editor dialog box. In that case, you
may have accidently changed the range without realizing it.
-Ken
On 11/25/08 9:35 AM, "Shi Jin" <[EMAIL PROTECTED]> wrote:
Hi Ken,
Thank you. I have attached my sample data file and a screenshot taken under
paraview-3.4.0 under 64bit Linux.
Just now I tried the Windows version and it seems to be working fine. So I
guess this is a problem only found in the Linux version. By looking at the
range for the variable Rank in the information panel, we can see it is [3,3]
however the color displays only for range [0,1].
Please let me know if you can reproduce this problem on Linux. The binary I
used is paraview-3.4.0-Linux-x86_64.
Thanks a lot.
Shi
________
From:"Moreland, Kenneth" <[EMAIL PROTECTED]>
To: Shi Jin <[EMAIL PROTECTED]>; "paraview@paraview.org"
Sent: Tuesday, November 25, 2008 7:50:42 AM
Subject: Re: [Paraview] Bug in Color Scale
Re: [Paraview] Bug in Color Scale Shi,
I have not run into this, nor have I heard of anyone else who has. Could you
tell us more about your data or, better yet, send us an example?
One thing that has changed with the rescale range feature recently is that the
range is now computed based on the values that appear throughout an entire
volume, not just what appears on the surface. Thus, if you are rendering a
volume of data with 1 in the middle but with the surface only having up to
0.01, the range is still going to be up to 1. Check the ranges in the
Information panel. The scalar bar range should agree with that. If you don’t
know where the upper values are located, try using the threshold filter to find
them.
-Ken
On 11/24/08 8:24 PM, "Shi Jin" <[EMAIL PROTECTED]> wrote:
Hi there,
I just upgraded my paraview from 3.10 to 3.40. Immediately I found that the
same data was not colored correctly with the new version. It turned out that in
the Display Tab, Rescale to Data Range button actually does nothing. If I
clicked on Edit Color Map.., I found that the maximum of data range is always 1
(minimum always 0), no matter what the real range is. I can of course uncheck
Automatically Rescale to Fit Data Range, and set the range using Rescale Range
button by hand. However, I think this is not what it is supposed to be. I
tried both the Linux-64bit binary found online and my own build on an ubuntu
box and they have the same problem. Please let me know if it is indeed a bug
or just something I didn't get right. Thanks a lot.
Thanks a lot.
Shi
___
ParaView mailing list
ParaView@paraview.org
http://www.paraview.org/mailman/listinfo/paraview
Kenneth Moreland
*** Sandia National Laboratories
***
*** *** *** email: [EMAIL PROTECTED]
** *** ** phone: (505) 844-8919
*** web: http://www.cs.unm.edu/~kmorel
<http://www.cs.unm.edu/%7Ekmorel>
Kenneth Moreland
*** Sandia National Laboratories
***
*** *** *** email: [EMAIL PROTECTED]
** *** ** phone: (505) 844-8919
*** web: http://www.cs.unm.edu/~kmorel
___
ParaView mailing list
ParaView@paraview.org
http://www.paraview.org/mailman/listinfo/paraview
[Paraview] File Format for Particles
Hi there, I am doing a simulation of fluid-particle interactions, in which I generate a lot of data for particles. I am looking for the efficient file format to store my particle information for visualization with paraview. For example, is there a file format that allows me to store all the particle information at a given time in a single ascii file, which looks like #1-id 2-radius 3-rho_p 4-fixed 5-x 6-y 7-z 8-u 9-v 10-z 11-w1 12-w2 13-w3 14-alpha 15-theta 17-phi 0 0.50 1.20 0 2.077176 2.678227 8.649375 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1 0.50 0.800 0 2.728281 0.873571 6.806029 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 ... I guess for the purpuse of visualization, we need radius, rho_p(for color), x,y and z at least. The rotation information would be nice to have but is considered optional at this stage. I am thinking to save different time results in different files to make the loading efficient in terms of memory since I have a lot of particles here. Then we can produce animation using time control. I guess we could use VTK formats but that has lots of redundant information. I saw some very early discussion on a similar topic in the forum but didn't get the conclusive answer. I would appreciate some advice for the current version of paraview. Thank you very much. -- Shi Jin, PhD ___ ParaView mailing list ParaView@paraview.org http://www.paraview.org/mailman/listinfo/paraview
Re: [Paraview] File Format for Particles
Thank you Bryn and Ivo. I agree binary format is more efficient. But I am reluctant to do that because of the issue of portability. I may run the code on both Linux clusters and IBM machines. My earlier experience shows me that the binary files on the two system are not compatible, i.e., I cannot load the data generated on a IBM machine on a Linux system. Does the little/big endian parameter solve this problem in paraview? Thanks. Shi - Original Message > From: Bryn Lloyd <[EMAIL PROTECTED]> > To: Ivo Roghair <[EMAIL PROTECTED]> > Cc: Shi Jin <[EMAIL PROTECTED]>; paraview@paraview.org > Sent: Friday, November 28, 2008 12:17:39 AM > Subject: Re: [Paraview] File Format for Particles > > Hi Shi, > > Yes, for large amounts of data you should use the binary (not ascii) formats. > It > is very simple to switch between ascii/binary. In the writer classes (e.g. > vtkPolyDataWriter) you can usually call the function SetFileTypeToBinary() or > SetFileTypeToASCII(). > > > An unstructured grid can of course be used to visualize your data in > paraview. > Since you not have cells (tetrahedra, hexahedra, etc.) a vtkPolyData data > structure and associated file type might be better, since it uses slightly > less > storage and if you add the points as "Verts" Paraview will automatically > display > them using glyphs (sphere,arrow,..) > > File formats are described here: > http://www.vtk.org/pdf/file-formats.pdf > > > --Bryn > > > > > > Ivo Roghair wrote: > > Hi Shi, > > > > Saving such amounts of data in ascii format is not going to be efficient. > > We > just accepted this fact, otherwise we should go to binary formats. > > > > In our group we have discrete particle simulations, and we export vtk files > (xml format -- an unstructured grid to be precise) that contains all the > particle data. I have included an example of such a file below. You write the > point positions of the particles first, followed by data concerning the > movement > of the particle, the diameter and other stuff like rotation, temperature, > etc... > I don't see what you mean by redundant data. When you load this file into > Paraview choose the glyph option, choose 'sphere', set 'radius' to 1 (it is > initially set to 0.5), scale mode to 'scalar' and scale factor to 1. You can > then draw the particles. You can color them by velocity, temperature, > rotation > or whatever you included in the file, or you can choose to show arrows > (another > glyph) to display the particle movement. > > For the flow field, which is calculated on a structured grid, you can use > another file format, e.g. rectilinear grid. In all cases the kitware/vtk file > formats documentation is going to be useful. > > > > Regards, > > Ivo Roghair > > > > PhD student at Fundamentals of Chemical Reaction Engineering > > University of Twente, The Netherlands > > > > -- BEGIN EXAMPLE FILE - > > > > > > > > > > > format="ascii"> > >0 0 0 1 1 1 0 0 1 > > > > > > > > > format="ascii"> > >4 4 4 4 0 0 2 2 -2 > > > > > >0.1 0.5 1 > > > > > >273 300 350 > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- END EXAMPLE FILE -- > > > > Shi Jin wrote: > >> Hi there, > >> > >> I am doing a simulation of fluid-particle interactions, in which I > >> generate a > lot of data for particles. I am looking for the efficient file format to > store > my particle information for visualization with paraview. For example, is > there a > file format that allows me to store all the particle information at a given > time > in a single ascii file, which looks like > >> #1-id 2-radius 3-rho_p 4-fixed 5-x 6-y 7-z 8-u 9-v 10-z 11-w1 12-w2 13-w3 > 14-alpha 15-theta 17-phi > >> 0 0.50 1.20 0 2.077176 2.678227 8.649375 0.00 0.00 > >> 0.00 > 0.00 0.00 0.00 0.00 0.00 > >> 1 0.50 0.800 0 2.728281 0.873571 6.806029 0.00 0.00 0.00 > 0.00 0.00 0.00 0.00 0.00 > >> ... > >> > >> I guess for the purpuse of visualization, we need radius, rho_p(for > >> color
[Paraview] redundant information in the VTK XML file format
Hi there, I have been using the VTK XML unstructured grid format (pvtu and vtu) for my fluid dynamics simulations. It worked fairly well with paraview but I think it stores a lot of redundant information and I am wondering if there is a way to simplify it. 1. My grid is fixed once created. I am dumping velocity and pressure field at many steps but in each vtu file, I have to have the same grid information such as vertex positions, cell connectivity, offset and cell type. What I would love to have is to dump the grid at the beginning of the simulation and then only dump the field of velocity and pressure at later time steps. To make it work, we need a way to include the grid information stored in another file, just like the #include statement in C++ or \input in Latex. 2. All my cells are of the same type (10-vertex Tetrahedron in my case). So the "types" are the same constant 10 and "offsets" are constant increments. What is now in my file are long lists of these boring numbering for each cell, which I would love to have a way to get rid of. I would appreciate any help. Thanks. Shi ___ ParaView mailing list ParaView@paraview.org http://www.paraview.org/mailman/listinfo/paraview
