[Paraview] 32b vs 64b and Binary vs Ascii

[Mike Jackson]

oops.. Well my code wasn't quite what I remembered. I do have code to 
read/write vtkUnstructuredGrids from an HDF5 file BUT all the code _is_ 
based on vtk code. Sorry for the mis-information. What is there is the 
beginnings of a "translation" of vtk files into HDF5 files. I think the 
idea was to try and create a library where one could write "vtk" files 
into HDF5 files using the native hdf5 services. So instead of writing an 
xml file or ASCII file the data is stored natively into an HDF5 file. I 
think all the farther I got was for unstructured grids. I think if you 
followed the layout of the hdf5 file with your own code the at least the 
reader portion would be useful. Unless you want to bring in vtk into 
your simulation as a dependency.

  Again sorry for the mis-information on this. I am truly "red-faced" 
over this.

Mike


Michael Jackson wrote:
> I was hitting the same problem and I ended up writing the unstructured 
> grid to and HDF5 file. I wrote the code so that the writing was portable 
> and NOT vtk dependent but reading the HDF5 data would read it directly 
> into a vtkUnstructuredGrid object. Never really cleaned up the code but 
> anyone is welcome to it if you want. Just shoot me  an email off list.
> 
> Mike
> 
> On Apr 7, 2009, at 10:14 AM, Stephens, Michael M ERDC-ITL-MS wrote:
> 
>> philippe,
>>
>> you might be running into the same problem i had in that the vtu (or 
>> all XML
>> styled files) have a
>> problem in that all the contents (points, connectivity, data) must be 
>> shorter
>> than 2^31.
>> it's the way the thing is written... there's an "int" (or several) 
>> that needs
>> to be
>> a long int or long long int.
>>
>> sounds like your grid is large or has a lots of data variables, either 
>> way
>> the XML format isn't capable of handling it presently.
>>
>> it would be desirable for the XML writing codes to flag this and at least
>> give you a warning about this.
>>
>> for what it's worth, i got around this by writing binary legacy vtk 
>> files.
>>
>> -m
>>
>> -----Original Message-----
>> From: paraview-bounces at paraview.org 
>> [mailto:paraview-bounces at paraview.org] On
>> Behalf Of Philippe David
>> Sent: Tuesday, April 07, 2009 9:06 AM
>> To: Michael Jackson
>> Cc: paraview at paraview.org
>> Subject: Re: [Paraview] 32b vs 64b and Binary vs Ascii
>>
>> thanks for your feedback:
>> We do use in-house FEM code which also use MPI: I will cross check your
>> suggestions. Small vtu work fine but 300mb one have problems (where it 
>> is not
>> obvious to manually check them). thank you again
>>
>> Michael Jackson a écrit :
>>
>>     What code are you using to write the .vtu files? Is it vtk code or is
>> it code that you wrote for your own simulation? It sounds like it 
>> _might_ be
>> incorrect values in the header parts of the velocity field. I believe 
>> .vtu
>> files are ascii so you should be able to hand check the values that 
>> are being
>> saved into the file with what you think you should be writing.
>>     
>>        Also on the off chance that your simulation is using either
>> threads or MPI or something where it is distributed are you locking the
>> section of code where the writing is performed? Possibly sounds like 2
>> processes maybe accessing and writing to the areas of memory as the 
>> same ares
>> is being written to disk.
>>     
>>      Just some thoughts.
>>     _________________________________________________________
>>     Mike Jackson                  mike.jackson at bluequartz.net
>>     BlueQuartz Software                    www.bluequartz.net
>>     Principal Software Engineer                  Dayton, Ohio
>>     
>>     
>>     
>>     On Apr 7, 2009, at 5:14 AM, Philippe David wrote:
>>     
>>     
>>
>>         we face non recurrent problem trying to read .vtu files
>> containing Velocity vectors.
>>         Paraview 3.4.0 replies with "...dataArray may be too short"
>> in some  conditions.
>>        
>>         the vtu are written under Linux 64 :
>>         if reading whose vtu with client "windows 32" and server
>> "linux 64" we quite often have the message "...dataArray may be too 
>> short"
>> from Paraview 3.4.0. The same vtu file read locally under windows 32 
>> is Ok.
>>         Time to Time it is vice versa : the problem occurs under
>> windows 32 and run correctly under client/server.
>>         If we mask the velocity field at loading it is working.
>>        
>>         -Ascii mode sounds more secure even though it is not working
>> 100% of the cases.
>>         -Finally, different vtu from a same run (at different time
>> step) behave differentely.
>>        
>>         thanks to anybody having encountered those type of problem or
>> who may have some suggestions.
>>        
>>         --
>>         Philippe DAVID
>>        
>>
>>
>>
>>
>>
>> -- 
>> Philippe DAVID
>> Sciences Computers Consultants
>>

-- 
_________________________________________________________
Mike Jackson                  mike.jackson at bluequartz.net
BlueQuartz Software                    www.bluequartz.net
Principal Software Engineer                  Dayton, Ohio