CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Programming & Development

HDF5 IO library for OpenFOAM

Register Blogs Community New Posts Updated Threads Search

Like Tree31Likes

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   February 3, 2014, 11:04
Default
  #21
Senior Member
 
Join Date: Dec 2011
Posts: 111
Rep Power: 20
haakon will become famous soon enough
I will try HDF5 1.8.12 myself tomorrow or Wednesday (I am very busy tomorrow) and see what I get. I think I am using HDF5 1.8.11 myself right now. Have you checked that you have write permissions in the folder?
haakon is offline   Reply With Quote

Old   February 4, 2014, 01:46
Default
  #22
Member
 
Join Date: Aug 2012
Posts: 33
Rep Power: 14
gigilentini8 is on a distinguished road
thanks Haakon

sure, with OF22x and Gcc it works
mm.abdollahzadeh likes this.
gigilentini8 is offline   Reply With Quote

Old   February 14, 2014, 15:58
Default
  #23
Member
 
Krishna
Join Date: Jun 2012
Posts: 33
Blog Entries: 1
Rep Power: 14
rkc.cfd is on a distinguished road
Thanks Håkon for the HDF5 Plugin.

I am currently porting it to the foam-extend-3.0 version. I have modified all the environment variables different from OF-2.2.x and foam-extend-3.0.

I am currently getting the following error in the core hd5Write.H, could you please comment on this error.


Cheers,

Krishna
Attached Files
File Type: txt log.Allwmake.txt (12.2 KB, 23 views)
rkc.cfd is offline   Reply With Quote

Old   January 9, 2015, 06:44
Default
  #24
egp
Senior Member
 
egp's Avatar
 
Eric Paterson
Join Date: Mar 2009
Location: Blacksburg, VA
Posts: 197
Blog Entries: 1
Rep Power: 18
egp is on a distinguished road
Have there been further developments since the last post (almost 1 year ago)? This is a pace-setting issue for true HPC (1000+ core) simulations. My HPC admins are demanding that we come up with a solution, and I wanted to check on status before digging in.
egp is offline   Reply With Quote

Old   January 9, 2015, 07:53
Default
  #25
Senior Member
 
