[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...)
wmayer
Site Admin
Posts: 16261
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 11:10 pm

sgrogan wrote:
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!
No, I tried it only on Linux so far.
User avatar
looo
Posts: 3424
Joined: Mon Nov 11, 2013 5:29 pm

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

Postby looo » Sat May 09, 2020 8:10 am

wmayer wrote:
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.
It's possible that we lost occt7.3 support by updating smesh to occt7.4... If there is a way to support both (occt7.3 and occt7.4) at the same time it would be nice to have this applied on the SMESH repo.
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.
Yes, I guess the better solution would be to use a shared_ptr in smesh directly. But this might lead to a lot more work. By creating the shared pointer in this way:

Code: Select all

shared_ptr<OCCGeometry> geo_ptr{&geo, [](OCCGeometry *) {}/*No-Op Deleter*/};
it's possible to avoid the crash, as the raw-pointer is not deleted when the shared_ptr is deleted.
wmayer wrote:
Fri May 08, 2020 6:41 am
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:
I guessed that the geometry might be necessary for creating second-order meshes. But I am not sure about this.
wmayer wrote:
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:
conda now builds with c++17 by default. So I didn't run into this issue.
wmayer wrote:
Fri May 08, 2020 10:30 am
At runtime I haven't seen any crashes when using the Netgen mesher.
Yes, I asked also on github about the mentioned crash. The solution is explained here:
https://github.com/NGSolve/netgen/issue ... -625181354
https://github.com/LaughlinResearch/SME ... 6024dR4202

Thanks so far. I am currently trying to build netgen for windows, but see some issues (unsupported operators). Not yet sure what this is about.

edit: the appimage should already include netgen 6.2.2004 and the patched smesh, in case someone wants to test it.
wmayer
Site Admin
Posts: 16261
Joined: Thu Feb 19, 2009 10:32 am

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

Postby wmayer » Sat May 09, 2020 11:09 am

looo wrote:
Sat May 09, 2020 8:10 am
It's possible that we lost occt7.3 support by updating smesh to occt7.4... If there is a way to support both (occt7.3 and occt7.4) at the same time it would be nice to have this applied on the SMESH repo.
As a quick hack I only commented out the problematic code. A cleaner solution is to use the OCC version preprocessor macro and for 7.3.0 or older disable the include of IMeshData_Types.hxx.

The second part is basically to disable the code of the morph() function that uses some classes of IMeshData. I don't know if there is an easy way to backport the code to OCC 7.3.

The only affected file is StdMeshers_Projection_2D.cxx
it's possible to avoid the crash, as the raw-pointer is not deleted when the shared_ptr is deleted.
Of course you can use the shared_ptr in a way to avoid to delete the object.
In the meantime I looked through the netgen plugin code of smesh where OCCGenerateMesh is used and in all cases the OCCGeometry instance is created on the stack. So, it's potentially dangerous to put it into a shared_ptr and pass it to the Mesh.
The point is that OCCGeometry will be destroyed as soon as the function where it's created is left and thus the raw-pointer inside the shared_ptr of the netgen::Mesh class will become dangling.

Here is the commit of netgen that has removed the global function OCCGenerateMesh and it's basically about reduction of code duplication.
The function NetgenGeometry :: GenerateMesh does quite the same as OCCGenerateMesh and I couldn't see that NetgenGeometry::SetGeometry is used anywhere there. The only example I found where SetGeometry is used is the Python wrapper.

So, to me it looks superfluous to use SetGeometry inside OCCGenerateMesh and thus it's sufficient to implement it like:

Code: Select all

int OCCGenerateMesh(OCCGeometry& geo, shared_ptr<Mesh>& mesh, MeshingParameters& params)
    {
      geo.SetOCCParameters(occparam);
      auto result = geo.GenerateMesh(mesh, params);
      return result;
    }
I guessed that the geometry might be necessary for creating second-order meshes. But I am not sure about this.
Obviously not. If that was the case I would have got a crash in the surface meshing function of FreeCAD.
conda now builds with c++17 by default. So I didn't run into this issue.
On Ubuntu 18.04 the C++17 option must be explicitly turned on when using the latest STL features.
wmayer
Site Admin
Posts: 16261
Joined: Thu Feb 19, 2009 10:32 am

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

Postby wmayer » Sat May 09, 2020 11:28 am

wmayer wrote:
Sat May 09, 2020 11:09 am
I don't know if there is an easy way to backport the code to OCC 7.3.
I had a closer look at it and it's very easy to backport it to OCC 7.3. Inside the function morph() this line

Code: Select all

IMeshData::Array1OfVertexOfDelaun srcVert( 1, 1 + nbP ), tgtVert( 1, 1 + nbP );
must be replaced with

Code: Select all

BRepMesh::Array1OfVertexOfDelaun srcVert( 1, 1 + nbP ), tgtVert( 1, 1 + nbP );
So, the whole patch would be:

Code: Select all

#include "Standard_Version.hxx"
#if OCC_VERSION_HEX >= 0x070400
#include <IMeshData_Types.hxx>
#endif

Code: Select all

#if OCC_VERSION_HEX >= 0x070400
    IMeshData::Array1OfVertexOfDelaun srcVert( 1, 1 + nbP ), tgtVert( 1, 1 + nbP );
#else
    BRepMesh::Array1OfVertexOfDelaun srcVert( 1, 1 + nbP ), tgtVert( 1, 1 + nbP );
