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.

https://github.com/WENO-OF/WENOEXT/blob/f45593abd480d9f1ea2056cefd2f6626bebab497/CMakeLists.txt#L243-L249

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.

https://github.com/WENO-OF/WENOEXT/blob/f45593abd480d9f1ea2056cefd2f6626bebab497/CMakeLists.txt#L243-L249

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: https://github.com/OpenFOAM/OpenFOAM-9/commit/9e740b286ff3f2ce36cbdc08868a956d3f0c1ed6

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 https://github.com/OpenFOAM/OpenFOAM-9/commit/5d4c8f5d5f50c911b7fee012513eb2e06781a19b, 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.