[ICEM] Help with fixing imported IGES model
 

Hi,

I need to make a tetra/prism mesh around a half-aircraft model. The IGES CAD file is available to download from http://aaac.larc.nasa.gov/tsab/cfdla...op4/grids.html

Also on this webpage is a gridding guidelines for specifiying element sizes and clustering.

So using this information and trying to generate the mesh ICEM states that there's a hole in the geometry. Before meshing I used the Build Topology with a tolerance of 0.2, lower values don't pick up all the edges correctly.

I'm unable to find the hole for it to be fixed. Is there anyway that ICEM can do this automatically for me?

Thanks.

PSYMM, if you read this there's also an ANSYS presentation (http://aaac.larc.nasa.gov/tsab/cfdla...sentations.htm) as part of the Drag Prediction Workshop (see the website) with your name on it. Would you have any extra advice for making the three tetra/prism grids (my computer isn't up to making the extra fine grid)?

Can anyone else see if they can successfully open one of these NASA IGES files (http://aaac.larc.nasa.gov/tsab/cfdla...DPW4-geom.html) in DesignModeler?

It's of an aircraft, but I'm finding that the wing/fuselge section does not appear.

Thanks.

I tried the first model and it mostly came in, but there was some issue with the rear end of the fuselage...

We have done all these AIAA DPW F6 models before, so I am not sure why there would be a problem with these files now... Although I do recall getting Catia files before. I passed this on to the product manager.

As for your first querry...

Remember, leakage just means that during flood fill, ICEM CFD can find a path from one material point to another without any shells blocking the way.

When ICEM CFD finds leakage, it should give you some options. If you choose to fix it, you will see the leakage path and can find where it passed thru the "surface". Look for missing surfaces, holes or gaps. Also check to see if your material point was on the surface or perhaps there were two material points in a region (maybe it is not actually a hole, but rather that the material points are not correct)... Alternatively, you can just keep the surface mesh (dump the volume mesh)... Then run a single edges check to find holes. After fixing up the surface mesh, smoothing, etc., you can run a delaunay fill to get new tetras.

As for build topology, With models like this (large far fields, tiny aircraft), a single build topo tolerance isn't very practical. You want a larger tolerance to walk over the large areas and a smaller tolerance so you don't collapse the small things. This can be done. Under Build Diagnostic topology, set the tolerance small enough to capture your smallest features... This may still leave some yellow edges though. So lets scroll down and turn on the "single curve cleanup" option. Here you can set a second larger tolerance that will clean up any remaining gaps without collapsing smaller surfaces that were already taken care of...

Thanks Simon,

I used a Build Topology Tolerance = 0.2 and switched on the Single Curve Cleanup check box, which had a Single Edge Tolerance = 0.4 (these numbers were the default values that appeared). Now the edges of the aircraft are the colours I'd expect (yellow around the fuselage and red everywhere else).

Now, I'm puzzled on how to apply varying grid spacings along the wing & tail chord and span. The gridding guidelines (see the hyperlink in my first post) state that:

i) Chordwise spacing for wing and tail leading edge ~0.1% local chord.

ii) Wing and tail spanwise spacing at root ~0.1% local semispan.

iii) Wing and tail spanwise spacing at tip ~0.1% local semispan.

I find points ii and iii a bit weird because spanwise grid spacing will increase at the wing and tail tips were vortical motion will occur so would have thought smaller spacing should be used to capture gradients.

Anyway, for my first try I applied Curve Mesh Setups to the chordwise curves (3 on the wing & 2 on the tail) with bunching at the leading and trailing edges to fulfill i). But the Help Guide says Octree does not use Curve Bunching. But this would not work anyway as only the bunching would be applied to the curves and not the whole wing & tail.

Next, I tried Surface Mesh Setup on the wing & tail surfaces with a Min Size Limit equal to the ~0.1% stated in the guidelines and when I ran Octree these were not used and the wing & tail surfaces elements were of the Maximum Size.