Join Date: Dec 2011
Posts: 111
Rep Power: 20
haakon will become famous soon enough
The latest update is on Github (https://github.com/hakostra/IOH5Write). It does work on OF 2.3.x as far as I know. As with any software there is some installation problems if your environment is not configured properly. Use a recent HDF5 version. Try to read the installation guidelines.

The "known bugs and limitations" section in the README file (see Github) does still apply. I should also probably emphasize that due to missing support in the XDMF format, polyhedral cells is not supported. I would love to see polyhedral cell support in XDMF, but I doubt that's going to happen any time soon.

One possible workaround for this issue is perhaps to rewrite the whole thing to use CGNS, that has support for polyhedral cells. However, it does not have support for discrete particles, and that was a showstopper for me when I wrote this library, hence the current HDF5+XDMF approach.
haakon is offline   Reply With Quote

Old   June 23, 2015, 15:57
Default Wrting Boundary Data to HDF5?
  #26
Member
 
Krishna
Join Date: Jun 2012
Posts: 33
Blog Entries: 1
Rep Power: 14
rkc.cfd is on a distinguished road
Hi Haakon,

How do we implement to write the boundary data?

Cheers!
rkc.cfd is offline   Reply With Quote

Old   February 3, 2016, 08:43
Default
  #27
nsf
Senior Member
 
Nicolas Edh
Join Date: Mar 2010
Location: Uppsala, Sweden
Posts: 123
Rep Power: 18
nsf is on a distinguished road
Quote:
Originally Posted by haakon View Post
The latest update is on Github (https://github.com/hakostra/IOH5Write). It does work on OF 2.3.x as far as I know. As with any software there is some installation problems if your environment is not configured properly. Use a recent HDF5 version. Try to read the installation guidelines.

The "known bugs and limitations" section in the README file (see Github) does still apply. I should also probably emphasize that due to missing support in the XDMF format, polyhedral cells is not supported. I would love to see polyhedral cell support in XDMF, but I doubt that's going to happen any time soon.

One possible workaround for this issue is perhaps to rewrite the whole thing to use CGNS, that has support for polyhedral cells. However, it does not have support for discrete particles, and that was a showstopper for me when I wrote this library, hence the current HDF5+XDMF approach.
Hi,

It's a great tool you've written! I've been writing on a CGNS exporter my self for a while. I did this since I need polyhedral support. Now ParaView's CGNS reader doesn't support polyhedrals so I had to write my own reader. I got it to work rather well but when I started to implement a parallel version I got into all sorts of trouble with CGNS. Now since CGNS uses HDF5 in the background I've come to the conclusion that it might be better to just stick to HDF5.

Since I need polyhedrals I think I need to develop my own HDF5 writer. My idea is basically to write the mesh fields just as they are and keep a similar structure as OpenFOAM already has. Then I would have to develop a reader or paraview which would read the hdf5-file and use vtkPolyhedron.

Do you see any problems with this approach or can I leverage on some of the work you have done?

Best Regards
Nicolas
nsf is offline   Reply With Quote

Old   February 10, 2016, 17:51
Default
  #28
Senior Member
 
dkxls's Avatar
 
Armin
Join Date: Feb 2011
Location: Helsinki, Finland
Posts: 156
Rep Power: 19
dkxls will become famous soon enough
I think there is another way.

You could extend the XDMF format to handle polyhedral cells. There is already a bug report concerning this topic and I discussed this recently with some XDMF developers, see here:
http://www.kitware.com/pipermail/xdm...er/000895.html

I would start by modifying XdmfTopologyType.cpp, i.e. add polyhedral cell support similar to the POLYGON implementation. Extending the VTK/ParaView readers to handle shouldn't be too difficult either, since polyhedral cells are already supported in VTK.

You can get the latest XDMF source like this:
git clone git://public.kitware.com/Xdmf2.git

However, I would probably recommend you to implement this directly in VTK, which contains a more or less full copy of the XDMF source tree. You get the latest VTK source from here:
https://gitlab.kitware.com/vtk/vtk
And this is the file, where I would start to implement the polyhedral cell support:
https://gitlab.kitware.com/vtk/vtk/b...gyType.cpp#L70

Hope this helps!

-Armin

Last edited by dkxls; February 13, 2016 at 09:31. Reason: Change link to the public XDMF mailing archive
dkxls is offline   Reply With Quote

Old   February 11, 2016, 04:37
Default
  #29
nsf
Senior Member
 
Nicolas Edh
Join Date: Mar 2010
Location: Uppsala, Sweden
Posts: 123
Rep Power: 18
nsf is on a distinguished road
Quote:
Originally Posted by dkxls View Post
I think there is another way.

You could extend the XDMF format to handle polyhedral cells. There is already a bug report concerning this topic and I discussed this recently with some XDMF developers, see here:
http://www.kitware.com/cgi-bin/mailm...er/000895.html

I would start by modifying XdmfTopologyType.cpp, i.e. add polyhedral cell support similar to the POLYGON implementation. Extending the VTK/ParaView readers to handle shouldn't be too difficult either, since polyhedral cells are already supported in VTK.

You can get the latest XDMF source like this:
git clone git://public.kitware.com/Xdmf2.git

However, I would probably recommend you to implement this directly in VTK, which contains a more or less full copy of the XDMF source tree. You get the latest VTK source from here:
https://gitlab.kitware.com/vtk/vtk
And this is the file, where I would start to implement the polyhedral cell support:
https://gitlab.kitware.com/vtk/vtk/b...gyType.cpp#L70

Hope this helps!

-Armin
Hi Armin,

Thanks for the insight. However I don't really see the benefit of going via XDMF. It could be that I'm just not enlightened. Since we already have to write a reader why not skip XDMF. That was my main lesson learned when I implemented the cgns reader writer. It took quite some time of going through the docs. And in the end I discoverer that the standard is so free it is near impossible to write a general reader. So I decided that my reader would have to be specific to my foamwriter. And then I had problems compiling cgns for parallel applications. It was to obvious that I should ditch the CGNS standard. And just go with HDF5. Which is what CGNS uses in the background any ways.

Now as I see it the benefit with not using XDMF is that we could make a reader that can read while the simulation is running. And we can make it smart on how to read the results in parallel since would keep the decomposition. And there would be no need have an intermediate step between simulation and postprocessing.

Now I've only started to work with it, will see how much I get done. It's a spare time project so it will take a while.

If you or some one else is working on something similar or want to pich in I'm happy to discuss the details!

Nicolas
nsf is offline   Reply With Quote

Old   February 11, 2016, 06:34
Default
  #30
Senior Member
 
dkxls's Avatar
 
Armin
Join Date: Feb 2011
Location: Helsinki, Finland
Posts: 156
Rep Power: 19
dkxls will become famous soon enough
Thanks for elaborating your view.
I certainly agree that the CGNS standard is "too free" and writing a general reader is and rather big task. However, the XDMF standard, is far more specific and there exist already readers for VTK/ParaView and VisIt.
So, in my opinion, the XDMF standard is very well suited for CFD applications.

I have a few comments below to further the discussion.

Quote:
Originally Posted by nsf View Post
Now as I see it the benefit with not using XDMF is that we could make a reader that can read while the simulation is running. And we can make it smart on how to read the results in parallel since would keep the decomposition. And there would be no need have an intermediate step between simulation and postprocessing.
There is nothing that holds you back from reading the HDF5/XDMF result file while the simulation is running. With Håkon's HDF5 writer, you just have to run the python utility in-between, but that's a detail specific to the current implementation. Alternatively, one could write the XDMF file directly during run time, always overwriting the previous XDMF file or something more sophisticated.
Concerning the VTK/ParaView XDMF reader: I think they are already quite smart concerning the parallel data handling, but I have no general overview of that.

Quote:
Originally Posted by nsf View Post
If you or some one else is working on something similar or want to pich in I'm happy to discuss the details!
I actually have implemented an HDF5 surface (i.e. cutplanes, isosurfaces, ...) writer for OpenFOAM similarly to Håkon's IO library. Meaning, I'm writing HDF5 files with during runtime and generate the XDMF file with a python script afterwards.
It's not (yet) publicly available, but I'm happy to share it if you are interested in. (I actually should just put it to some public git repo.)

-Armin
dkxls is offline   Reply With Quote

Old   February 11, 2016, 07:17
Default
  #31
nsf
Senior Member
 
Nicolas Edh
Join Date: Mar 2010
Location: Uppsala, Sweden
Posts: 123
Rep Power: 18
nsf is on a distinguished road
Quote:
Originally Posted by dkxls View Post

I actually have implemented an HDF5 surface (i.e. cutplanes, isosurfaces, ...) writer for OpenFOAM similarly to Håkon's IO library. Meaning, I'm writing HDF5 files with during runtime and generate the XDMF file with a python script afterwards.
It's not (yet) publicly available, but I'm happy to share it if you are interested in. (I actually should just put it to some public git repo.)

-Armin
Hi,

If it includes patches I would definitely be interested! Even if I don't choose to go with xdmf it would be interesting to see how you solved some of the issues I currently have. Right now if I use my function object from a custom app "foamToHDF5" then everything is fine. I can write in parallel and see no issues. However if I include my function object in say icoFoam I get and segmentation fault when when icoFoam does "finalize". The writing goes fine. It's just a bit unclean to exit on a segmenation fault. The only difference I can see is that my app includes hdf5.h and dynamically links libhdf5.so at compile time while icoFoam would do it at runtime. Is it something you've seen?

Another point I have is that by organizing the data very close to how foam already does simplifies converting back. We would have faces, owners, neighbours, points exactly as they are now. Is it possible with XDMF?

The link you posted to the discussion of polyhedral cells for XDF is private so I can't see it.

I can offer one point of experience from CGNS. At least in CGNS you can't mix polyhedral cells with structured types. For structured types (tetras, hexas and so on). All you need is a list of points for each cell. (it's actually slightly more complicated but not much). But for a polyhedral you need two lists. One defining all the faces in the mesh and one list defining the cells. (Although I've come to realize that defining the faces i a separate list is redundant.) In any case that makes merging a polyhedral reader with the current CGNS reader difficult since the structure is totally different. I suspect we might run in to similar issues if we implement polyhedrals in XDMF. But I have no experince of XDMF so I don't really know.

Best Regards
Nicolas
nsf is offline   Reply With Quote

Old   February 13, 2016, 09:29
Default
  #32
Senior Member
 
dkxls's Avatar
 
Armin
Join Date: Feb 2011
Location: Helsinki, Finland
Posts: 156
Rep Power: 19
dkxls will become famous soon enough
Just a few quick comments now, I will get back to you concerning the XDMF surface writer for OpenFOAM.

Quote:
Originally Posted by nsf View Post
The link you posted to the discussion of polyhedral cells for XDF is private so I can't see it.
The mailing list archives are now public, here the new link (I also changed the link in the original post):
http://www.kitware.com/pipermail/xdm...er/000895.html

Quote:
Originally Posted by nsf View Post
I can offer one point of experience from CGNS. At least in CGNS you can't mix polyhedral cells with structured types.
...
I suspect we might run in to similar issues if we implement polyhedrals in XDMF. But I have no experince of XDMF so I don't really know.
In XDMF you can actually mix different cell types by using TopologyType="Mixed", so there is no problem on that end. For more information see here:
http://www.xdmf.org/index.php/XDMF_Model_and_Format

Cheers,
Armin
dkxls is offline   Reply With Quote

Old   June 12, 2017, 06:29
Default
  #33
Senior Member
 
anonymous
Join Date: Aug 2014
Posts: 205
Rep Power: 13
ssss is on a distinguished road
Has anyone been able of updating this library to the new function objects structure of openfoam>3.0 ? I would like to contribute to the implementation of this function object in OpenFOAM v16 though it would be also nice to know if someone has already worked on this

When using OpenFOAM for big unsteady computations the amount of files outputted by OpenFOAM makes it impossible to use clusters with number of files limitations, therefore it seems really interesting to use HDF5 to write the solution data
ssss is offline   Reply With Quote

Old   June 25, 2017, 09:31
Default
  #34
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,981
Blog Entries: 45
Rep Power: 128
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
Quick note to ssss: In OpenFOAM+, they have been implementing the interface with ADIOS, for optimized data storage: http://www.openfoam.com/version-v161...ty-parallel-io

Nonetheless, support for HDF5 will likely be welcome too, given that having other options for IO is always good to have
wyldckat is offline   Reply With Quote

Old   June 27, 2017, 06:07
Default
  #35
Senior Member
 
anonymous
Join Date: Aug 2014
Posts: 205
Rep Power: 13
ssss is on a distinguished road
Quote:
Originally Posted by wyldckat View Post
Quick note to ssss: In OpenFOAM+, they have been implementing the interface with ADIOS, for optimized data storage: http://www.openfoam.com/version-v161...ty-parallel-io

Nonetheless, support for HDF5 will likely be welcome too, given that having other options for IO is always good to have
Hi @wyldckat,

Thank you for your answer I have already tryed to use ADIOS with OpenFOAMv16.12+ and we saw important reductions in the time used by the solver to write the fields. However, ADIOS does not change the file structure or the file count of the OpenFOAM's solution file.

When dealing with thousands of cores and unsteady simulations, file count can grow to millions of files pretty quickly, that's why hdf5 could be a good solution to the problem although the current HDF5 function object is not capable of reading HDF5 files into OpenFOAM. I will definitely try to implement this function object into OpenFOAM>3.0 when I have time
wyldckat likes this.
ssss is offline   Reply With Quote

Old   July 8, 2017, 14:21
Default
  #36
Retired Super Moderator
 
Bruno Santos
Join Date: Mar 2009
Location: Lisbon, Portugal
Posts: 10,981
Blog Entries: 45
Rep Power: 128
wyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to allwyldckat is a name known to all
Hi ssss,

Another quick note for you, in case you haven't seen it yet, a new feature was introduced into OpenFOAM's Foundation development repository yesterday: https://openfoam.org/news/parallel-io/

I haven't tested it yet, but the information provided there seems to indicate that this new feature will store each field into a single file for all time steps.

Best regards,
Bruno
beatlejuice likes this.
wyldckat is offline   Reply With Quote

Old   November 6, 2019, 09:35
Default
  #37
Member
 
Join Date: Nov 2013
Posts: 35
Rep Power: 13
beatlejuice is on a distinguished road
Hello everybody,

I want to spend some time until Christmas to update the IOh5Write library from Hakon so that it is compatible with new openfoam versions (e.g. OF6,7 or OFV1806/1812/1904) and also writes boundary data. I think it is a useful library and it is worth updating it and share it with the community so that it can also be improved by the community.

I would not consider myself a good programmer or a programmer at all, and that's why I want to ask the experts if somebody can give me some hints how to start best.

Is somebody maybe also interested in this and wants to collaborate?
Has somebody already extended the code to write out boundary data?

What I realized up to now:
Regarding OF6 the code in the outputFilterFunctionObject.H must be replaced and updated to the new OF structure. Still have not get the overview here where to attack =)

I appreciate any comments/help ... =)
beatlejuice is offline   Reply With Quote

