CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Visualization & Post-Processing Software > ParaView

[General] Error while reading VTK files in Paraview

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree2Likes
  • 2 Post By karlvirgil

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   July 24, 2014, 08:38
Default Error while reading VTK files in Paraview
  #1
New Member
 
Deep Ray
Join Date: Jan 2014
Posts: 6
Rep Power: 12
d_ray is on a distinguished road
I have been getting the following error while opening a .vtk file in Paraview:

"Error reading ascii data. Possible mismatch of datasize with declaration."

I am running a simulation on my Mac OS X 10.9.3, and saving my solution files in .vtk format. While the first few solution files (unsteady flow) opens perfectly, the above error occurs from a particular file onwards. Moreover, some of my scalar variables disappear from the data-set in Paraview. I tried opening the file on my friends laptop, which has a linux OS, and Paraview opens all the files correctly with all variables in place. I noticed a similar problem while using VisIT.

I have even tried to use different versions of Paraview but the problem persists. Could there be a problem with the vtkreader? Any help or leads to solving this issue will be much appreciated.
d_ray is offline   Reply With Quote

Old   July 26, 2014, 11:14
Default
  #2
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,980
Blog Entries: 45
Rep Power: 128
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
Greetings Deep Ray and welcome to the forum!

My guess is that if your VTK file is in ASCII, then it could be a problem due to the character used for the line ending: http://en.wikipedia.org/wiki/Newline
In a nutshell:
  • On Windows, line transition is with CR+LF.
  • On Linux, line transition is with LF only.
  • On Mac, some older versions used CR only. Nowadays I guess it should use LF as well.
CR= "Carriage Return" byte
LF= "Line Feed" byte


Therefore, my question back to you is this: how was your VTK file saved in the first place? Because the solution might be on the side of how the file was saved.

On the the other hand, if the VTK file is really fully in ASCII, then you can try converting the new line format for the file, either using an advanced text/code editor or using sed.

Best regards,
Bruno
wyldckat is offline   Reply With Quote

Old   July 26, 2014, 12:25
Default
  #3
New Member
 
Deep Ray
Join Date: Jan 2014
Posts: 6
Rep Power: 12
d_ray is on a distinguished road
First of all, thank you for your reply Bruno. I have been facing this problem for 6 months now and this is the first positive feedback I have received. As you have mentioned, the solution could lie in understanding whether I am using the correct form of line ending.

Below is a snippet of the C++ code I am using to save solutions in a vtk file:
Code:
   ofstream vtk;
   vtk.open (filename.c_str());

   vtk << "# vtk DataFile Version 3.0" << endl;
   vtk << "flo3d" << endl;
   vtk << "ASCII" << endl;
   vtk << "DATASET UNSTRUCTURED_GRID" << endl;
   vtk << "POINTS  " << grid->n_vertex << "  float" << endl;

   for(unsigned int i=0; i<grid->n_vertex; ++i)
      vtk << grid->vertex[i].coord.x << " " 
          << grid->vertex[i].coord.y << " " 
          << grid->vertex[i].coord.z << endl;

   vtk << "CELLS  " << grid->n_cell << " " << 4 * grid->n_cell << endl;
   for(unsigned int i=0; i<grid->n_cell; ++i)
      vtk << 3 << "  " 
          << grid->cell[i].vertex[0] << " "
          << grid->cell[i].vertex[1] << " "
          << grid->cell[i].vertex[2] << endl;

   vtk << "CELL_TYPES  " << grid->n_cell << endl;
   for(unsigned int i=0; i<grid->n_cell; ++i)
      vtk << 5 << endl;

   // Write vertex data
   if(vertex_data.size() > 0 || has_conserved) 
      vtk << "POINT_DATA  " << grid->n_vertex << endl;

   // If vertex conserved data is available, write to file
   if (has_conserved)
   {
      vtk << "SCALARS convar float 1" << endl;
      vtk << "LOOKUP_TABLE default" << endl;
      for(unsigned int i=0; i<grid->n_vertex; ++i)
         vtk << (*vertex_conserved)[i] << endl;
   }

   vtk.close ();
The obvious question would be whether using "endl" would be sufficient for Unix systems, or would one need to use something like '\n'?

However, as I had mentioned earlier, the first few solution files have no problems whatsoever. It is only after a certain point the the files start misbehaving. If the incorrect line ending usage is the reason behind all this, would it not have occurred in all the solution files?

Best,
Deep

Last edited by wyldckat; July 27, 2014 at 07:08. Reason: Added [CODE][/CODE]
d_ray is offline   Reply With Quote

Old   July 27, 2014, 08:07
Default
  #4
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,980
Blog Entries: 45
Rep Power: 128
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
Hi Deep,

