[d_ray]

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.

[wyldckat]

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

[d_ray]

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:

   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

[wyldckat]

Hi Deep,

Originally Posted by d_ray

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.

Originally Posted by d_ray

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:

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

[d_ray]

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

[wyldckat]

Hi Deep,

I'm glad I managed to guide you in the right direction!

Originally Posted by d_ray

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

[d_ray]

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

[wyldckat]

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

[alimalik]

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:

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:

 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.

[wyldckat]

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

[karlvirgil]

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;

[SAE]

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

[TomášOberhuber]

Hello,

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

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