[Paraview] [Xdmf] - vtkXdmfReader - time support

[Jerry Clarke]

Putting on my "way back" hat, I seem to remember us having problems
with parallel HDF5. To make it work we had to set some NFS parameter
which turned out to negatively impact performance of NFS. I believe
that is why we added the SetUseSerialFile() method to XdmfHDF.

Jerry

John Biddiscombe wrote:
> Just a follow up to my own emails. I tested in parallel and had some 
> trouble. I fixed an error in the origin setting of image pieces which 
> crept in when I merged my code with other changes
> 
> so...
> 
> Loading (imagedata) in parallel works fine if you have 
> HDF5_ENABLE_PARALLEL OFF, but fails if you have it on. Actually, having 
> it on is mostly useful if you are writing rather than reading, so no 
> loss there.
> 
> NB. These test were performed on a system using nfs mounted files which 
> don't support HDF5 parallel anyway. Tests on a GPFS mounted filesystem 
> also failed, but the error message was the same as on nfs (file lock 
> error) and I don't believe all is working correctly. I will continue 
> testing on parallel filesystem and keep you informed (if you want!). I 
> will also try with hdf 1.8 (anyone cmake-ified it yet?)
> 
> JB
> 
>> I have just re-uploaded the test data xdmf file because I left the full 
>> path (C:\temp\blah) in the file reference. I have replaced it with just 
>> the relative part and checked it loads ok on win32/linux.
>> (NB. loading in parallel failed. I will find the problem right away)
>>
>> JB
>>
>>
>>   
>>> I've just checked in some changes to the vtkXdmfReader for handling 
>>> time dependent data.
>>>
>>> I have also uploaded a test dataset to here
>>> ftp://ftp.cscs.ch/out/biddisco/xdmf
>>>
>>> this contains a single Volume of dimension {24,24,24} with several 
>>> scalar/vector fields.
>>> Interesting Vector fields are
>>>    X-Vector {1, 0, 0}
>>>    Y-Vector {0, 1, 0}
>>>    Z-Vector {0, 0, 1}
>>> which makes it ideal for testing. Some other fields are block number 
>>> and suchlike which are only useful to me.
>>>
>>> In the Xdmf xml file, the same data is referenced twice - so there are 
>>> two time steps - they are actually the same data in both time steps, 
>>> but the second step swaps the x,y,z vector fields around by simple 
>>> changing the string references to datasets in the hdf5 file.
>>>
>>> In timestep 0 (time value 0.0)
>>> x - X
>>> y - Y
>>> z - Z
>>> In timestep 1 (time value 0.2)
>>> x - Y
>>> y - Z
>>> z - X
>>>
>>> The changes I have made to the XdmfReader might break some code since 
>>> I had to change the Grid storage from a Map structure to a vector - to 
>>> allow the same grid name to be used for multiple time steps. There are 
>>> also many other small tweaks/fixes all over the place.
>>>
>>> I will check in some changes to the vtkXdmfWriter later, but will post 
>>> separately on that.
>>>
>>> Please let me know of any problems this introduces - I think there is 
>>> still much work to be done (c.f. other vtk data types)
>>>
>>> JB
>>>
>>>     
>>
>>
>>   
> 
> 
> -- 
> John Biddiscombe,                            email:biddisco @ cscs.ch
> http://www.cscs.ch/about/BJohn.php
> CSCS, Swiss National Supercomputing Centre  | Tel:  +41 (91) 610.82.07
> Via Cantonale, 6928 Manno, Switzerland      | Fax:  +41 (91) 610.82.82
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xdmf mailing list
> Xdmf at lists.kitware.com
> https://www.kitware.com/cgi-bin/mailman/listinfo/xdmf