Hi all! Thanks a lot Tim for the clarifications on the XDMF/HDF5 data format!
You are right, without proper bug reports the potential problems won't be fixed. So, I probably should have reported the not working XDMF files with screenshots, but I just figured that I might do something wrong and got it working otherwise. :)
There where two important things that I learned step by step about VTK/XDMF/HDF5:
1. The 2D grids (e.g. 2DRectMesh) allow only two-component vectors, kind of logic, but I also did that mistake.
2. Paraview reads the dimensions, origin and spacing for uniform rectangular meshes (i.e. 2DCoRectMesh and 3DCoRectMesh) in ZYX order as opposed to XYZ. The underlying reason is probably the C memory layout, as Tim already explained (more details can also be found here [1]). However, this behavior is not always consistent in all XDMF readers. For example, the 1D coordinate arrays for a 3DRectMesh (using VXVYVZ) have to be listed in X, Y, Z order, while the dimensions are specified in ZYX order (see my earlier mail for an example).
In all cases, the data arrays have to be in reveres (i.e. ZYX) order.Now, when I started to read and write XDMF/HDF5 files, I also had to experiment quite a bit and I believe the major reason why I didn't get the 2D grids working was related to the memory layout.
Nowadays, I use XDMF/HDF5 files for almost everything. It's just to easy to have a quick look at the data in ParaView, and one can read them otherwise very nicely with python (using vtk or h5py directly). Though, I haven't looked into the more advanced stuff like hyperslabs and the like yet.
Attached is one more example of a 3DCoRectMesh, which essentially is a 2D surface (has however three-component vectors).
-Armin [1] http://www.visitusers.org/index.php?title=Memory_accessOn 03/07/2015 01:24 AM, Tim Gallagher wrote:> Don't forget to reply to the list --
Without seeing errors or images of what was wrong about it, there isn't much we can do to help. The file I sent does work and PV reads it just fine. The coordinate axes in this case is Y-Z, but ultimately those are just names since it's 2D right? It doesn't matter if I call it X-Y, Y-Z, or X-Z so long as I have 2 orthogonal coordinates. The axes are specified in reverse order when you list them the way it is done there. So the first dataitem is always Z, the second is always Y and the third, if you have one, is always X. This also comes up when you specify the multi-dimensional data items in the attribute section because you have to remember it uses C memory layout (row major), which is different from the Fortran layout (column major). We use XDMF for massive multiblock structured simulations and we store our coordinates in hdf5 files in full 3D arrays (so what something like the meshgrid function returns in Matlab/Numpy) and I've put an example at the end of my email here. In this case, we have a grid which in Fortran would have coordinates X(I,J,K) where I = 1, 83; J = 1, 83; K = 1, 4. Note that the indexing is flipped when we specify it in the XDMF file. It is also flipped from what one would expect coming from Fortran when you look at the h5dump (after the XDMF example). Our strategy is to specify our grid points as an array of vectors and we create that array of vectors using the JOIN function. The XDMF documentation isn't always as helpful as I'd like sometimes. It took a lot of trial and error on our part to get this working (and it's made more complicated because we use hyperslabs a lot to only display portions of our data). The PV release binaries are also not helpful in understanding the problems sometimes -- very often, it will just segfault or crash with a glibc double-linked list error or something. Building PV yourself with debug options may help if you are really stuck. But what you seem to be trying to do is fully supported and you just need to keep working at it to understand why it doesn't work. And if you are having problems, posting images of what it looks like when you import the data would really help if the issue is just that it doesn't seem to be what you think it should be. Tim <Topology TopologyType="3DSMesh" Dimensions="4 83 83 3"/> <Geometry GeometryType="XYZ" Units="m"> <DataItem ItemType="Function" Function="JOIN($0, $1, $2)" Dimensions="4 83 83 3"> <DataItem Dimensions="6 85 85" NumberType="Float" Precision="8" Format="HDF">&gridpath;/grid.h5:/Domain_00001/x</DataItem> <DataItem Dimensions="6 85 85" NumberType="Float" Precision="8" Format="HDF">&gridpath;/grid.h5:/Domain_00001/y</DataItem> <DataItem Dimensions="6 85 85" NumberType="Float" Precision="8" Format="HDF">&gridpath;/grid.h5:/Domain_00001/z</DataItem> </DataItem> </DataItem> </Geometry> <Attribute AttributeType="Scalar" Center="Cell" Name="Temperature [K]"> <DataItem NumberType="Float" Dimensions="3 82 82" Precision="8" Format="HDF">&outputpath;/RESTS/REST_00000.h5:/FlowData/temperature</DataItem> GROUP "/" { GROUP "Domain_00001" { DATASET "x" { DATATYPE H5T_IEEE_F64LE DATASPACE SIMPLE { ( 6, 85, 85 ) / ( 6, 85, 85 ) } } DATASET "y" { DATATYPE H5T_IEEE_F64LE DATASPACE SIMPLE { ( 6, 85, 85 ) / ( 6, 85, 85 ) } } DATASET "z" { DATATYPE H5T_IEEE_F64LE DATASPACE SIMPLE { ( 6, 85, 85 ) / ( 6, 85, 85 ) } } }
On 03/07/2015 12:54 AM, Tim Gallagher wrote:
Hi guys, So the problems you're having are due to specifying inconsistent data here. You are specifying a 2DRectMesh grid but then giving it 3 vectors for the points. I don't have your HDF5 files so I made a light data XMF file that works for me on all versions going back to 3.14. I have attached it here for you to test. This all works fine. I've also created a 3DRectMesh. For that, you need to give it 2 points in the 3rd direction for the grid because you are specifying cell centered data. If you only give it 1 point in the 3rd direction, there is no "cell" anymore in which to specify the data. I'll leave adding the 3rd dimension as an exercise for you to work with. Once you figure out how it needs to work using the light data format, then switch over to using the heavy data format and get it working again. Hope that helps, Tim ----- Original Message ----- From: dkxl...@gmail.com To: canismajorw...@gmail.com Cc: paraview@paraview.org Sent: Friday, March 6, 2015 4:55:37 PM Subject: Re: [Paraview] Import of XDMF/HDF5:Cell centered attribute of 2D Rectangular grid I have had similar problems with 2D structured grids and XDMF in the past. I never got them to work in ParaView. I solved the problem by using 3D grids and set the first dimension (i.e. the slowest varying) one to 1, the same way as you have done it with VXVYVZ. You just have to adjust your data arrays accordingly, i.e. dimensions 1 82 221 in your example. I can send you a working xdmf file when back in the office. I believe the computational overhead from 2D to 3D grids with effectively 2 dimensions is rather small. Maybe the next-generation XDMF reader in ParaView works better for 2D structued grids or somebody with the knowledge explains us how to write them correctly. :) -Armin On Fri Mar 6 23:17:52 2015 GMT+0200, Canis Major wrote:I have troubles importing xdmf output to paraview. This is an example of xdmf of 0th iteration. <?xml version="1.0" ?> <Xdmf> <Domain> <Grid Name="Grid" GridType="Uniform"> <Topology TopologyType="2DRectMesh" Dimensions="1 82 221"/> <Geometry GeometryType="VXVYVZ"> <DataItem Dimensions="1" NumberType="Float" Precision="4" Format="HDF"> xdmf2d.h5:/Z </DataItem> <DataItem Dimensions="83" NumberType="Float" Precision="4" Format="HDF"> xdmf2d.h5:/Y </DataItem> <DataItem Dimensions="221" NumberType="Float" Precision="4" Format="HDF"> xdmf2d.h5:/X </DataItem> </Geometry> <Attribute Name="pressure" AttributeType="Scalar" Center="Cell"> <DataItem Dimensions="82 220" NumberType="Float" Precision="4" Format="HDF"> xdmf2d.0.h5:/pressure </DataItem> </Attribute> </Grid> </Domain> </Xdmf> I have an error that paraview failed to import attribute. What could be wrong? I have played around the parameters nothing helps.
circAvgFavre.xmf
Description: audio/xmf
_______________________________________________ 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 Search the list archives at: http://markmail.org/search/?q=ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview
