[WIP] updating to netgen 6.2.2004 (was smesh windows problem)

[looo]

OK, I will try to link against the debug versions in the Libpack (12.1.2)

@sgrogan I guess this issue doesn't occur on windows:
https://github.com/NGSolve/netgen/issue ... -625151555

[sgrogan]

Is it necessary to have the source code available for RelWithDebInfo packages? If not, it should be possible to create debug packages of some of the dependencies. If it is easy to strip the debug symbols it should be possible to create special optional debug-packages.

The source code doesn't need to be distributed with the binaries. All the debug symbols are in .pdb files, so they are easily segregated.
The key is that the .pdb's are time stamp so they are tied to the .dll's by the actual build not just the version.
I've never tried on Linux, but for a while we provided them for FreeCAD on the PPA, it was just an option on Launchpad, and everything happened auto-magically.
Compilation time is increased.

[sgrogan]

@sgrogan I guess this issue doesn't occur on windows:
https://github.com/NGSolve/netgen/issue ... -625151555

Thanks. The link is interesting in the fact they want to set up FreeCAD in their test lab. The two projects share a lot of dependencies and I wonder if there's any synergy there?
I'm still going to try to compile netgen against occt 7.4 myself. apeltauer is updating the libpack and everything works except netgen, surprise. I'm not sure what version he was using but the latest is as good as any. It also may mean that we start using external SMesh in the libpack too.

[wmayer]

If it is ok, I am going to ask some basic c++ questions:

1. I need the OCCGenerateMesh function in 3 files. If I define this function in all 3 files I get multiple definitions (the cxx-files are compiled into one target). So what is the obvious way to define the function only in one file and use it in all 3 files.

This doesn't work of course because you have three object files with the function symbol and thus the linker will complain.

2. Defining the function in a header file and including it in all the 3 cxx files also results in redefinition errors.

It should work to declare the function as inline. But IMO the best practice is to keep everything in cxx files as you did it then.

edit: is it possible that this way the shared pointer deletes the raw pointer which was passed by reference and this leads to the segmentation fault?

Yes. Geo is passed as reference to OCCGenerateMesh and might be created on the stack. I don't know how SetGeometry is implemented but if this doesn't use a shared_ptr then you see the crash inside OCCGenerateMesh as soon as the shared_ptr is cleaned up because it's the last reference to the object. If SetGeometry uses a shared_ptr then you may get a crash at a later point because if OCCGeometry has been created on the stack then it will be destroyed automatically as soon as it leaves its scope.

In short: do not put an object to a shared_ptr or unique_ptr when it was created on the stack.

The actual question to me is how SetGeometry is implemented and do we really have to pass it to the generated mesh. In case it's not needed then the function can look like this:

Code: Select all

int OCCGenerateMesh(OCCGeometry& geo, shared_ptr<Mesh>& mesh, MeshingParameters& params)
    {
      geo.SetOCCParameters(occparam);
      auto result = geo.GenerateMesh(mesh, params);
      return result;
    }

[wmayer]

https://github.com/NGSolve/netgen/releases

It seems SMESH now requires OCC 7.4 because otherwise you get a build failure in StdMeshers_Projection_2D.cxx. But which gcc version does it require now? After 96% of the build I run into some weird build failure related to std::enable_if.

[wmayer]

netgen now requires C++17 and in order to build SMESH together with this netgen version it must be built with C++17, too. Therefore this line must be added to the top-level CMakeLists.txt file:

Code: Select all

set(CMAKE_CXX_STANDARD 17)

[wmayer]

But now there is still another problem. Every second time a mesh is created freecad crashes.

I have now successfully built netgen, smesh (btw I modified the file that causes a build problem with OCC 7.3) with your PR applied.

I also built FreeCAD using the external smesh option and had to manually modify some of the link.txt files in order to avoid linker errors due to hdf5.so.

At runtime I haven't seen any crashes when using the Netgen mesher.

[bernd]

But now there is still another problem. Every second time a mesh is created freecad crashes.

I have now successfully built netgen, smesh (btw I modified the file that causes a build problem with OCC 7.3) with your PR applied.

I also built FreeCAD using the external smesh option and had to manually modify some of the link.txt files in order to avoid linker errors due to hdf5.so.

At runtime I haven't seen any crashes when using the Netgen mesher.

on Windows only or on Linux too? How about FEM Netgen mesher? Does this still works too?

[wmayer]

on Windows only or on Linux too? How about FEM Netgen mesher? Does this still works too?

It uses some features of C++17. So, it's also required on Windows. I have tried the Netgen option of the Mesh workbench but when this works then the FEM netgen mesher very likely will work, too.

[sgrogan]

I have now successfully built netgen

Do you try to link against a Libpack? Even with the (U)CRT is it necessary to build/link the sub-dependencies. I guess yes at least for the C++17 stuff? Thanks in advance!