Old   January 25, 2020, 06:12
Default
  #38
Member
 
Join Date: Nov 2013
Posts: 35
Rep Power: 13
beatlejuice is on a distinguished road
Hello dear openfoam community,

I managed to extend Hakon's code so that it is now possible to write out patch/boundary field data as well. It is only a prototype of code and therefore has some limitations. Although, it should be quite easy to get rid of the limitations, I first want to update the code in such a way that it is usable with newer openfoam versions ... lets say from openfoam6 or v1806 on (current state is that it works for openfoam versions 2.2.x and 2.3.x, only tested with 2.3.1). But right now I have no clue how to do that and I would really appreciate any help regarding that issue!!! I think the main part of work is done regarding the patch/boundary writing and it would be awesome if the community could help to get the code working in latest openfoam versions so that everybody can benefit from it. If the code works in latest OF versions, next step would be to optimize it in such a way that the h5 writing is more efficient. One main advantage over collated writing (fileHandler collated) is that we do not have to reconstruct the fields to be able to use the data in paraview (decomposed view in paraview is not working with collated fileHandler). For me, the reconstructing takes a long time because I need a lot of time steps in my simulations.

Attached you'll find the code "IOH5Write_b". The limitations are the same as for Hakon's code (only works in parallel, tensor fields not implemented, no clean simulation ending) but with some additional limitations for patch/boundary writing (works only for quadrilateral faces, does not work for boundaries with boundary condition "empty"). There are two tutorials included (h5cavity_b, h5pitzDaily_b) that show how to write patch/boundary data. After the simulation, you can use the python code "writeXDMF_b.py" to generate xdmf files for using internal field and patch/boundary field data in paraview.
Attached Files
File Type: gz IOH5Write_b.tar.gz (52.1 KB, 10 views)
wyldckat, zhangyan and blttkgl like this.
beatlejuice is offline   Reply With Quote

