I have a visualization routine for a high resolution 3D simulation, and it writes binary/xmf files. Everything seems to go fine, but when I open it in Paraview 5.5.1 the data range for some of the arrays is incorrect (up to e+36 instead of e+1 and 1e-20 instead of 0, seems close to the maximum float size). When opening the same files on a OSX or Linux machine (with 5.1.2) instead of Windows 10 64 bit everything seems to work fine!
Anyone an idea in how to fix this problem? The filesize is 8 gb. I use Xdmf3 reader. If needed I can provide the .xmf and .bin files.
I just found out that while release binaries for windows are built only with MSVC2013, nightly builds are made with a variety of compilers. Try them. MSVC2013 builds for Windows are very unstable, despite the “stable” prefix. At the moment I am trying GCC builds, which look and work closer to linux. Despite there are UI metrics bugs, like window elements of wrong size.
The absence of notice about other Windows compilations in “nightlies” have cost me problems at my work (never tried using alpha and beta software for important work)
They shouldn’t be any different other than the compiler. If you want something most similar to what you are using, choose 2013. If you want something most similar to the next version choose 2015. Unless you know you need MS MPI, you can ignore the -MPI binaries. “very unstable” is an exaggeration… @Someone_fromjapan has just had problems since they are trying to do things that noone has done recently and they are frustrated.
That said, this is probably a bug in the reader code or the rendering code and won’t be affected by the compiler. Can you share the data (or given the size, a smaller dataset that still exhibits the problem)? That would help a lot in tracking this down. Unless @Dave_DeMarle has seen something like this? He’s more familiar with XDMF than I am.
So I have tried a variety of things. Different builds of Paraview on Windows do not fix the problem. Closer inspection shows me that this problem is most probably related to the xdmf reader and the seek variable in the .xmf file. The data gets corrupt after reading the maximum value of an integer (2147483647). Do you reckon this can be fixed?
As this problem only occurs with larger datasets (probably >2 gb binaries), would you need the data still?
The first xmf file loads fine, the second displays wrong ranges from -3.21869e+26 to 4.56693e+32. absa_0.xmf (3.0 KB) chem_absa_0.xmf (6.4 KB)
The one with no mention about compiler. Today it is gcc… don’t know what it would be tomorrow.
It has minor bugs in UI, but does not crash when editing.
It is possible, scaling will also be correct, because numbers representation in MSVC and GCC can differ(see long double difference for instance). This can be the root of your problem.
On the other hand gcc nightly just crashed today at my home, leaving rendered avi half-unreadable. While MSVC build which was crashing during edits had finished its blind AVI rendering without errors today.
If you have linux installed on hardware (not VM), I would recommend using linux build.
It is still helpful to have a dataset where we KNOW the problem happens. Let me talk to @Dave_DeMarle about fixing this. It may be that we need to update the XDMF library or it may be a signed/unsigned integer error in the reader.
(never tried using alpha and beta software for important work)