not at the moment. My goal is to provide packages for linux (ubuntu/ arch) first.
I did not know this. So the latest freecad won’t work with python2.7 in windows?
As far as I know, there is no official pyside for python3.5 in windows… So maybe we will have to wait until pyside2 is working and freecad has ported to python3 and qt5…
In the lib packs Peterl94 has compiled python2.7 with VC12. This is where the version hassle that ickby was referring to comes from. All of the readily accessible compiled extensions are compiled with VC9 and hence don’t work with current Freecad. It should work with 0.16 x86 release FreeCAD as this was compiled with VC9.
Currently I am trying to compile the latest source of freecad with occt7. My problem is now with netgen. Netgen is build with cmake: https://anaconda.org/freecad/netgen/6.1/download/linux-64/netgen-6.1-py27_1.tar.bz2. So I don’t know if this is a problem with the netgen-cmake or if it is a linking error:
NETGENPlugin_NETGEN_3D.cpp:(.text+0x2fb9): Nicht definierter Verweis auf `netgen::mparam'
NETGENPlugin_NETGEN_3D.cpp:(.text+0x3052): Nicht definierter Verweis auf `vtable for netgen::NgException'
NETGENPlugin_NETGEN_3D.cpp:(.text+0x333f): Nicht definierter Verweis auf `netgen::multithread'
NETGENPlugin_NETGEN_3D.cpp:(.text+0x33e3): Nicht definierter Verweis auf `netgen::NgException::~NgException()'
NETGENPlugin_NETGEN_3D.cpp:(.text+0x3408): Nicht definierter Verweis auf `netgen::NgException::~NgException()'
NETGENPlugin_NETGEN_3D.cpp:(.text+0x342c): Nicht definierter Verweis auf `netgen::multithread'
Has anyone run into a similar situation?
I think nglib has to be patched to support OCCT7/SMESH7. wmayer provides the patch for Netgen 5.1 here: http://forum.freecadweb.org/viewtopic.php?f=17&p=127000#p126997
I tried to compile the Netgen master branch on Win because it has similar changes but I was unsuccessful, and I’m back to trying with 5.1.
vejmarie also posted a patched branch that was successful on linux Netgen 5.3 I think. I’ll find the link.
thanks, I have added another patch to the conda build process, but still the same problem with netgen.
This are the patches from vejmarie: https://github.com/looooo/FreeCAD_Conda/blob/master/netgen/netgen.patch
and here is the new one from wmayer: https://github.com/looooo/FreeCAD_Conda/blob/master/netgen/freecad.patch
cmake choose the wrong headers(system instead of conda). But now I see why you have switched to an older version of netgen 
.
anaconda/conda-bld/work/src/3rdParty/salomesmesh/src/NETGENPlugin/NETGENPlugin_NETGEN_2D_ONLY.cpp:478:90: error: invalid initialization of reference of type ‘std::shared_ptr<netgen::Mesh>&’ from expression of type ‘netgen::Mesh*’
err = netgen::OCCGenerateMesh(occgeom, ngMesh, netgen::mparam, startWith, endWith);
Had some time to work on conda builds again. It seems the smesh build is working now, but the compilation now stops at the fem-module.
This is the error:
In file included from ~/anaconda/conda-bld/._1473004468427/work/src/Mod/Fem/App/FemMeshShapeNetgenObject.cpp:45:0:
~/anaconda/conda-bld/._1473004468427/work/src/3rdParty/salomesmesh/inc/NETGENPlugin_Mesher.hxx:40:19: fatal error: nglib.h: Datei oder Verzeichnis nicht gefunden
compilation terminated.
src/Mod/Fem/App/CMakeFiles/Fem.dir/build.make:426: die Regel für Ziel „src/Mod/Fem/App/CMakeFiles/Fem.dir/FemMeshShapeNetgenObject.cpp.o“ scheiterte
The nglib headers are in include/netgen/nglib/nglib.h. Is it necessary to tell cmake to include this directory for the fem wb?
The compilation is now working. This had to be done for the fem libs (maybe this could be applied to master?)
diff --git a/src/Mod/Fem/App/CMakeLists.txt b/src/Mod/Fem/App/CMakeLists.txt
index 89989fb..2c129e3 100755
--- a/src/Mod/Fem/App/CMakeLists.txt
+++ b/src/Mod/Fem/App/CMakeLists.txt
@@ -22,6 +22,7 @@ include_directories(
${XercesC_INCLUDE_DIRS}
${SMESH_INCLUDE_DIR}
${VTK_INCLUDE_DIR}
+ ${NETGEN_INCLUDE_DIRS}
)
But I can’t mesh with netgen. A mesh object is created, but nothing is displayed on the 3d-view. There is no error message or warning. Netgen does work outside of freecad (with setting NETGENDIR to the dir containing ng.tcl.) Any ideas what is missing?
Can anyone point me to the file (fem or Mesh) where the netgen-mesher is called.
a question for the c++ experts:
To get freecad work with the latest netgen I had to introduce things like this:
#if NETGEN_VERSION >=6
std::shared_ptr<netgen::Mesh> mesh_ptr(ngMesh);
err = netgen::OCCGenerateMesh(occgeom, mesh_ptr, netgen::mparam, startWith, endWith);
#elif NETGEN_VERSION > 4
err = netgen::OCCGenerateMesh(occgeom, ngMesh, netgen::mparam, startWith, endWith);
#else
char *optstr = 0;
err = netgen::OCCGenerateMesh(occgeom, ngMesh, startWith, endWith, optstr);
#endif
My question is: mesh_ptr is used only to satisfy the function attributes. After this function call the mesh_ptr isn’t used any more. So it is deleted after the function call? And then the ngMesh is also deleted? Could this be the reason why no mesh is shown?
Is there a way to delete the shared_ptr without deleting the *pointer ?
You don’t delete a shared ptr, it gets deleted automatically when it goes out of scope (when you leave your function). The purpose of this shared ptr is Reference counting: when the Last one gets out of scope it deletes the internal Pointer.
This means the Mesh stays valid as long as netgen internally holds one of those shared ptr s. It don’t tjink it does from your Small Code slipped. Hence you need to Store the shared ptr somewhere to ensure that at least one of those survives the whole livetime it is needed.
The problem starts because netgen::OCCGenerateMesh has changed its interface where the second parameter is now a shared_ptr instead of Mesh*. This affects the code throughout the Netgen plugin of smesh.
Important to know when working with shared_ptr is that once it holds an object you must adjust the interface of functions to replace a Mesh* with shared_ptr too when it internally expects a shared_ptr because otherwise you confuse the reference counter and get a dangling pointer in the calling instance. But this will likely cause a crash and not an empty mesh.
Example:
class Mesh
{
public:
Mesh()
{
i=0;
}
~Mesh()
{
}
void func()
{
i++;
}
private:
int i;
};
void useMesh(Mesh* p)
{
std::shared_ptr<Mesh> u(p);
u->func();
} // <<== here the Test object will be destroyed
int main()
{
std::shared_ptr<Mesh> t(new Mesh);
Mesh*p = t.get();
useMesh(p);
Mesh*q = t.get(); // <<== t holds a dangling pointer now
q->func();
}
So, in the smesh netgen code there are a few classes that internally only has a Mesh* and this must also be replaced with a shared_ptr.
Last weekend I was also working to improve the Netgen cmake checks and therefore had to try netgen v6. I made the same experience that the mesh is empty and stumbled across the same issue as you. For testing purposes I added an “exit(0);” at this code bloc but FreeCAD didn’t terminate. So, this means the code part is never executed and there must be other reasons for the empty mesh.
Thanks for the information.
Regarding the shared pointers: there is also a way to suppress the deletion of the pointer…:
http://stackoverflow.com/questions/20131877/how-do-you-make-stdshared-ptr-not-call-delete
http://de.cppreference.com/w/cpp/memory/shared_ptr/shared_ptr
template< class Y, class Deleter >
shared_ptr( Y* ptr, Deleter d );
Wouldn’t this work in this case?
sounds not good. Have you done this on all the cases? There are more then one implementation of NETGENPlugin…::Compute.
Wouldn’t this work in this case?
Yes, this should do the trick.
sounds not good. Have you done this on all the cases? There are more then one implementation of NETGENPlugin…::Compute.
No. I started to change the interface of NETGENPlugin_NETGEN_3D::compute but then had to change more and more. Since my main goal was to improve the cmake netgen check I reverted this part. Here you can see the changes I made so far: https://github.com/wwmayer/FreeCAD/commit/481e340c78251eb0a4ba98902b1fbbbb7ac29481
A backtrace from creating a mesh with mesh-design workbench and netgen6:
#0 0x00007fff579f3b7b in netgen::OCCGenerateMesh (geom=..., mesh=..., mparam=..., perfstepsstart=1, perfstepsend=1)
from /home/lo/anaconda/envs/fc_2/lib/././libocc.so
#1 0x00007fff5de1dd17 in NETGENPlugin_Mesher::Compute (this=0x7fffffff9ee0) from /home/lo/anaconda/envs/fc_2/lib/./libNETGENPlugin.so
#2 0x00007fff5de52030 in NETGENPlugin_NETGEN_2D::Compute (this=0x2cbe1e0, aMesh=..., aShape=...)
from /home/lo/anaconda/envs/fc_2/lib/./libNETGENPlugin.so
#3 0x00007fff5d0c7d2e in SMESH_subMesh::ComputeStateEngine (this=0x2cbe6c0, event=1) from /home/lo/anaconda/envs/fc_2/lib/./libSMESH.so
#4 0x00007fff5cf68f96 in SMESH_Gen::Compute (this=0x2ccaa50, aMesh=..., aShape=..., aShapeOnly=false, anUpward=false, aDim=MeshDim_3D,
aShapesId=0x0) from /home/lo/anaconda/envs/fc_2/lib/./libSMESH.so
#5 0x00007fff5e10769a in MeshPart::Mesher::createMesh (this=0x7fffffffb1b0) from /home/lo/anaconda/envs/fc_2/lib/MeshPart.so
#6 0x00007fff5e0efd92 in MeshPart::Module::meshFromShape (this=0x2b6cc70, args=..., kwds=...) from /home/lo/anaconda/envs/fc_2/lib/MeshPart.so
#7 0x00007fff5e0f5a3f in Py::ExtensionModule<MeshPart::Module>::invoke_method_keyword (this=0x2b6cc70, method_def=0x2b6cee0, args=...,
keywords=...) from /home/lo/anaconda/envs/fc_2/lib/MeshPart.so
Seems the error is somewhere in the libocc.so from netgen.
I have created a pull-request for the shared pointer stuff so it doesn’t get lost: https://github.com/FreeCAD/FreeCAD/pull/277
any ideas how to debug the netgen stuff? I tried to place std::cout in the netgen plugin but nothing got printed. I also have build netgen in debug mode, but gdb doesn’t show anything related to netgen.
I tried to place std::cout in the netgen plugin but nothing got printed.
Use std::cerr instead.
thanks, I have tried to debug with std::cerr. It seems that the problem is at the first call to OCCGenerateMesh. And in this function the crash happen here: https://github.com/looooo/netgen/blob/master/libsrc/occ/occgenmesh.cpp#L1294
Looking at the smesh implementation the shared pointer holds a NULL. Is it a problem to set a member of a shared NULL pointer?
Looking at the smesh implementation the shared pointer holds a NULL. Is it a problem to set a member of a shared NULL pointer?
Of course. OCCGenerateMesh expects a pointer to an existing Mesh instance. If it’s a NULL pointer then trying to access a member variable causes a segmentation fault. So, the question is why in NETGENPlugin_Mesher::Compute() is the member “_ngMesh” NULL?
in older versions of netgen a new mesh was created inside the OCCGenerateMesh function. https://github.com/vejmarie/netgen_5.3.1_occt7/blob/master/libsrc/occ/occgenmesh.cpp#L1283.