Quote:
Originally Posted by d_ray View Post
The obvious question would be whether using "endl" would be sufficient for Unix systems, or would one need to use something like '\n'?
You might want to try replacing endl with "\r\n" or just "\r" or just "\n", but endl is meant to do this automatically for you in the system you're working on.

Quote:
Originally Posted by d_ray View Post
However, as I had mentioned earlier, the first few solution files have no problems whatsoever. It is only after a certain point the the files start misbehaving. If the incorrect line ending usage is the reason behind all this, would it not have occurred in all the solution files?
Mmm... I didn't fully notice that particular detail in your description. Then there are at least a few other possibilities:
  1. There might be one or more values that are of type NaN or Inf or some other special computational numeric definition for non-real numbers. They might be readable on Linux, but not on Mac, perhaps of the next possibility.
  2. Location based numeric definitions, aka Locale, might be triggering situations where values are being stored with commas or with a strange scientific notation. For example, if a value "1.0002" is stored as "1,0002" or even perhaps "1.0002ES+000" (just a possibility).
If the files are in ASCII, then try opening them with a text editor and look for one or more of the occurrences above.
If it's the situation #2, then you might try the trick that works on Linux, by running ParaView like this:
Code:
export LC_ALL=C
paraview
This will should ensure that ParaView will use the standard scientific notation... then again, it might be your application that needs to abide to the standard scientific notation.


And looking at the source code, there is an "if" that is worrying me, namely the one with the comment "Write vertex data", specially because the "vertex_data" variable appears only once in the code you've shown.

Best regards,
Bruno
wyldckat is offline   Reply With Quote

Old   July 30, 2014, 09:08
Default
  #5
New Member
 
Deep Ray
Join Date: Jan 2014
Posts: 6
Rep Power: 12
d_ray is on a distinguished road
Hi Bruno,

I tried all options that you suggested but the problem persisted. I manually tried checking for Locale problems or the appearance of Nan etc, but everything seemed in place.

However, I noticed that some of the stored solution values were as small as 10.e-34. I had a feeling that the underflow conditions maybe be triggering problems while reading. I put a check in my code for underflow conditions and rounded them off to 0. This fixed the issue, with the solution being displayed at all times without error messages. This is true on both Visit and Paraview. I wonder if there are any local setting in Paraview that can change the data range limits?

Thanks for all your help. I'll be sure to forward the solutions to a few other forums where people have faced similar issues.

Best,
Deep
d_ray is offline   Reply With Quote

Old   August 4, 2014, 12:54
Default
  #6
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,980
Blog Entries: 45
Rep Power: 128
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
Hi Deep,

I'm glad I managed to guide you in the right direction!
Quote:
Originally Posted by d_ray View Post
However, I noticed that some of the stored solution values were as small as 10.e-34. I had a feeling that the underflow conditions maybe be triggering problems while reading. I put a check in my code for underflow conditions and rounded them off to 0. This fixed the issue, with the solution being displayed at all times without error messages. This is true on both Visit and Paraview. I wonder if there are any local setting in Paraview that can change the data range limits?
"10.e-34"... that's sounds like an issue related to numerical precision, probably related to using "float" instead of "double" or "float64" in the VTK file format.
Although it's a bit strange, because the smallest value for float should be 10e-38, if I'm not mistaken.

I can't test this right now, but as I mentioned a few lines above, you can also try using "double" or "float64" instead of "float" for the arrays in the VTK file.
If you search online for "VTK file format", you should find some more information about this, although testing this might be easier.

Best regards,
Bruno
wyldckat is offline   Reply With Quote

Old   August 5, 2014, 18:32
Default
  #7
New Member
 
Deep Ray
Join Date: Jan 2014
Posts: 6
Rep Power: 12
d_ray is on a distinguished road
Hi Bruno,

I tried changing the format type to "double" and "float36", but I get the same issue as before. In fact, after carefully analysing the solution files, I found some of the entries of the order of 1.0e-40. So that might explain it.

But as I mentioned before, rounding off the values to 0 does the trick.

Best,
Deep
d_ray is offline   Reply With Quote

Old   August 16, 2014, 13:10
Default
  #8
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,980
Blog Entries: 45
Rep Power: 128
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
Hi Deep,

I've tested this now on Ubuntu and if you replace all type entries from "float" to "double", it should be possible for ParaView to load the VTK file with double precision and the smallest supported value should be something like "1.0e-308".

On the other hand, if that doesn't work, it's possible that the ParaView build you're using on Mac OS X is not able to read double values properly.

Best regards,
Bruno
wyldckat is offline   Reply With Quote

Old   December 20, 2015, 23:54
Default
  #9
New Member
 
Ahmad Ali
Join Date: Jun 2015
Posts: 2
Rep Power: 0
alimalik is on a distinguished road
Hello guys,

