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?
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.
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.
E.g. find_package(HDF5 REQUIRED COMPONENTS C HL CXX) only finds C and HL.
-- 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):
Plugins/CFSReader/CMakeLists.txt:71 (paraview_add_plugin))
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 13.0.0.13000029
-- The CXX compiler identification is AppleClang 13.0.0.13000029
-- 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):
superbuild/projects/hdf5.cmake:6 (superbuild_add_project)
superbuild/cmake/SuperbuildMacros.cmake:1061 (include)
superbuild/CMakeLists.txt:170 (superbuild_process_dependencies)
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 find_package) and 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 :
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.
But I found no usage of H5Cpp.h in paraview, only in VTK/CMake/patches/99/FindHDF5.cmake
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.
@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.
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 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 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.
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.
We have the dependencies hdf5cpp which is prepared in paraview and boost filesystem, which is available.