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
--
Philippe DAVID
Sciences Computers Consultants
