No, I tried it only on Linux so far.
[WIP] updating to netgen 6.2.2004 (was smesh windows problem)
Re: [WIP] updating to netgen 6.2.2004 (was smesh windows problem)
Re: [WIP] updating to netgen 6.2.2004 (was smesh windows problem)
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.
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: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.
Code: Select all
shared_ptr<OCCGeometry> geo_ptr{&geo, [](OCCGeometry *) {}/*No-Op Deleter*/};
I guessed that the geometry might be necessary for creating second-order meshes. But I am not sure about this.
conda now builds with c++17 by default. So I didn't run into this issue.
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.
Re: [WIP] updating to netgen 6.2.2004 (was smesh windows problem)
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
Of course you can use the shared_ptr in a way to avoid to delete the object.it's possible to avoid the crash, as the raw-pointer is not deleted when the shared_ptr is deleted.
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;
}
Obviously not. If that was the case I would have got a crash in the surface meshing function of FreeCAD.I guessed that the geometry might be necessary for creating second-order meshes. But I am not sure about this.
On Ubuntu 18.04 the C++17 option must be explicitly turned on when using the latest STL features.conda now builds with c++17 by default. So I didn't run into this issue.
Re: [WIP] updating to netgen 6.2.2004 (was smesh windows problem)
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 );
Code: Select all
BRepMesh::Array1OfVertexOfDelaun srcVert( 1, 1 + nbP ), tgtVert( 1, 1 + nbP );
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
Re: [WIP] updating to netgen 6.2.2004 (was smesh windows problem)
No, it doesn't work out of the box. I still have to add
Code: Select all
set(CMAKE_CXX_STANDARD 17)
Re: [WIP] updating to netgen 6.2.2004 (was smesh windows problem)
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...wmayer wrote: ↑Sun May 10, 2020 8:30 am No, it doesn't work out of the box. I still have to addto the CMakeLists.txt file.Code: Select all
set(CMAKE_CXX_STANDARD 17)
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'
Re: [WIP] updating to netgen 6.2.2004 (was smesh windows problem)
it's not about compilers but compiler versions.I guess different compilers behaving differently?
MSVC usually doesn't need an explicit option to turn on the supported C++ version.Also we do not run into this with windows with the gihub actions configured for smesh...
For set_unexpected you possibly have to add: #include <exception>. See here: http://www.cplusplus.com/reference/exce ... nexpected/But still those two c++17 errors need to be resolved.
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;
};
Re: [WIP] updating to netgen 6.2.2004 (was smesh windows problem)
Conda build 0.19 build 21049 (https://github.com/FreeCAD/FreeCAD/rele ... -x86_64.7z) doesn't work.
I had to downgrade netgen to:
to get it to work again.
Mesh Design WB->Create mesh from shape gives:
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
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.
Re: [WIP] updating to netgen 6.2.2004 (was smesh windows problem)
We are currently trying to update smesh, but this is interrupted by a windows linking error.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:
https://github.com/LaughlinResearch/SMESH/pull/21