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

[Michael Jackson]

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
>