[myusername]

as mentioned in my other thread I'm meshing the rotor of a windturbine. Besides the problem in the other thread I'm quite happy with my (patch depend) surface mesh of both the rotor and a zylinder which is the border for the boundary of the rotor.

My plan was to now do a delauney mesh. If I delete the Rotor and only mesh the zylinder (first the surface, then the volume), everything is fine. But with the rotor inside it acts as if there was a hole in the zylindermesh or something (Octree warns me of a hole but doesnt show it) and produces a giant Element around everything. But this only happens with the rotor inside (which doesnt touch the zylinder.) If I delete the rotor again and make a new volumemesh, it works.

I've tried all day and have no clue how to continue. Any ideas what I could try?


this is part of the log, but there is no error (and its really fast). it also says something about a bounding box

finished writing
status 0
Application is finished.
Unloaded unstructured domain
Current Coordinate system is global
Volume part name "inherited" runs flood fill (only for material points)
Number of material points: 1
Performing a mesh flood fill...
2558 elements are in part FLUID_ROTOR
Done mesh flood fill


The pictures show the mesh, the geometry and this big element. I used one mat.point but it also happened without any. If u need any other information, plz tell me.

[kad]

The big element is the initial element that the octree mesher starts with. So it seems octree is crashing right at the start.

Delaunay is failing because of your non conformal mesh in the rotor region. This is like a hole in the surface mesh. Delaunay needs a water tight mesh. That means your surface mesh must fully enclose your desired volume mesh. This also explains why Delaunay is working without the rotor. With deleting the rotor you deleted your problematic part of the mesh, too. Btw. you should use the checkmesh function to see better where problems occur.

[myusername]

Thanks a lot I think it actually worked what I dont understand: why does ICEM start an octree mesher at all, if I tell it to use delauney?

[kad]

As stated before delaunay needs a valid surface mesh. If there is none, delaunay tries to generate one. If the surface mesh method is set to patch independent ICEM runs the Octree mesher, throws the volume mesh out and then runs delaunay. But I am not 100% sure about this, as I never used delaunay that way.