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

[Stephens, Michael M ERDC-ITL-MS]

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 
		
		_______________________________________________ 
		Powered by www.kitware.com 
		
		Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html 
		
		Please keep messages on-topic and check the ParaView Wiki at:
http://paraview.org/Wiki/ParaView 
		
		Follow this link to subscribe/unsubscribe: 
		http://www.paraview.org/mailman/listinfo/paraview 
		






-- 
Philippe DAVID
Sciences Computers Consultants