I am facing same king of problem when I run my fortran code and when I try tp load output VTK files on Paraview.
When I run my fortran code and when I try to load output VTK files on Paraview, I get error:
Code:
In  C:\DBD\pvs-x64\paraview\src\paraview\VTK\IO\Legacy\vtkDataReader.cxx,  line 1359
Error reading ascii data. Possible mismatch of datasize with declaration.
I tried Double and float 64, float but error persists. Can you please suggest any other solution?

here is output module:

Code:
 module output_vtk_m
  use parameters_m ; use variables_m
  use velo_grid_m
  implicit none
  contains
subroutine output_vtk_rectilinear(KT,KFILE)                                                !M140625a
  integer, intent(in)         ::  KT,KFILE
  integer                     :: i, j, is, js, num
  real*8,dimension(0:mx,0:my) :: wlg, hg, u, v
  real*8,dimension(1:lx,1:ly,1:idd,1:jdd) :: wltree
  character*4                 :: anum
  character*50                :: dvtk
!
  do j = 1, ly
  do i = 1, lx
    do js = 1, jdd
    do is = 1, idd
      wltree(i,j,is,js) = wl(i,j)
    end do
    end do
  end do
  end do
!
  call tree_to_struct( hs    , hg , lx, ly, idd, jdd, mx, my )
  call tree_to_struct( wltree, wlg, lx, ly, idd, jdd, mx, my )
! call tree_to_struct( zb    , zg , lx, ly, idd, jdd, mx, my )
  call velo_grid(      u , v )
!
  num = KT/KFILE
  write( anum(1:4) , '(i4)' ) num
  do i = 1, 4
    if( anum(i:i)==' ' ) anum(i:i)='0'
  end do
  DVTK = trim(cwrite)//anum//'.vtk'
!
  OPEN( 30, FILE = trim(DVTK), STATUS='UNKNOWN')                                           !VTK FILE
  Write(30,'(a26)') '# vtk DataFile Version 2.0'
  Write(30, *     ) 't=', dt*dble(kt),'(sec)', ' dt=', dt, '(sec)'
  Write(30,'(a5)' ) 'ASCII'
  WRITE(30,'(a24)') 'DATASET RECTILINEAR_GRID'
  write(30,'(a10,3i9)'  ) 'DIMENSIONS', mx+1, my+1, 1
!
  write(30,'(a13,i9,a6)') 'X_COORDINATES', mx+1, ' float64'
    do i = 0, mx
      write(30,'(e15.7)') xgs(i)
!!      write(30,'(f12.8)') xgs(i)
    end do
  write(30,'(a13,i9,a6)') 'Y_COORDINATES', my+1, ' float64'
    do j = 0, my
      write(30,'(e15.7)') ygs(j)
!!      write(30,'(f12.8)') ygs(j)
    end do
  write(30,'(a13,i9,a6)') 'Z_COORDINATES', 1  , ' float64'
      write(30,'(e15.7)') 1.d0
!
  write(30,*)
!
  write(30,'(a10,i10)') 'point_data', (mx+1)*(my+1)
  write(30,'(a17)'    ) 'scalars h float64 1'
  write(30,'(a20)'    ) 'lookup_table default'
    do j = 0, my
    do i = 0, mx
!!    write(30,'(e15.7)') hg(i,j)
      write(30,'(f12.8)') hg(i,j)                                                          !E140628c
!!    write(*,*) 'hg write',i,j,hg(i,j) ; pause
    end do
    end do
!
!write(30,'(a10,i10)') 'point_data', ix*iy*iz
  write(30,'(a18)'    ) 'scalars wl float64 1'
  write(30,'(a20)'    ) 'lookup_table default'
    do j = 0, my
    do i = 0, mx
!!!   write(30,'(e15.7)') wlg(i,j)
      write(30,'(f12.8)') wlg(i,j)
    end do
    end do
!
!write(30,'(a10,i10)') 'point_data', ix*iy*iz
  write(30,'(a18)'    ) 'scalars zb float64 1'
  write(30,'(a20)'    ) 'lookup_table default'
    do j = 0, my
    do i = 0, mx
      write(30,'(f12.8)') zgs(i,j)
    end do
    end do
!
!write(30,'(a10,i10)') 'point_data', (ix+1)*(iy+1)*(iz+1)
  write(30,'(a18)'    ) 'vectors velo float64'
    do j = 0, my
    do i = 0, mx
      write(30,'(3f12.8)') u(i,j), v(i,j), 0.d0
    end do
    end do
  close(30)                                                                                !E140628d
end subroutine output_vtk_rectilinear
end module     output_vtk_m
Waiting for your kind reply and suggestions.

Last edited by wyldckat; December 29, 2015 at 10:39. Reason: merged posts that were a few minutes apart
alimalik is offline   Reply With Quote

