[Paraview] Memory seeking problems in using the xdmf2 reader

Pulido, Jesus pulido at lanl.gov
Thu Jul 30 17:55:54 EDT 2015


Hi David,

The patch did not work, the file is still not read correctly after the second scalar component.

After applying your patch, I did a bit of debugging myself. I enabled XDMF Debug in the code and found that the seek values are incorrect for scalar fields 3, 4, and 6.
They seem to be stuck at the value 2147483647. On the plus side, it looks like the array size (array size in bytes) is being computed correctly.

Please take a look at the parsed debug log file that I've attached. Maybe the seek value is being malformed somewhere before it reaches XdmfValuesBinary.cxx?

Thanks,
Jesus


________________________________
From: David E DeMarle [dave.demarle at kitware.com]
Sent: Wednesday, July 29, 2015 10:36 PM
To: Pulido, Jesus
Cc: paraview at paraview.org
Subject: Re: [Paraview] Memory seeking problems in using the xdmf2 reader

Would you mind trying this Jesus?

diff --git a/ThirdParty/xdmf2/vtkxdmf2/libsrc/XdmfValuesBinary.cxx b/ThirdParty/xdmf2/vtkxdmf2/libsrc/XdmfValuesBinary.cxx
index 04ea0a7..6fe37d0 100644
--- a/ThirdParty/xdmf2/vtkxdmf2/libsrc/XdmfValuesBinary.cxx
+++ b/ThirdParty/xdmf2/vtkxdmf2/libsrc/XdmfValuesBinary.cxx
@@ -187,7 +187,7 @@ public:

 size_t XdmfValuesBinary::getSeek(){
     if(this->Seek==NULL)return 0;
-    return static_cast<size_t>(atoi(this->Seek));
+    return static_cast<size_t>(atol(this->Seek));
 }

Once you confirm it fixes it for you too I'll check it in.

Thanks,


David E DeMarle
Kitware, Inc.
R&D Engineer
21 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-881-4909

On Fri, Jul 24, 2015 at 12:43 PM, Pulido, Jesus <pulido at lanl.gov<mailto:pulido at lanl.gov>> wrote:
Hello,

I have written a custom xmf file used by the xdmf2 reader to properly read in (raw) binary data into Paraview. This normally works but only for small datasets. The file requires the input of a memory "seek" location to start reading the different scalar components of the data. A problem arises when there is a 512^3 dataset, with 5 scalar components that are required to be read in. The first two scalar components are read in correctly, then the next two components receive the error:


ERROR: In /Users/kitware/Dashboards/MyTests/NightlyMaster/ParaViewSuperbuild-Release-Python27/paraview/src/paraview/VTK/IO/Xdmf2/vtkXdmfHeavyData.cxx, line 1128

vtkXdmfReader (0x7f8614672af0): Failed to read attribute data

The 5th component then becomes a duplicate of the 1st component.
What I believe that's happening is that the "seek" value is only being represented as a signed integer, this would explain the memory location rolling from MAX_INT to -MAX_INT, and failing to read in scalar components 3 and 4. Their seek locations fall within this case. By the time the 5th component is read, the seek value may have rolled over back to positive values (seek > 0) and then duplicates the same data as the 1st component.

Is this assumption correct and intended? Is there fix for this or an alternative way around reading large, raw datasets using this format? I'm attaching a sample xmf file

Thank you,
Jesus

_______________________________________________
Powered by www.kitware.com<http://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

Search the list archives at: http://markmail.org/search/?q=ParaView

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/paraview


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20150730/3096c395/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: debug.txt
URL: <http://public.kitware.com/pipermail/paraview/attachments/20150730/3096c395/attachment.txt>


More information about the ParaView mailing list