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

This subforum is specifically to discuss packaging issues on different platforms (windows, mac, linux), and using different packaging systems (conda, etc...)
User avatar
looo
Posts: 3432
Joined: Mon Nov 11, 2013 5:29 pm

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

Postby looo » Thu May 07, 2020 10:34 am

sgrogan wrote:
Wed May 06, 2020 10:39 pm
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
User avatar
sgrogan
Posts: 5989
Joined: Wed Oct 22, 2014 5:02 pm

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

Postby sgrogan » Thu May 07, 2020 10:52 pm

looo wrote:
Thu May 07, 2020 6:29 am
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.
User avatar
sgrogan
Posts: 5989
Joined: Wed Oct 22, 2014 5:02 pm

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

Postby sgrogan » Thu May 07, 2020 11:00 pm

looo wrote:
Thu May 07, 2020 10:34 am
@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
Site Admin
Posts: 16309
Joined: Thu Feb 19, 2009 10:32 am

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

Postby wmayer » Fri May 08, 2020 6:41 am

looo wrote:
Tue May 05, 2020 11:43 am
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
Site Admin
Posts: 16309
Joined: Thu Feb 19, 2009 10:32 am

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

Postby wmayer » Fri May 08, 2020 8:30 am

looo wrote:
Sat May 02, 2020 5:36 pm
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
Site Admin
Posts: 16309
Joined: Thu Feb 19, 2009 10:32 am

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

Postby wmayer » Fri May 08, 2020 9:03 am

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
Site Admin
Posts: 16309
Joined: Thu Feb 19, 2009 10:32 am

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

Postby wmayer » Fri May 08, 2020 10:30 am

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.
User avatar
bernd
Posts: 10731
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland

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

Postby bernd » Fri May 08, 2020 10:33 pm

wmayer wrote:
Fri May 08, 2020 10:30 am
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
Site Admin
Posts: 16309
Joined: Thu Feb 19, 2009 10:32 am

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

Postby wmayer » Fri May 08, 2020 10:39 pm

bernd wrote:
Fri May 08, 2020 10:33 pm
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.
User avatar
sgrogan
Posts: 5989
Joined: Wed Oct 22, 2014 5:02 pm

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

Postby sgrogan » Fri May 08, 2020 10:56 pm

wmayer wrote:
Fri May 08, 2020 10:30 am
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!