Old   December 29, 2015, 10:48
Default
  #10
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,980
Blog Entries: 45
Rep Power: 128
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
Greetings Ahmad,

It would make it a lot easier if you could either provide an example VTK file or the part of the code for using the module Otherwise I don't know it will take me to create a working version of your code

I ask this because I don't know for certain if ParaView/VTK fully supports 64-bit values in the VTK file format. And the error message isn't clear on the origin of error. It might even be due to a problem with the interpretation of the decimal separator.

Best regards,
Bruno
wyldckat is offline   Reply With Quote

Old   April 11, 2016, 20:20
Default
  #11
New Member
 
karlvirgil's Avatar
 
Join Date: Jul 2009
Location: Wrentham, MA
Posts: 9
Rep Power: 17
karlvirgil is on a distinguished road
Occasionally, when trying to open an OpenFOAM generated, ascii formatted, vtk file in ParaView 5.0.0, the following error will occur:

“Error when reading ascii data. Possible mismatch of datasize with declaration.”

The problem can be fixed by using "double" in the vtk header instead of "float", as mentioned above. Changing this line of the code in surfaceFormats/vtk/VTKsurfaceFormatCore.C fixes the issue for future output

45 os << “POINTS " << pointLst.size() << " double" << nl;
wyldckat and Zbynek like this.
karlvirgil is offline   Reply With Quote

Old   November 22, 2017, 08:20
Default Can not open my vtk file with paraview
  #12
SAE
New Member
 
Sab Sea
Join Date: Nov 2017
Posts: 1
Rep Power: 0
SAE is on a distinguished road
I have created the attached file with a Matlab script but can not open it with paraview.
Please help in debugging./

https://drive.google.com/file/d/1frf...ew?usp=sharing

Regards,

Sab
SAE is offline   Reply With Quote

Old   January 24, 2018, 08:00
Default
  #13
New Member
 
Tomáš Oberhuber
Join Date: Jan 2018
Posts: 1
Rep Power: 0
TomášOberhuber is on a distinguished road
Hello,

I am having similar problem. Paraview does not accept my vtk file and I cannot find out why? The file looks as follows.

Code:
# vtk DataFile Version 2.0
TNL DATA
ASCII
DATASET UNSTRUCTURED_GRID
POINTS 25 double
0 0 0
0.0297674 0 0
0.0595349 0 0
0.0893023 0 0
0.11907 0 0
0 0.005 0
0.0297674 0.005 0
0.0595349 0.005 0
0.0893023 0.005 0
0.11907 0.005 0
0 0.01 0
0.0297674 0.01 0
0.0595349 0.01 0
0.0893023 0.01 0
0.11907 0.01 0
0 0.015 0
0.0297674 0.015 0
0.0595349 0.015 0
0.0893023 0.015 0
0.11907 0.015 0
0 0.02 0
0.0297674 0.02 0
0.0595349 0.02 0
0.0893023 0.02 0
0.11907 0.02 0

CELLS 16 80
4 0 1 5 6
4 1 2 6 7
4 2 3 7 8
4 3 4 8 9
4 5 6 10 11
4 6 7 11 12
4 7 8 12 13
4 8 9 13 14
4 10 11 15 16
4 11 12 16 17
4 12 13 17 18
4 13 14 18 19
4 15 16 20 21
4 16 17 21 22
4 17 18 22 23
4 18 19 23 24

CELL_TYPES 16
8 
8 
8 
8 
8 
8 
8 
8 
8 
8 
8 
8 
8 
8 
8 
8 

CELL_DATA 16
VECTORS cellVectorFieldValues double
LOOKUP_TABLE default
6.92918 6.92918 0
6.92918 6.92918 0
0 0 0
0 0 0
0 0 0
0 0 0
0 0 0
0 0 0
0 0 0
0 0 0
0 0 0
0 0 0
0 0 0
0 0 0
0 0 0
0 0 0
The message is:

"Error reading ascii data. Possible mismatch of datasize with declaration."

Thank you for any help you could give me.

Tomas.
TomášOberhuber is offline   Reply With Quote

Reply

Tags
paraview, vtk

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
[General] Reading binary VTK files from Octave/Matlab/Python well_well ParaView 0 August 8, 2017 12:39
[General] Converge files in to paraview kri321shna ParaView 1 April 9, 2017 00:05
''unknown radialModelType type Gidaspow'' PROBLEM WITH THE BED TUTORIAL AndoniBM OpenFOAM Running, Solving & CFD 2 March 25, 2015 18:44
OF 1.6 | Ubuntu 9.10 (64bit) | GLIBCXX_3.4.11 not found piprus OpenFOAM Installation 22 February 25, 2010 13:43
[General] Iblanked Plot3d files in Paraview Robert ParaView 0 September 27, 2006 15:45


All times are GMT -4. The time now is 22:30.