# Gambit question

 Register Blogs Members List Search Today's Posts Mark Forums Read

 March 1, 2005, 08:37 Gambit question #1 HP Guest   Posts: n/a Hi! Does anybody know if there is a way to define boundary zones with boundary lines that do not fit in exactly with the grid lines? (so fluent will have to make interpolations?). (This is very usual in open codes) I want to create a structured grid in a simple volume (imagine a cube) with very small inlets (comparing to the total size of the whole volume) on its sides. So it is very difficult to construct a structured grid with gridlines which coincides exactly with the inlet zones' boundary lines. I tried to create the mesh directly on the whole volume (with Gambit) and I succeeded, but then the boundary zones (inlets) were not taken into account, (they were not saved with the grid). Does anybody know if this can be done with Gambit, or any other mesher, and if it is supported by fluent?

 March 1, 2005, 15:35 Re: Gambit question #2 Tarnz Guest   Posts: n/a Did you create a Size Function before meshing (and choose the inlets as the source and the volume as the attachement)?

 March 2, 2005, 04:49 Re: Gambit question #3 HP Guest   Posts: n/a Generally I want to create a grid which will be at first independent of the inlets, namely structured and uniform, but also taking into account the boundary entities (circular inlets). If I create the size function you said, then * if the volume was initially defined by the surrounding surfaces of the geometry (including the inlets) then Gambit does not succeed to create the grid. To be precise it fails to mesh the faces of the volumes (arround the inlets) * if the volume was initially defined by some boundary edges (the same volume), the inlets that are on its faces (but don't belong on them), are not taken into account at all If you think that you can help me, but did not quite understand what I want to do, then I could send you some pics. Thank you, Ilias

 March 2, 2005, 15:33 Re: Gambit question #4 Jason Guest   Posts: n/a It sounds like you're trying to do a non-conformal interface. This works when connecting volume meshes (or face meshes in 2D). You can't define a boundary condition unless it's actually part of the mesh (i.e. when you say the inlets are faces that don't belong to the volume, that won't work). The non-conformal interface isn't perfect either... it sounds like your volume mesh size is larger than the boundary you want to define... that's not a good thing... your mesh size is related to how much detail you can handle in the flow. If your mesh isn't small enough to capture the details local to the BC, then you're going to have problems. Even if you do a non-conformal interface (where you would have to create some kind of volume to simulate your inlet) it sounds like you'll have to reduce the mesh in the main volume to be able to capture any detail. Hope this helps, and goodluck, Jason

 March 4, 2005, 04:02 Re: Gambit question #5 HP Guest   Posts: n/a Thank you Jason for your help. The actual problem that I have is that many of the (face) inlets are small, comparing to the total area, and circular. And when I say small I mean that 4 cells are enough (initially) for each of them. Therefore my problem is not the minimum element size, but that I cannot construct a structured face grid (and then from that the volume grid) because of these small circular inlets, whereas the total volume geometry is very simple. So my first approach was the construction of a non structured grid on the surrounding faces, and from them a hex core grid for the volume. Do you have any other suggestions that could lead to an 100% structured mesh? As I have already said, I could send some geometry pictures to make my problem completely clear. Thank you, Ilias

 March 4, 2005, 07:50 Re: Gambit question #6 Jason Guest   Posts: n/a A structured mesh is going to be tricky on this type of geometry, and it's going to be a VERY manul process. The only way I can think of doing it is to split the edge of each circular face into four segments (so there's vertices at 45degrees, 135degrees, 225degrees, and 315degrees; this will create a top edge, bottom edge, and two side edges). Now, go to "Set Vertex Type" in the face meshing window. Then you select a circular face and change the vertex type of each of these vertices to "end" on the small circular face... this tells Gambit that you want to treat each of the vertices as an internal corner. Repeat this for each circular face. Then mesh all of the circular faces. Now select the larger face and change all of those vertices to "corner"... this tells Gambit to treat them as external corners. You MIGHT be able to use a submappable mesh on this face now. If it still fails, you're going to have to split this large face into smaller faces that are mappable. As I said, this is a VERY manual process. You might be better off just using an unstructured grid. With a properly defined grid, you're going to reach the same results with much less time wasted in setting up the grid. Hope this helps, and goodluck, Jason

 March 4, 2005, 08:34 Re: Gambit question #7 HP Guest   Posts: n/a I have already tried to set the type of the vertices. The result was succesfull for the meshing of the inlets, but a complete failure for the submapping of the surrounding the inlets area. The problem was of course the number of intervals. Then I started to decompose the geometry, but it was VERY VERY tricky (some entities became virtual somewhere in the process and I couldn't turn them back to real!). So I thought that maybe there was an easier way. Do you think that this way is the only way for a structured grid? Or could I try something else (you said something about non-conformal grid)? Is there any possibility, another mesher to be more efficient concerning the part of the submapping algorithm? Thank you very much for your time, Ilias

 March 4, 2005, 09:02 Re: Gambit question #8 Jason Guest   Posts: n/a I figured you'd have problems meshing that surface... the number of intervals error means the number of elements on the edges don't add up (if you had a square and meshed the left edge with 10 elements and the right edge with 9 elements, you'd get the number of intervals error). You could try playing around with the edge meshes and seeing if you can get a successful mesh, otherwise you're going to have to decompose the face. If you don't plan on modifying the geometry any more, then virtual geometry is alright. In fact, virtual geometry was designed to do two things... merge faces to avoid very small faces or highly skewed faces, and split larger faces into manageable ones. As far as other options, the only thing I can think of is to use an unstructured mesh (whether it's a quad mesh using the pave scheme or a tet mesh... either one is unstructured). You could use the cooper volume meshing scheme. This way you'll be structured perpendicular to the face that's giving you problems. The non-conformal interface is for joining volumes together where their mesh isn't coincident on the adjoining face. For this, the circular faces would not have been cut out of the larger face. They would be co-planar, but still separate from the large face. Then you would extrude the circular faces. Now you can mesh each cylinder as you wish and then mesh the larger volume as you wish. Be careful to keep the mesh on the larger volume refined enough to capture the details of the cylinders. I've heard you could use about a 3x difference in mesh size between a non-conformal mesh, but I would feel more comfortable with ~1x to ~1.5x maximum. Then your inlets would be the faces of the cylinder furthest from the large volume. Then in Fluent you would define the faces as non-conformal interfaces. I don't know if it can handle this setup though. I think each face can only have 1 non-conformal interface, which means you'd have to break up the larger face anyway. I could be wrong about that, I've only used non-conformal interfaces once. Gambit is an ok meshing program... it works, but it's a pain to get it to work... there are much better programs out there for meshing. Unfortunately my company won't spring for anything else, so I haven't bothered looking into other programs... I just deal with what I have. There's probably some good information on the general CFD forum as to pre-processor recommendations. I hope this helps, and goodluck, Jason

 March 4, 2005, 09:32 Re: Gambit question #9 HP Guest   Posts: n/a Thank you very much Jason. You definately helped me a lot. Regards, Ilias

 Thread Tools Display Modes Linear Mode

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is OffTrackbacks are On Pingbacks are On Refbacks are On Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post stage81 FLUENT 0 October 1, 2010 10:06 Pablo Cornejo FLUENT 10 March 10, 2006 10:46 LI Y FLUENT 2 April 6, 2003 16:59 Jack FLUENT 5 February 6, 2003 07:04 brian FLUENT 3 December 3, 2002 00:58

All times are GMT -4. The time now is 09:45.