CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   ParaView (http://www.cfd-online.com/Forums/paraview/)
-   -   Ensight byte order (http://www.cfd-online.com/Forums/paraview/130739-ensight-byte-order.html)

DLuo March 3, 2014 15:21

Ensight byte order
 
I've got an ensight data set written out by a 3rd party in Little Endian order.
However, when I read it into Paraview, it seems to pass both the Little Endian and Big Endian tests.
According to the vtkEnsight binary reader source code

Code:

// Just a sanity check. (0, 0 occurs often).
    // This condition would only occur for some really large files.
    if (tmpLE > 0 && tmpBE > 0)
      {
      vtkWarningMacro("Byte order is ambiguous.");
      }
 
    // If they are both valid, use the larger one.

It reverts to reading the data as a Big Endian file, which then results in a segmentation fault.

Because I can't get the data in Ensight Gold Format I'm stuck dealing with this vtkEnsight6BinaryReader.
Does anybody have any recommendations or suggestions?

wyldckat March 4, 2014 05:54

Greetings Andy,

Which exact ParaView version are you using?

----
edit: I've done a very quick test in ParaView 4.1.0, but without a small test case, I'm unable to double check this.
The test was to use Python code to load the data directly with VTK:
Code:

import vtk
e = vtk.vtkEnSight6Reader()
e.SetByteOrderToLittleEndian

This is the farthest I went, because the last method exists and allows us to define the Endianness to be used by the reader, instead of relying on automatic definition.
I'm going to do some other tests with the ParaView Data sample, which provides EnSight Gold data and try to figure out how to use a Programmable Source to do a VTK data loading.
----

Best regards,
Bruno

wyldckat March 4, 2014 06:50

OK, here's what I've done with some success:
  1. Instead of "File->Open", I used "Sources->Programmable Source'.
  2. In the "Output Data Set Type" drop-down box, I chose "vtkMultibockDataSet".
  3. In the first big edit box "Script", I placed this source code:
    Code:

    import vtk
    en = vtk.vtkEnSightGoldReader()
    en.SetFilePath('/home/user/ParaViewData-v4.0.1/Data/EnSight/')
    en.SetCaseFileName('elements.case')
    #en.SetByteOrderToLittleEndian() #commented out
    en.Update()

    self.GetOutput().ShallowCopy(en.GetOutput())

  4. Then hit the "Apply" button.
It showed me the correct data, although I didn't have a nice interactive way to choose which data sets I wanted to load, but at least I could choose to render them or not.


I'll update this post, if I can find some non-Gold EnSight file... hopefully VTK has got one or two...

---------
edit: OK, found a test case in VTK 5.8's data package. The following code mostly worked, although it gave be an intriguing error message:
Code:

import vtk
en = vtk.vtkEnSight6BinaryReader()
en.SetFilePath('/home/user/VTKData/Data/EnSight')
en.SetCaseFileName('office6_bin.case')
#en.SetByteOrderToLittleEndian()
en.Update()

print en.GetByteOrderAsString()

self.GetOutput().ShallowCopy(en.GetOutput())

The intriguing message was:
Code:

vtkSMPVRepresentationProxy (0x54e60c0): Could not determine array range.
But it seemed to have loaded the data correctly... er, no, the "vectors" field didn't get properly loaded.

If we uncomment the LittleEndian line, it won't load the data, as it's wrongly ordered. The "print" line will let us known which mode it is using for loading the data.

DLuo March 4, 2014 10:17

Thanks for the reply Bruno,

I'm testing with version 4.1 on CentOS

I tried your example case with and without the en.SetByteOrderToLittleEndian()
Without it: I get the same warning and then the Segmentation Fault
With it: I just get Segmentation Fault

In both cases it appears that it doesn't get past line 6 because I get no output from either Paraview nor my CLI telling me the Endianness

wyldckat March 4, 2014 10:29

Strange... are you using:
Code:

en = vtk.vtkEnSight6BinaryReader()
en.SetFilePath('/home/user/VTKData/Data/EnSight')
en.SetCaseFileName('office6_bin.case')

and properly defining the path and file name to the case file in question?

Perhaps the data is in EnSight 5?

Have you tried using the free version of EnSight? It's suppose to be limited, but perhaps it can help to either convert the data formats or at least validate if the data can in fact be loaded or not.

DLuo March 4, 2014 11:09

Yes I was using the code you quoted above
I also tried importing as both MultiBlock and as Unstructured Data

I have similar data sets generated from the same source that read in fine; same solver, same analysis just a slight geometry change. So I don't think it's a matter of Ensight version.

The frustrating part is that I can read the data into other Ensight viewers but all my post Processing scripts are set up in ParaView and it's not trivial to port them over to something else.

Edit:
I don't have sys-admin privileges so can't install the free version of Ensight on my own

wyldckat March 4, 2014 11:33

Mmm... it's possible that something is somewhat broken in the code that generates the EnSight data files.
Possibly the original data generation binaries are in 32 bit and ParaView is in 64 bit, leading to some array incorrect sizing or interpretation.

Do you know the array dimensions that are meant to be loaded on each case? Namely a good case vs a bad case? It's possible that one of them is over 2GiB integer value, leading to bad pointing issues.

Because the only other thing that comes to mind is to write an Endian converter for those data files :(

edit: By the way, what happens when you comment out the last line, namely the one that starts with "self"?

DLuo March 4, 2014 18:52

Well the Ensight files read fine into Meta PostCFD and it's been confirmed to open in Ensight as well (not by me) so I don't think it's something with the generation of the Ensight file. And I'm pretty sure everything I've been dealing with is 64-bit.

I don't follow what you mean by array dimensions. Is there a quick way to check?

I'm hoping not to have to delve into an Endian converter. I tried playing with quick one-liners such as dd conv=swab but honestly I don't know what I'm doing there. From what I've read, I need more in depth knowledge about the structure of the binary file in order to do a proper Endian conversion.

Also when I comment out the last line beginning with "self" I get the same thing namely because the Segmentation Fault happens during the input portion of the code therefore it doesn't even get a chance to read that line.

BTW when I try that code with a "good" ensight data set, it throws errors if I leave in the line "en.SetByteOrderToLittleEndian()"
Code:

vtkEnSight6BinaryReader (0x2fbeb30): Invalid number of unstructured points; check that ByteOrder is set correctly.
Without it, it just prints BigEndian. The data doesn't actually get rendered.

Have I been misinformed? Are my data sets in fact Big Endian?

wyldckat March 5, 2014 14:36

Quote:

Originally Posted by DLuo (Post 478131)
Well the Ensight files read fine into Meta PostCFD and it's been confirmed to open in Ensight as well (not by me) so I don't think it's something with the generation of the Ensight file. And I'm pretty sure everything I've been dealing with is 64-bit.

Mmm... OK, then it's probably more than just one bug in the ParaView/VTK reader.
What about asking the person who opened in EnSight to export into Gold format? As long as it's practical, that is... or at the very least, you can figure out if it's a lost cause or not, in case ParaView can't even open in Gold format.

Quote:

Originally Posted by DLuo (Post 478131)
I don't follow what you mean by array dimensions. Is there a quick way to check?

Check the number of points and/or number of cells reported by EnSight or Meta PostCFD. The dimensions of the arrays are directly associated, so it will only be a matter of multiplying by 2 or 3, in order to estimate the sizes of the arrays.

Quote:

Originally Posted by DLuo (Post 478131)
I'm hoping not to have to delve into an Endian converter. I tried playing with quick one-liners such as dd conv=swab but honestly I don't know what I'm doing there. From what I've read, I need more in depth knowledge about the structure of the binary file in order to do a proper Endian conversion.

It probably requires specific coding, since a simple byte swapping will not do the trick, as there might be data that is not in little or big Endian.

Quote:

Originally Posted by DLuo (Post 478131)
Also when I comment out the last line beginning with "self" I get the same thing namely because the Segmentation Fault happens during the input portion of the code therefore it doesn't even get a chance to read that line.

Too bad. I had hopes that it could have been an issue in the transfer of data into ParaView, but since it's not, the problem is during the reading of the data.

Quote:

Originally Posted by DLuo (Post 478131)
BTW when I try that code with a "good" ensight data set, it throws errors if I leave in the line "en.SetByteOrderToLittleEndian()"
Code:

vtkEnSight6BinaryReader (0x2fbeb30): Invalid number of unstructured points; check that ByteOrder is set correctly.
Without it, it just prints BigEndian. The data doesn't actually get rendered.

If the last line with "ShadowCopy" was still operational when you made that test, then the data is likely in LittleEndian.
Worst case scenario: the big data might be in BigEndian, but certain details might be in LittleEndian.

Quote:

Originally Posted by DLuo (Post 478131)
Have I been misinformed? Are my data sets in fact Big Endian?

In the tests I made, when using the incorrect Endian, it did not crash, but it also did not properly load the data for rendering. So essentially, nothing was rendered.


I did another quick look for any more hints that might be in the code documentation and I spotted this today: http://www.vtk.org/doc/nightly/html/...r.html#details
Quote:

Warning
You must manually call Update on this reader and then connect the rest of the pipeline because (due to the nature of the file format) it is not possible to know ahead of time how many outputs you will have or what types they will be. This reader can only handle static EnSight datasets (both static geometry and variables).
Looks like one hint is that your data might have non-static geometry or variables.


Beyond this, the only somewhat practical idea that comes to mind is to build VTK 6.0 or 6.1 from source code in Debug mode and to diagnose the issue more up-close in the VTK code. Or use a release version of VTK and build a modified version of this class...
Of course that for such it would be useful to have a really small test case that reproduces the problem. Such a test case would still be needed for submitting a bug report in the VTK bug tracker, in case you prefer to defer the issue to the developers.

Contacting Kitware directly for paid support is also a possibility, but I don't know if it's practical for you (your company) or not.

DLuo March 7, 2014 15:46

Regarding array sizes, the case has 22M points and 39M cells.

I think I might just have to abandon my scripts for this case and manually post-process the data in metaPost CFD.

If I happen across an installation of Ensight, I'll give the import/export a try and see if Paraview can read the new data.

Thanks for your help Bruno but it looks like this one will remain unresolved for some time.

DLuo April 3, 2014 21:55

Hi Bruno,
So it turns out, the code you provided was on the correct path. A colleague of mine, who is much better versed in Python, was able to take your code and make it work/load the corrupted files into paraview.
In short, it turns out the files were in fact Big Endian, and that most of the datasets had a header that specified Big Endian. But in a few cases, it actually lacked this information, and thus Paraview struggled with it. I'm a little surprised because the source code for the vtkEnsight Binary reader is supposed to default to Big Endian if the byte order is ambiguous.

Honestly I can't really explain it any better because my python scripting is terrible. But for anyone else who has a similar problem I think the points Bruno brought up are a good starting point.

wyldckat April 4, 2014 15:39

Hi Andy,

I'm glad your colleague managed to use my broken Python code to get things working!
And I hope you've documented this on your side, otherwise you might trigger the same issue in a few months from now and no longer have a working solution for it :(.

Best regards,
Bruno


All times are GMT -4. The time now is 09:05.