#endif
User avatar
looo
Posts: 3424
Joined: Mon Nov 11, 2013 5:29 pm

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

Postby looo » Sat May 09, 2020 5:23 pm

wmayer wrote:
Sat May 09, 2020 11:28 am
I had a closer look at it and it's very easy to backport it to OCC 7.3. Inside the function morph() this line
Thanks, I added these changes to the PR. It would be nice to see if this works now without modification for your configuration.
wmayer
Site Admin
Posts: 16261
Joined: Thu Feb 19, 2009 10:32 am

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

Postby wmayer » Sun May 10, 2020 8:30 am

looo wrote:
Sat May 09, 2020 5:23 pm
wmayer wrote:
Sat May 09, 2020 11:28 am
I had a closer look at it and it's very easy to backport it to OCC 7.3. Inside the function morph() this line
Thanks, I added these changes to the PR. It would be nice to see if this works now without modification for your configuration.
No, it doesn't work out of the box. I still have to add

Code: Select all

set(CMAKE_CXX_STANDARD 17)
to the CMakeLists.txt file.
User avatar
looo
Posts: 3424
Joined: Mon Nov 11, 2013 5:29 pm

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

Postby looo » Sun May 10, 2020 6:32 pm

wmayer wrote:
Sun May 10, 2020 8:30 am
No, it doesn't work out of the box. I still have to add

Code: Select all

set(CMAKE_CXX_STANDARD 17)
to the CMakeLists.txt file.
You are right this has to be added. Not sure why I didn't run into this with linux in the first run. I guess different compilers behaving differently? Also we do not run into this with windows with the gihub actions configured for smesh...

But still those two c++17 errors need to be resolved.

Code: Select all

../inc/Utils_ExceptHandlers.hxx:44:22: error: no type named 'set_unexpected' in namespace 'std'
  ~Unexpect() { std::set_unexpected(old); }
  
  ..\inc\GEOMUtils.hxx(119): error C2039: 'binary_function': is not a member of 'std'
wmayer
Site Admin
Posts: 16261
Joined: Thu Feb 19, 2009 10:32 am

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

Postby wmayer » Sun May 10, 2020 8:27 pm

I guess different compilers behaving differently?
it's not about compilers but compiler versions.
Also we do not run into this with windows with the gihub actions configured for smesh...
MSVC usually doesn't need an explicit option to turn on the supported C++ version.
But still those two c++17 errors need to be resolved.
For set_unexpected you possibly have to add: #include <exception>. See here: http://www.cplusplus.com/reference/exce ... nexpected/
binary_function is declared deprecated since C++11 and has been removed in C++17 See here: https://en.cppreference.com/w/cpp/utili ... y_function

I guess the smesh code uses it by deriving from it. So, it might be sufficient to just remove the code:

Code: Select all

  struct CompareShapes : public std::binary_function<TopoDS_Shape, TopoDS_Shape, bool>
  {
    CompareShapes (bool isOldSorting)
      : myIsOldSorting(isOldSorting) {}

    bool operator() (const TopoDS_Shape& lhs, const TopoDS_Shape& rhs);

    typedef NCollection_DataMap<TopoDS_Shape, std::pair<double, double> > GEOMUtils_DataMapOfShapeDouble;
    GEOMUtils_DataMapOfShapeDouble myMap;
    bool myIsOldSorting;
  };
==>

Code: Select all

  struct CompareShapes
  {
    CompareShapes (bool isOldSorting)
      : myIsOldSorting(isOldSorting) {}

    bool operator() (const TopoDS_Shape& lhs, const TopoDS_Shape& rhs);

    typedef NCollection_DataMap<TopoDS_Shape, std::pair<double, double> > GEOMUtils_DataMapOfShapeDouble;
    GEOMUtils_DataMapOfShapeDouble myMap;
    bool myIsOldSorting;
  };
Btw, it's interesting that it's deprecated since C++11 because in FreeCAD we use it in several places too and I never got a compiler warning about it. So, it's good to know that we must port the corresponding code to C++17.
UR_
Posts: 1188
Joined: Tue Jan 03, 2017 8:42 pm

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

Postby UR_ » Thu May 14, 2020 1:08 pm

Conda build 0.19 build 21049 (https://github.com/FreeCAD/FreeCAD/rele ... -x86_64.7z) doesn't work.

I had to downgrade netgen to:

Code: Select all

(freecad) C:\Users\aio\Miniconda3>conda list netgen
# packages in environment at C:\Users\aio\Miniconda3\envs\freecad:
#
# Name                    Version                   Build  Channel
netgen                    6.2.1808        py38hb990d29_1007    conda-forge
to get it to work again.


Mesh Design WB->Create mesh from shape gives:

Loading GUI of MeshPart module... done
Traceback (most recent call last):
File "<string>", line 1, in <module>
<class 'ImportError'>: DLL load failed while importing MeshPart: The specified procedure could not be found.
User avatar
looo
Posts: 3424
Joined: Mon Nov 11, 2013 5:29 pm

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

Postby looo » Thu May 14, 2020 1:43 pm

UR_ wrote:
Thu May 14, 2020 1:08 pm
Conda build 0.19 build 21049 (https://github.com/FreeCAD/FreeCAD/rele ... -x86_64.7z) doesn't work.

I had to downgrade netgen to:
We are currently trying to update smesh, but this is interrupted by a windows linking error.
https://github.com/LaughlinResearch/SMESH/pull/21