Make in openfoam v9 error

[jiaqiwang969]

Hi, WENOEXT,
Do you have a plan to update the WENOEXT to openfoam v9?

Now, there is a bug, below:

[ 54%] Building CXX object libWENOEXT/CMakeFiles/WENOEXT.dir/WENOUpwindFit/makeWENOUpwindFit.C.o
[ 55%] Building CXX object tests/Catch2/src/CMakeFiles/Catch2.dir/catch2/internal/catch_reporter_registry.cpp.o
/dssg/home/acct-medgm/medgm/projectUserDir-9/src/WENOEXT/libWENOEXT/WENOBase/reconstructRegionalMesh.C: In function 'Foam::autoPtr<Foam::fvMesh> Foam::reconstructRegionalMesh::reconstruct(const labelList&, const labelList&, const Foam::fvMesh&)':
/dssg/home/acct-medgm/medgm/projectUserDir-9/src/WENOEXT/libWENOEXT/WENOBase/reconstructRegionalMesh.C:172:13: error: no matching function for call to 'Foam::faceCoupleInfo::faceCoupleInfo(Foam::fvMesh&, Foam::fvMesh&, const scalar&, bool)'
             )
             ^
In file included from /opt/OpenFOAM/OpenFOAM-9/src/dynamicMesh/lnInclude/polyMeshAdder.H:44:0,
                 from /dssg/home/acct-medgm/medgm/projectUserDir-9/src/WENOEXT/libWENOEXT/WENOBase/reconstructRegionalMesh.H:41,
                 from /dssg/home/acct-medgm/medgm/projectUserDir-9/src/WENOEXT/libWENOEXT/WENOBase/reconstructRegionalMesh.C:30:
/opt/OpenFOAM/OpenFOAM-9/src/dynamicMesh/lnInclude/faceCoupleInfo.H:132:9: note: candidate: Foam::faceCoupleInfo::faceCoupleInfo(const Foam::polyMesh&, const labelList&, const Foam::polyMesh&, const labelList&)
         faceCoupleInfo
         ^~~~~~~~~~~~~~
/opt/OpenFOAM/OpenFOAM-9/src/dynamicMesh/lnInclude/faceCoupleInfo.H:132:9: note:   no known conversion for argument 2 from 'Foam::fvMesh' to 'const labelList& {aka const Foam::List<int>&}'
/opt/OpenFOAM/OpenFOAM-9/src/dynamicMesh/lnInclude/faceCoupleInfo.H:55:7: note: candidate: Foam::faceCoupleInfo::faceCoupleInfo(const Foam::faceCoupleInfo&)
 class faceCoupleInfo
       ^~~~~~~~~~~~~~
/opt/OpenFOAM/OpenFOAM-9/src/dynamicMesh/lnInclude/faceCoupleInfo.H:55:7: note:   candidate expects 1 argument, 4 provided
libWENOEXT/CMakeFiles/WENOEXT.dir/build.make:182: recipe for target 'libWENOEXT/CMakeFiles/WENOEXT.dir/WENOBase/reconstructRegionalMesh.C.o' failed
make[2]: *** [libWENOEXT/CMakeFiles/WENOEXT.dir/WENOBase/reconstructRegionalMesh.C.o] Error 1
make[2]: *** Waiting for unfinished jobs....

[Fracturist]

Hello Jiaqi,

I noticed that the error occurred after compiling some files for Catch2.

Have you tried building with -DCMAKE_BUILD_TYPE=Release to ignore tests? I think the library can work witout that part.

WENOEXT/CMakeLists.txt

Lines 243 to 249 in f45593a

	if (build_type_upper STREQUAL "RELEASE")
	message("Tests are NOT build for the release type")
	else()
	message("Building tests")
	message("This can be deactivated by using CMAKE_BUILD_TYPE=Release")
	add_subdirectory(tests)
	endif()

Best,

Fracturist

[jiaqiwang969]

Hello Jiaqi,

I noticed that the error occurred after compiling some files for Catch2.

Have you tried building with -DCMAKE_BUILD_TYPE=Release to ignore tests? I think the library can work witout that part.

WENOEXT/CMakeLists.txt

Lines 243 to 249 in f45593a

	if (build_type_upper STREQUAL "RELEASE")
	message("Tests are NOT build for the release type")
	else()
	message("Building tests")
	message("This can be deactivated by using CMAKE_BUILD_TYPE=Release")
	add_subdirectory(tests)
	endif()

Best,

Fracturist

Hi, Fracturist.
Actually, is Release type already. The error does not dispear.

	Build State
-------------------------------------------------------------------
Built state is: Release
Tests are NOT build for the release type

[JanGaertner]

I believe it has something to do with the mesh functions and maybe some names have changed from v8 to v9 or the function signature. I would need to look into that for a moment and see what changes had been made from v8 to v9. Generally, at some point the library wont be able to work for both versions as more and more they diverge and it would require a lot of pre processing macros to then switch between the versions.

[JanGaertner]

I probably get to it in the next few weeks but you can also have a look at it yourself. Try to see in which file and which function it fails, you can also use a IDE like visual code, it you are more familiar with this. Once you located the troublesome functions check the change logs of OpenFOAM v8 to v9 and try to find out what has changed for these functions. Alternatively, go to the documentation page and the Doxygen and look the class up and see how the function is called now or what arguments it requires.

When you can get it to compile with v9 you can create a pull request to merge your changes into this library.

[JanGaertner]

I found the issue. They have refactored the snappyHexMesh and polyMeshAddr functions
See commit 9e740b286ff3f2ce36cbdc08868a956d3f0c1ed6 of OpenFOAM v9 at: OpenFOAM/OpenFOAM-9@9e740b2

reconstructParMesh, fvMeshDistribute: Removed all geometric point merging

Geometric point merging has an inherent chance of failure that occurs
when a mesh contains valid distinct points that are closer together than
the supplied tolerance. It is beneficial to avoid such merging whenever
possible.

reconstructParMesh does not need explicit point merging any more. Points
may be duplicated temporarily when processor meshes are combined which
share points and edges but not faces. Ultimately, however,
reconstructParMesh reconstructs the entire mesh so everything eventually
gets face-connected and all point duplications get resolved.

fvMeshDistribute requires point-merging, as the entire mesh is not
constructed. However, since OpenFOAM/OpenFOAM-9@5d4c8f5, this process has been purely
topological and has not relied on any of the geometric merging processes
triggered by utilised code.

As such, all geometric point merging operations and tolerances have been
removed from these two implementations, as well as in lower level code
in faceCoupleInfo and polyMeshAdder. faceCoupleInfo has also had support
for face and edge splits removed as this was not being used. This change
will have improved the robustness of both reconstruction and
redistributuon and has greatly reduced the total amount of code
involved.

The only geometric tolerance-based matching still being performed by
either of these processes is as a result of coupled patch ordering in
fvMeshDistribute. It is possible that this is not necessary either
(though at present coupled patch ordering is certainly needed
elsewhere). This warrants further investigation.

This change substantially changes how the reconstructParMesh works. You would need to work through how the merge process is managed now and how to merge the connecting patches/faces.