Finally, I thought about running Density Regions along the wing & tail leading and trailing edges, which would be okay for the chordwise spacings. But this is no good as the elements will not vary in size along the semi-spans.

As always I'm using the appraoch: Run Octree-> Delete volume mesh -> Smooth surface mesh -> Run Delaunay from surface mesh -> Smooth volume mesh -> Run prism mesh.

So how can I meet these gridding guidelines?

Octree Sizes.
 

Hey SIW,

Lets just go thru that big set of questions 1 by 1...

1) Don't just accept the Build topo defaults for examples like this. It was OK here because you just had your aircraft, but if you had built your much larger far field, you might have had problems because the tolerance would have been scaled up to fit the far field (the default is just 1/1000th of the bounding box diagonal) and may cause troubles for the aircraft. Tolerance should be less than your smallest mesh size... Always check it.

2) Do you have a far field... I guess so or you would be able to get a volume mesh? So why do you have yellow around your aircraft?

3) Those sizes are just ball park suggestions for average mesh size. If you looked at what was used at the actual AIAA event a couple weeks ago, you would see quite a wide range. Use those as a starting point and then adjust the mesh to suit. Also, those sizes are often set by people doing a very different mesh type to you. That size would have a very different meaning with a Cartesian mesh or multi-block structured overset mesh vs a Tetra/Prism mesh.

4) Correct, Octree does not use curve bunching. An octree algorithm must reach its sizes thru subdivision in space and then fitting to the geometry. Therefore is not that precise. But you could use the sizing function (curvature and proximity based refinement) combined with sizes and density boxes to get what you want.

5) Min size limit works with Curvature and Proximity refinement. It is not a goal (it won't force the mesh size down)... It is a limit. If the mesh tries to refine due to the curvature or proximity goals, this will limit that refinement to a minimum size. This will prevent your mesh from getting too fine in those areas. There is also a global Min Size, but these local Min Sizes can get smaller than the global. If you want to force the size on a surface down to a certain small size, you need to set the Max Size on that surface. Think of it this way... What do you want the Max Size to be on that surface?

6) The size set in a density box is also a Max Size... You can create several density boxes (or density lines or points) with varying size to get some transition. Also, I usually set the surface size smaller than the Density size so I get some transition in that direction also. You could also nest density boxes (one within the other) and set a smaller Max Size on the inner one... Setting width on the surface is another way to create mesh density around a surface, but it only works for Octree (not Delaunay yet).

6-b) Don't forget about powers of 2. Some users waste time setting lots of fancy sizes... If you have these sizes in your model... 9, 6, 5, 4, 3, 2, 1.5, 1 , 0.75 and 0.25; 0.25 is the minimum size, therefore valid sizes will be powers of 2 times that size. 0.25, 0.5, 1, 2, 4, 8. Any other sizes will be rounded down to those sizes. So your 9 becomes 8, your 6, 5 and 4 all end up as 4. Your 3 and 2 end up as 2 and your 1.5 and 1 become 1. The 0.75 becomes 0.5 and the 0.25 stays as it is... Get it? I have seen many users wast time carefully crafting sizes such as 1.1, 1.2, 1.4, 1.5, 1.6, etc. all in the same model. It is a waste of time. I am sure I have posted detailed explanations of the Octree process in the help and on CFD Online if you want more explanation. This is just the downside of Octree... The solvers don't really mind, so you can live with it (and enjoy the benefits of Octree) once you accept it.


Your process seems good. Just need to work on how you set your sizes.

Best regards,

Simon

Thanks for the explanations on this.

Yes, I did make a farfield boundary after importing the aircraft IGES file. The domain was a hemisphere. I made a point at the mid fuselage position and one many reference lengths starboard of the wingtip and used the Geometry/Surface/Standard Shape with Sphere and angle set to 90. As I said before the aircraft fuselage was a yellow line. One I made the hemisphere it changed to red, as expected. I then deleted the surface of the hemisphere that was "inside" the aircraft symmetry plane. The good thing about this method is that the hemipshere is that it's made of two haves so can be set to CFX inlet and outlet.

