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: [email protected] [mailto:[email protected]] On Behalf Of Philippe David Sent: Tuesday, April 07, 2009 9:06 AM To: Michael Jackson Cc: [email protected] 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 [email protected] 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 _______________________________________________ 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