Old   October 7, 2020, 10:11
Default
  #39
Member
 
Join Date: Nov 2013
Posts: 35
Rep Power: 13
beatlejuice is on a distinguished road
Dear openfoam community,

I extended my previous code that was based on Hakon's work.

It is now possible to use newer versions of openfoam.

Like in the previous version it is possible to write patch or boundary data to the hdf5 archive (additionally to the internal field data).

I adapted the functionObject for openfoam6.0. The code might also work with other versions but it was only tested with openfoam6.

Attached you'll find the code "IOH5Write_b_OF6". Again, the limitations are the same as for Hakon's code (only works in parallel, tensor fields not implemented yet, no clean simulation ending) but with some additional limitations for patch/boundary writing (works only for quadrilateral faces, does not work for boundaries with boundary condition "empty"). Again, there are two OF6 tutorials included (cavity_IOh5Write_b_OFv6, pitzDaily_IOh5Write_b_OFv6) that show how to use the functionObject and to write patch/boundary data. After the simulation, you can use the python code "writeXDMF_b_OF6.py" to generate xdmf files for using internal field and patch/boundary field data in paraview.

I excluded the "h5WriteCloud.C" in Make/files because i get an error (see below) when compiling the code. I am not familiar with particle clouds so maybe the community can help to fix it and knows what Uc is and how to replace Uc so that the particle part of the code works in openfoam6.