PYSMN, I recall a previous topic were you detailed the power of 2 method (http://www.cfd-online.com/Forums/ans...-question.html). You should write an ICEM Theory & Modelling Guide just like there is for CFX as all this info is really useful and not written (as far as I can find).

Also as you have experience with this aircraft and have made meshes for the AIAA 4th Drag Workshop using the Hexa option (I'm guessing all this from your responses and the ANSYS presentation). If you had to make it using the Tetra/Prism option what sizings would you set? I've got my latest attempt meshing on my work PC after a hole was found this morning.

I'll need to send the files to ANSYS tech support about the hole as I really don't see why it's appeared and how to fix it.

Regards

Tools...
 

Actually, we submitted Hexa and MultiZone Hexa meshes done with ICEM CFD.

Our Tetra/Prism mesh was done with the new ANSYS Meshing tools. Nothing against the ICEM CFD Tetra/Prism, it is just not what we used.

Simon

I've attached 2 images (one zoomed in of the other) on the mesh with the hole. Not sure what's going on or how to fix it.

I see, so that gets around to my original query of importing the CAD file into ANSYS. But I guess you were issued Catia files and not the IGES hosted on the NASA website.

Are the Meshing Application meshes available to be viewed in the public domain? I see the Hexa meshes are at ftp://cmb24.larc.nasa.gov/outgoing/D...tiblock_ANSYS/ but as I don't have that licence I cannot view or use them. My objective is to repeat the DPW-4 runs and then make a change to the geometry and run the cases again and see the change in the flowfield due to the geometry change.

Regards

Material Point Placement rather than real leakage?
 

It is hard to tell from here, but I am not sure you have real leakage... It looks like a material point in your wing tip is leaking to the Orfn region, but that should be hollow anyway. Just delete any material points inside the aircraft and make sure that your FLUID material point is good and far from the surface, out in the fluid region where it belongs... You should only have one material point for this model.

Sorry, I forget.
 

About the question of which meshes were available... I don't recall what was uploaded in the end (that was years ago). But I don't have any on my machine that are "ready to go".

Simon

Hi,

I removed all the ORFN points so that the only material point (BODY) was located in the fluid region away from the aircraft. Unfortunately, it still finds a hole.

Another thought that you may be able to suggest is good or bad (in either case the mesh still finds a hole). The dimensions of the aircraft are very large (fuselage length is about 2470 inches, reference length for Reynolds number is 275.8 inches) and the farfield boundary radius is 100 times the reference length. But the smallest edge is the blunt trailing edges of the wing and tailplane (about 0.53 inches). So for this reason I've set the global element seed size to 4096 (2^12) and the global scale factor to 1. Because I need 12 elements across the blunt trailing edges I've set their max size (via the Part Mesh Setup where the individual trailing edges are their own Parts) to 0.03125 (2^-5) as this gives the closest match. Would there be any advantage to scaling the geometry?

My thesis depends on getting this mesh and I'd never thought it'd be this difficult to make!

thoughts...
 

It could be that you are just setting the mesh size smaller than the geometric tolerances of the model... The seams are just not tight enough (not high quality enough) to keep in mesh that fine...

Have you tried a coarser mesh, maybe just 2 elements across that trailing edge? Just try it as a test...

My guess is you will find that requires a lot of elements.

If the finer case had worked with size a small size over the length of the trailing edge, it might have been a huge number of elements. It could easily exceed your hardware.

You might be able to hexa block this in about the same time it would take the tetra mesh to generate and smooth... But the hexa mesh would be much more efficient and smooth. There is also the multizone option which is pretty fast and efficient on this sort of model.

Hi,

Unfortunately I don't have the Hexa licence, our company only has Tetra/Prism as I'm the only one who uses ICEM CFD primarily for the CFX ICEM Replay Remeshing feature. I read most of the topics in the ANSYS Meshing & Geometry and Hexa certainly gets more mentions than Tetra/Prism. Still, here's hoping that the near future releases of ANSYS Extended Meshing will give me access to block structured meshing. But I'm just deviating from the aim of this thread.

When I return to work tomorrow I shall try applying larger elements such as on the trailing edge, perhaps I'm following the gridding guidelines to much as the DPW-4 members presented the types of unstructred meshes that I'm trying to obtain. But meshing seems to be too much of an art whereas I like to seem justifiable numbers to use for such things.

Octree subdivision clarification
 

PSYMN, I just want to pick up on your description about the power of 2 sizing for the octree method.

Is it okay to set the smallest tetra size to any value, not just 2^n value (such as 1/16, 1/8 etc)? Just so long as all the other sizings that are used in the meshing parameters follow the rule: min size x 2^n, where n = 0 for the smallest desired element? So if I wanted to have my smallest element to be 0.043 I could set this and also use 0.043x2^1, 0.043x2^2 etc?

Thanks

similar questions
 

Sorry for my interruption in this thread.

Hi, Simmon, I have similar questions with siw.

In the octree subdivision rule min size * 2^n, what does the min size mean? Is it a quantity predefined by the original geometry or manually setup? How can I find this smallest size?

"Smallest Size"
 

SIW, yes. The smallest size you set in your model sets the base for the powers of two...

The equation is (smallest size) * 2^n, where n ranges from 0 to infinity.

If you set the smallest size to 0.043, it would work out just as you said.

Note it is the “smallest size”, not specifically the “min size”. You don’t need to set a min size in ICEM CFD. It could just be the smallest “max size”.

Since Peaksun and others are also interested, I will take this opportunity to explain the Octree process in detail… :eek:

After finding the smallest size set in the model, the Octree process can scale up (doubling) to determine the max power of two size that is still below the Max size set in your model (doubling again would exceed the max size). This sets the upper range for “n”. Then the actual mesh generation process starts by filling the space with mesh cubes of that max Octree size. Once the space is filled, it begins subdivision. The algorithm asks the same simple question for each cube. “Are there any entities within this cube whose max size is smaller than the current cube size?” If the answer is yes, it subdivides. If the answer is no, it stops subdividing that cube and continues to work on other cubes until all max sizes are set. Somewhere along the way, it also looks after curvature and proximity refinement in a similar way. For the actual subdivision, each size of the cube is subdivided (in two). Therefore the first subdivision (to n-1), is half the size of the one before it, all the way down to the smallest size set. When you divide a cube in half on all three sides, you get 8 smaller cubes at each step… Since it divides each cube into 8 cubes in a branching process, it is called Oct-Tree subdivision.
Then it divides each hexa into 12 tetras (some other Octree methods divide each hexa into 8, but division into 12 gives better quality). Eventually, it will work out “smooth” transitions between the steps, run the cutter to fit to the geometry and create the shells, flood fill to put the volume elements in the right parts (and throw out the junk) and then smooth.

So, if you set the “max size” on one surface to 3, and if that is the smallest size you set in your model, you will get sizes like;

n 0 1 2 3 4 5 6 7 8
size 3 6 12 24 48 96 192 384 768

If somewhere else you set a smaller size (such as a max size of 0.8 or a global min size of 0.8), then the smaller size would set the base for your powers of two, it would scale up to one step below the max size and begin to subdivide from there. Valid sizes could be…

n 0 1 2 3 4 5 6 7 8
size 0.8 1.6 3.2 6.4 12.8 25.6 51.2 102.4 204.8

If it finds entity sizes between these sizes, it would round down until it is below the size set on any entity (size on an entity can’t exceed the max size on that entity, so it must subdivide again until it is below). So when it looks at the surface you set to size 3, if the mesh size of the current Octree iteration is 3.2, it will subdivide down to 1.6 and then stop.

Also remember that the size set is an average size of the initial subdivision... Since the tets do not start as equilateral (rather they are hexas divided into 12 tetra elements), you will get a variety of sizes depending on which edges you measure. Then this is further complicated by transitions between the sizes, as well as adjustments and refinements made as the edge criterion fits the nodes to the actual geometry. Finally, the smoother may also adjust the average mesh size of any element.

All these oddities are just a byproduct of the Octree method. On the positive side, it is a very robust mesher that can give results on very poor data without much setup effort.
If you are looking for more precise size control, use the patch dependent (aka patch conforming) meshers that start with the user specified sizes and growth rates on each curve and march from there.

Tri-Tolerance
 

Ok, looking at your model, I don't think I would be able to run it on my machine right now (it would use too much memory and CPU for too long)... (I will try to kick off a run this evening).

First thing I noticed was that the wing appeared very faceted, particularly near the trailing edge. In this screen shot, the cursor is pointing to the tetra size icon ("right click on surfaces => Tetra sizes" to display these surface size icons.) The gap icons are showing large gaps in your model. These are smaller than your tolerance, but more than enough to let many of these small elements leak thru.
Attachment 4285


There is a concept in ICEM CFD of "Triangulation Tolerance" (aka tri-tolerance). This is usually just a display issue related to how the surface display represents the bspline geometry of the model. The surface display actually creates a faceted representation to more efficiently handle highlights, etc. If you have a finer tri-tolerance, display slows down as it needs to calculate for more facets.

With Octree Tetra, the cutter and flood fill processes actually need a faceted version of the geometry to run... Rather than do this as a separate step, it was logical to use the same tri-tolerance that was already facetizing the geometry for display. That way, what you see is what you get. So, even though this is a bspline geometry, this faceted display affects the way that octree tetra runs the cutter and flood fill operations... Sloppy tri-tolerance = leakage.

However the fix is easy.

Just reduce the tri-tolerance. here I reduced it by an order of magnitude (from 0.001 down to 0.0001).
Attachment 4286


You can find more about tri-tolerance in my tips and tricks pdf posted a bunch of times on CFD-Online.

Other suggestions
 

Oh yea, suggestions for Tetra/Prism success with this model...

Instead of setting sizes on all the separate surfaces, I often set sizes more casually (and coarsely) and then set a global curvature and proximity size function. Since you have already done the work, might as well keep it.

However, i do worry that meshing this fine will require a large number of elements (Hexa would be much more efficient). Hopefully your hardware can handle the final mesh size. (you will definitely need 64 bit with lots of memory to handle the many millions of cells (I am unwilling to guess) this could potentially generate.

You will probably also want to refine some volume regions using density boxes or lines. These will set a local max size, which is important in wake regions and other sensitive areas. Density boxes will work with Delaunay.

I usually Octree first to get the surface mesh, then delete the volume mesh, smooth the heck out of the surface mesh (with laplace) and then run the Delaunay Tetra volume fill (to get smoother volume transitions and a more efficient space filling than Octree Tetra). Then I run smoothing again (without laplace) to improve the new volume mesh quality. Then I would run prism, then smooth again with prisms frozen.

Not sure what else I can tell you. My octree process is so standard it should be scripted (and is in Workbench) Hopefully the tri-tolerance tip gets you past the leakage and the rest will be smooth sailing.

PSYMN,

Will this IGES file import into ANSYS Meshing v13 correctly? In version 12.1 the wing/fuselage fairing is omitted and there's nothing I can see that will make it appear.

I've come to the end of my patience trying to get this to work in ICEM because whenever I get close to the mesh I want (with the correct cell quanity and distributions) it finds a hole!!!!

I've followed carefully everything you've stated above and additionally tried other things I've read in other topics here but cannot resolve the probelm.

I apply the entire method (octree -> delaunay etc) that's been repeated above and it works so long as the element sizes are larger than what I'm after.

If I change the build topo and single curve edge values, thinking that this is the bit that will resolve the entire issue, it fixes some issues (i.e. merges 2 very small areas at the wing root trailing edge:)) and introduces new problems (multiple yellow lines at the aft wing fairing:mad:).

BTW, the reason I'm not starting with a shell mesh and then moving on to Delaunay is becuase ICEM will not respect either curve or surface sizings that I specify on the trailing edges.

Nope, I tried that Iges file in R13 ANSYS Meshing back at the start. it had some weird problems...

Sorry for the frustration... I would blame the iges file as not suitable for mesh this fine, but that probably wouldn't help.

If you have already increased your tri tolerance and still got leakage, then I suggest you just keep the surface mesh rather than view the leakage. This will dump all the volume mesh so leakage won't matter.

Then do a checkmesh on the surface mesh to look for for single edges... (or you can right click on mesh => Diagnostics => Single edges. This should find the holes for you. You can just sew them up with Edit mesh => Repair => Mesh from edges. Or use merge nodes to fix smaller holes, etc.

Once the mesh is fixed up and smoothed, perhaps even with a few laplace iterations, try one of the bottom up methods to fill the now watertight surface mesh without worrying about fixing the not watertight geometry. The Delaunay with TGlib AFT is the best, but does take more memory than the others...

Final CAD fix (hopefully)
 

Finally, I got a smoothed surface mesh from the Octree mesher of the required element quantity and distribution and without any messages about holes :D. I haven't gone on and generated the TGlib AF Delaunay and Prisms just yet as the Octree was left to run overnight and I ant to get this issue fixed too re-run the Octree.

On inspection of the surface mesh at the fuselage/wing trailing edge interface I noticed 2 small curves which ICEM has followed with mesh elements (only about half a dozen elements). These 2 curves are in the original IGES file but should not be there. I've tried deleting them and re-running Build Topo but ICEM is finding them again. So they must be due to the surface.

The surface image just shows the perspective that the zoomed-in wireframe image is viewed from and the yellow lines are due to me trying different things with the Build Topo and not in the final mesh. The wireframe image shows the wing trailing edge with the 2 curves (bold red) and the trailing edge surface (thin orange). So how can I get the 2 curves to follow the straight trailing edge surface? I think this needs to be done with one of the Geometry tools rather than a tolerance setting, but I've had no success with deleting/merging/creating surfaces.

Thanks.

No need for a geometry based solution.
 

This is a case of how you think about it... Geometry is a problem for you, but the Octree doesn't care about the geometry as much as you do.

So, next time, you can just delete the curves and not bother to re-run build topology. It just means you won't have nodes lining up along that surface edge... do you actually need the elements to line up there? Lining up elements forces them into certain shapes based on the geometric constraints. This limits quality, etc.

I would say Octree only needs curves at the boundaries of sharp features and the perimeter of boundary conditions...

So, just delete the curves (and points for that matter) that do not mark the edges (and corners) of sharp features and boundary conditions...

Now, as for you existing mesh, I guess you won't want to remesh it... Just go into Edit Mesh => Move Nodes, and change the association of those curve projected nodes to "surface projected". This will free them of the silly curves. You could delete line elements also. Then run the smoother again and let it do its thing.

Sorry, I couldn't provide a geometry based solution. Hopefully this is better. If this really is the boundary of an important boco, let me know and we can work thru that.

Best regards,

Simon

Why now a Delaunay fault?
 

Okay, I've now managed to get a checked, smoothed surface mesh from the Octree mesher with no holes or strange elements as posted above at about the required element quantity and distribution. The octree mesh took +8 hrs to run (not sure total time as I left the PC running overnight from a 7am start) and ended with a mesh of about 23 million elements (2 million surface elements).

I then ran the Delaunay mesher (with TGlib and Use AF) and it finished in a matter of minutes with a volume element count of about 5 million as shown in the image. Clearly it didn't work. Why? I don't know what or why stuff has gone outside of the domain when I started with a checked, smoothed surface mesh. Next is how can this be fixed? I was expecting this part to be straight forward.

Thanks.

Hmmm...
 

I have no idea why it would do that... Did you run all the checks before hand (no single edges, overlapping faces, etc.)? Have you tried any other methods (Standard Delaunay or Advancing Front?)

Define a Material Point and used it for mesher.