I’m a developer of the free coupled field FEM and structural optimization tool openCFS https://www.opencfs.org
It originates in academia and is now free and open (MIT-License). Our data format is based on hdf5 and we used to have an own reader since paraview 3.x.
The reader has some useful features in handling complex valued datasets, transforming harmonic results to time animations, … - so it is slightly more than just reading data.
While I always have issues in bringing the plugin and paraview together, it all compiles and runs smoothly when this is done (just now with PV 10 on arm64 macOS). Especially for the three platforms Linux, Windows and macOS this is always a hassle.
My aim is to make our CFSReader part of the official paraview distribution and I’d like to start a discussion on this.
What makes things more complicated, is, that we are using the vtkMultiBlockDataSet which seems to be planned to be depreciated soon?
I’m ready to attempt to migrate this when this is ultimately necessary and clearly understand that the reader would be removed from paraview if I do not succeed with that. However having at least one official paraview binary with CFSReader would already be a great help and benefit.
So I have two questions:
- what is the way to bring our reader for openCFS to the official paraview release
- is our current usage of vtkMultiBlockDataSet a show stopper?
Hi and welcome @Fabian !
what is the way to bring our reader for openCFS to the official paraview release
The would depend on the dependencies of your reader. If there is none, it can be trivial with a simple MR into VTK/ParaVIew or into a ParaView plugin.
is our current usage of vtkMultiBlockDataSet a show stopper?
Definitelly not, while a transition to partitioned dataset will be needed at some point, integrating an existing code using multiblock is fine. I’d advocate to put your reader into a ParaView plugin in that case though.
That being said, the integration process is a bit complex so do not hesitate to reach out for help.
Thanks for the (positive) response! We have the dependencies hdf5cpp which is prepared in paraview and boost filesystem, which is available.
I’ll clean and document our plugin a little more and will then come back for further questions.
Great, do not hesitate to tag me, either here or on gitlab.
I hope I followed the right path: I forked paraview and created a branch there: https://gitlab.kitware.com/fabian.wein/para-view-cfs-reader-plugin/-/tree/add_CFSReader_plugin
There I added our plugin to Plugins. It is dirty work in progress and not cleaned yet.
I then create a superbuild with paraview_SOURCE_SELECTION=source and paraview_SOURCE_DIR set.
In principle I can build paraview and my plugin and it works! However I still struggle with hdf’s cpp. I could not figure out, how to trigger building hdf5 with cpp. Currently I configure it manually and additionally need to add the hdf5cpp lib manually.
find_package(HDF5 REQUIRED COMPONENTS C HL CXX) only finds C and HL.
I did not succeed with Aaron’s suggestion in how to enable hdf5cpp in superbuild?
Adding hdf5cpp to my vtk.module
-- HDF5 C compiler wrapper is unable to compile a minimal HDF5 program.
-- HDF5 CXX compiler wrapper is unable to compile a minimal HDF5 program.
-- Found HDF5: /opt/homebrew/Cellar/hdf5/1.12.1/lib/libhdf5.dylib;/Users/fwein/code/pv_10/sb_build_branch/install/lib/libhdf5.dylib;/Users/fwein/code/pv_10/sb_build_branch/install/lib/libhdf5_cpp.dylib;/Users/fwein/code/pv_10/sb_build_branch/install/lib/libhdf5.dylib (found version "1.12.1") found components: C HL CXX
CMake Error at CMake/ParaViewPlugin.cmake:1064 (message):
Failed to find the required module hdf5cpp.
Call Stack (most recent call first):
VTK::hdf5 in you vtk.module should be enough, but you should include the right file, which is:
Take a look at
VTK/IO/HDF/vtkHDFReaderImplementation.cxx for an example usage.
Are you sure, you use hdf5cpp in vtkHDFReaderImplementation.cxx?
Maybe the issue is because I’m in macOS on arm64, but I don’t think so.
I did a complete clean superbuild
LIBRARY_PATH=/opt/homebrew/lib cmake ../paraview-superbuild -Dsuperbuild_download_location=/Users/fwein/code/cfsdepscache/paraview -DENABLE_boost=ON -DENABLE_hdf5=ON -DENABLE_qt5=ON -DQt5_DIR=/opt/homebrew/Cellar/qt@5/5.15.2_1/lib/cmake/Qt5 -Dparaview_SOURCE_SELECTION=source -Dparaview_SOURCE_DIR=/Users/fwein/code/pv_10/sb_build_branch/superbuild/paraview/src
Re-run cmake no build system arguments
-- The C compiler identification is AppleClang 220.127.116.1100029
-- The CXX compiler identification is AppleClang 18.104.22.16800029
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /Library/Developer/CommandLineTools/usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /Library/Developer/CommandLineTools/usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check size of void*
-- Check size of void* - done
-- Found Git: /usr/bin/git (found version "2.32.0 (Apple Git-132)")
-- Determined source version for paraview: 5.10.0-730-g9d42d12261
-- Enabling cxx11 as requested.
-- Enabling boost as requested.
-- Enabling zlib for: hdf5
-- Enabling szip for: hdf5
-- Enabling hdf5 as requested.
-- Enabling nlohmannjson as requested.
-- Enabling qt5 as requested.
-- Enabling paraview as requested.
-- Building projects: cxx11, boost, zlib, szip, hdf5, nlohmannjson, qt5, paraview
CMake Warning (dev) at superbuild/cmake/SuperbuildMacros.cmake:213 (message):
Optional dependencies for hdf5 not found: hdf5cpp
Call Stack (most recent call first):
This warning is for project developers. Use -Wno-dev to suppress it.
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/fwein/code/pv_10/sb_build_killme
Using both targets
hdf5cpp (coming from a
VTK::hdf5 seems wrong. The clean way to do it would be that
VTK::hdf5 provides all needed components (that is C, HL and CXX).
Looking quickly into
VTK/ThirdParty/hdf5/CMakeLists.txt it seems it only provides HDF5 with C and HL :
COMPONENTS C HL <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
I don’t how easy (or hard) it is to make
VTK::hdf5 provide the
CXX component, so maybe integrating your plugin will not be as trivial as Mathieu first said.
hdf5cpp is given in
But I found no usage of H5Cpp.h in paraview, only in
It “only” is the question of enabling the existing hdf5 option but not the question of an additional external dependency.
In general I see two options:
- enable cpp dynamically or fixed in paraview
- I change our plugin to the C interface.
Can you please share your thoughts on the two possibilities? Probably you plan to go to hdf5_cpp internally anyway or you think, that the C api is just fine enough.
In that case, using the C api would be the safest way to go forward.
OK, I should not be that hard but will take some time. I’ll come back
@timothee.chabat I forgot to thank you for this insight, this explained a lot for me. When I’m done with the plugin I can offer the small patch removing remaining hdf5cpp artefacts from paraview to prevent future confusion.
Happy I could help ! Sounds cool thanks for your contribution
Just to clarify,
hdf5cpp is used by other superbuild projects, specifically ITK, and so should not be removed from the superbuild.
Fixing this in ParaView would be good I think.
hdf5cpp is a superbuild project, not a VTK module, so this won’t work. Note that
VTK::hdf5 only ever provides C bindings (never C++ bindings), so you won’t be able to use
VTK::hdf5 at all unless you migrate to a C-only usage.
I finished migrating to C-bindings yesterday. Just need some more code cleaning and testing.
I switched our hdf5 reader to c-api (incl. high level). I also cleaned the cmake configuration a lot. The reader is not ready, I want to do some more code cleanup.
I renamed my fork of ParaView to ParaView: https://gitlab.kitware.com/fabian.wein/para-view-cfs-reader-plugin/-/tree/add_CFSReader_plugin. I’m not sure if this worked but it is not easy to create a new fork once there is already a fork.
I build superbuild with
-DENABLE_boost=ON -DENABLE_hdf5=ON -DENABLE_qt5=ON -DQt5_DIR=... -Dparaview_SOURCE_SELECTION=source -Dparaview_SOURCE_DIR=...
My plugin is recognized, but in
superbuild/paraview/build/ it has
PARAVIEW_PLUGIN_ENABLE_CFSReader:BOOL=OFF. When I enable it an do make there, I get a paraview where I can load the the reader and it works A make in the superbuild build directory does not have any effect.
How are plugin builds enabled automatically?
Hi @Fabian ,
You need to rename your fork, not only the branch. It’s in the general settings/housekeeeping of your project.
How are plugin builds enabled automatically?
I did already rename the fork as you described, but it does not change the link name. If it does not work I could register with another login and create a new fork. Currently a second fork seems no really possible with gitlab.
Thanks for the hint with enabling. I greped for some plugins (e.g. GmshIO) but did not check that I picked the ones which were not enabled.