Code:
h5Write_b_OFv6/h5WriteCloud.C:380:68: error: ‘class Foam::KinematicParcel<Foam::particle>’ has no member named ‘Uc’; did you mean ‘U’?
                    particleScalar3[3*i+0] = pIter().U().x() - pIter().Uc().x();
In the near-future, I want to make use of github repositories to share the code and make it possible for the community to develop it further if needed (like Hakon).
Attached Files
File Type: gz IOH5Write_b_OFv6.tar.gz (26.7 KB, 4 views)
joshwilliams likes this.
beatlejuice is offline   Reply With Quote

Old   October 8, 2020, 14:42
Default
  #40
Member
 
Join Date: Nov 2013
Posts: 35
Rep Power: 13
beatlejuice is on a distinguished road
Dear OpenFOAM community,

you can find the latest code "IOH5Write_b_OF6" (works with openfoam6) in the github branch:
https://github.com/ipat-fau/IOH5Writ...H5Write_b_OFv6

The previous code IOH5Write_b" (works with openfoam-2.3.1) can be found in the github branch:
https://github.com/ipat-fau/IOH5Write/tree/IOH5Write_b

I think Hakon's "IOHWrite" is a useful library and it is worth updating it and share it with the community so that it can also be improved by the community.

I hope it is useful and maybe helps somebody.

Cheers
lizzy likes this.
beatlejuice is offline   Reply With Quote

Reply


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
[Other] Multi species mass transport library [update] novyno OpenFOAM Community Contributions 111 November 10, 2021 00:37
problem loading UDF library in parallel cluster Veera Gutti FLUENT 8 July 26, 2016 08:24
Compiled library vs. inInclude Files, DSMC solver crashes after run GPesch OpenFOAM Programming & Development 8 April 18, 2013 08:17
[swak4Foam] Installing swak4Foam to OpenFOAM in mac Kaquesang OpenFOAM Community Contributions 22 January 21, 2013 12:51
OpenFOAM141dev linking error on IBM AIX 52 matthias OpenFOAM Installation 24 April 28, 2008 16:49


All times are GMT -4. The time now is 01:37.