CODEWITHSUNDEEP
vtkparaview
Stershic
Stershic

Reputation: 191

Paraview "possible mismatch of datasize with declaration" error

Paraview (v4.1.0 64-bit, OSX 10.9.2) is giving me the following error:

Generic Warning: In /Users/kitware/Dashboards/MyTests/NightlyMaster/ParaViewSuperbuild-Release/paraview/src/paraview/VTK/IO/Legacy/vtkDataReader.cxx, line 1388 Error reading ascii data. Possible mismatch of datasize with declaration.

I'm not sure why. I've double-checked that fields are all of the expected lengths, and none of the values are NaN, inf, or otherwise extremely large. The issue starts with the output from timestep 16 (0-15 produces no error). Graphically, steps 0-15 produce plots of my data as expected; step 16 shows the "Y/Yc" series having an unexpectedly large point (0.5625, 2.86616e+36).

Is fine: http://www.filedropper.com/ring0000015

Produces error: http://www.filedropper.com/ring0000016

Upvotes: 3

Views: 4768

Answers (3)

Stershic
Stershic

Reputation: 191

This may not fix the Inf/NaN problems, but if the numbers in the vtk file are too large or too small (i.e. 1e-50, 1e45), this may cause the same error.

One solution in this case is to change the datatype specification. When I had this problem, I specified the datatype as "float", which uses a 32-bit floating point representation (same as "float32"). Changing it to "float64" uses a 64-bit double-precision representation, which is consistent with my C++ code that generated the vtk file that uses doubles. This may eliminate the problem.

Upvotes: 1

rayd
rayd

Reputation: 102

I have been facing the same problem for the last 6 months and been struggling to find a solution. I was given the following reasons to explain the error(http://www.cfd-online.com/Forums/paraview/139451-error-while-reading-vtk-files-paraview.html#post503315):

  1. It could be a problem due to the character used for the line ending (http://en.wikipedia.org/wiki/Newline) In a nutshell: a)On Windows, line transition is with CR+LF. b)On Linux, line transition is with LF only. c)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
  2. 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. If this is the case,
  3. 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"

I have viewed other forums, and they have generally stated #2 and #3 and the possible solutions -- it has in general worked. However, none of the above seemed to solve my problem.

I noticed that some of the stored solution values in the ASCII files were as small as 10.e-34. I had a feeling that the underflow conditions maybe be triggering problems. 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.

Upvotes: 4

Hải Phạm Thanh
Hải Phạm Thanh

Reputation: 23

If you are using Fortran, this problem also occur when you write to file but not close it in code.

For example:

do i=1,10
write(numb,'(i3)')i
open(unit=1, file='test'//numb//'.vtk')
write(1,*).......
enddo

Upvotes: 0

Related Questions