[diamondx]

may i know where does the problem lie ??

[Far]

Ali this method is perfect. But I am not able to generate the volume mesh in the inner domain through denauly. No matter Whatever I do, I always get one big larger than inner domain!!!!

[diamondx]

how come ?? you did it already with tgrid ???

[Far]

Now I am trying to generate denauly using surface mesh as shown in previous posts. But volumes are leaking as can be seen attached Figs.
What is the problem? I checked through build topology and did not find any problem there.

[diamondx]

but if you remove the small box and consider the big beometry , wil it work ???
How about in t-grid ? will it do same ?

[Far]

Big box is deleted so there is only small box (should be same now? ). Tgrid does make the grid and even prisms successfully but there is some thing strange happening there as well (quite different than ICEM)

[Far]

Tgrid is making prisms in the first wing (from left to right on screen) correctly but it is penetrating prism inside the wing instead of extruding them on wing 2 and 3. See attached pics and files are also attached.

https://dl.dropbox.com/u/68746918/Inneronly.rar

[diamondx]

i get the same mesh as you

[PSYMN]

Originally Posted by Far

Now I am trying to generate denauly using surface mesh as shown in previous posts. But volumes are leaking as can be seen attached Figs.
What is the problem? I checked through build topology and did not find any problem there.

That doesn't look like leaking... It is some other problem. I have seen it before, but not for years. I recall it had something to do with an edit operation that triggered a bug where the nodes were mis-numbered during the save operation.

There are two sets of node numbers, the ones in the forground and the ones in the background...

Basically, it messes up the surface mesh node numbers in the background so that when delaunay runs it gets the wrong connectivity.

To fix it, try running the Edit mesh option to re-number nodes before running delaunay.

[Marinus]

Originally Posted by PSYMN

That doesn't look like leaking... It is some other problem. I have seen it before, but not for years. I recall it had something to do with an edit operation that triggered a bug where the nodes were mis-numbered during the save operation.

There are two sets of node numbers, the ones in the forground and the ones in the background...

Basically, it messes up the surface mesh node numbers in the background so that when delaunay runs it gets the wrong connectivity.

To fix it, try running the Edit mesh option to re-number nodes before running delaunay.

I am having the same problem, re-numbering the nodes did not fix it. Any other suggestions?

[Far]

Delete mesh and regenerate surface mesh. After that compute mesh.

PS: There is no clear pattern for this problem to happen

[Marinus]

Originally Posted by Far

Delete mesh and regenerate surface mesh. After that compute mesh.

PS: There is no clear pattern for this problem to happen

Eventually the problem did not show up when I first made an octree mesh, then after saving deleting the volume mesh and then computing the delauney volume mesh from the surface mesh.

Somewhere during saving the element numbers were changed automatically, however when I tried doing this manually it did not fix the problem. Maybe I did this wrong. Luckely I found a working solution .

Thanks for the help.

[Far]

What working solution you found?

[Marinus]

Originally Posted by Far

What working solution you found?

As I described, first I saved the octree mesh. Then deleted the volume mesh, then created Delaunay. Works for me.