|
[Sponsors] |
[ICEM] multiple problems with 15 degree sector model |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
September 26, 2013, 16:35 |
multiple problems with 15 degree sector model
|
#1 |
New Member
Join Date: Sep 2013
Posts: 9
Rep Power: 13 |
Hello all! I could definitely use your help on this...
I have a model that I'm trying to mesh in hexa. It's fairly complitcated with a lot of cuts in it. As I was blocking the model out I started to create new fluids (right-click on Parts, name the part, click the blocks I wanted in the fluid, etc.). This made it easier for me to see what I was doing instead of staring at all those lines. I got the whole thing blocked with 9 different "fluids", but they're actually all connected together. In the Blocking Tab I did a quality check to make sure I didn't have any negative elements. I fixed all those problems. Not sure how helpful any of the other quality checks I could do in the Blocking Tab, so I converted the pre-mesh to an unstructured mesh for Fluent. After the unstructured mesh was generated I did the Error and Possible Problem checks in the Edit Mesh tab. I get Periodic problems (it is a 15 degree model sector), penetrating elements (looks like there are at the interesection of each fluid that I made), multiple edges and delaunay violations. During the process of the checks ICEM also created a new parts for uncovered faces and missing faces, as well as found volume orientation errors. I've tried all the tricks that I know how to do to get this to work, granted I don't know a ton of tricks. I've never had these problems with hexa before. Can anyone give me any suggestions on how to get this mesh useable please? I'm at my wits end! Thanks in advance everyone! |
|
September 30, 2013, 11:54 |
|
#2 |
New Member
Join Date: Sep 2013
Posts: 9
Rep Power: 13 |
Anybody? Please?
I've looked thru this site trying to find answers, but only finding partial answers. Another issue I have is in a certain area the pre-mesh follows the geometry. The unstructured mesh (previewed) also follows the geometry in this particular area. But once I do a mesh check it changes the mesh and it no longer follows the geometry. I've unassociated the blocking to this particular geometry, and reassociated it. Still, the unstructured mesh after being checked is changed. Because of this it's adding faces on it's own, and it's not the mesh I want. I would like for it to follow the geometry. Not make up it's own. Does anyone have any suggestions on how to get around this please? Thanks everyone! |
|
September 30, 2013, 13:33 |
|
#3 |
Super Moderator
Ghazlani M. Ali
Join Date: May 2011
Location: Tokyo, Japan
Posts: 1,385
Blog Entries: 23
Rep Power: 29 |
After you have blocked everything, did you try putting all the blocks back to one part (FLUID) then generate the unstructured mesh ? try it see if it can avoid some your errors...
|
|
September 30, 2013, 13:51 |
|
#4 |
New Member
Join Date: Sep 2013
Posts: 9
Rep Power: 13 |
Thanks! Yea, I tried that last week. It still puts faces where one fluid connects to another fluid. I guess that's ok, right? Just make it "interior" in Fluent? I would've thought since the individual fluids were once all one fluid it would've kept that relationship intact. I guess not.
What I'm doing right now is converting each fluid into an unstructured mesh separately, and also cleaning up any penetrating element problems that I have. ICEM is obviously adding faces where another fluid connects to it. Once I have all my fluids converted to unstructured I'll do a mesh merge. Regarding the extra faces that ICEM adds at the interface, let's say Fluid1 connects to Fluid2. ICEM will put faces on both Fluid1 and Fluid2 at the interface. Do I need to delete one set of faces so that there's only one set of faces on the interface? Doing it separately, so far, has helped with eliminating the periodic problems that I was getting. ICEM is fixing the issue during the check. When the fluids were all together it was not. Don't know why. Right now I'm on the 4th out of 9 fluids. The distance that it's off is E-15. Is there a place in ICEM to set a tolerance for the periodic so if I were to have a larger sized error it would get fixed? Thanks everyone! |
|
September 30, 2013, 14:11 |
|
#5 | |||
Super Moderator
Ghazlani M. Ali
Join Date: May 2011
Location: Tokyo, Japan
Posts: 1,385
Blog Entries: 23
Rep Power: 29 |
Quote:
Quote:
After the merge done, do to check mesh -» run a check-up for ONLY "duplicated elements", if there is any, ICEM will ask you to fix it , say yes, it will remove all the duplicated elements. the faces left will be the interiors face in fluent. Quote:
I know you are almost done, just want to share how I deal with portions of geometries: I do the blocking, i convert to unstructured, Then I use the "translate mesh " tab to rotate the mesh, check duplicates, remove them , declare those faces as interior,and the job is done. May be it can help you. |
||||
September 30, 2013, 14:20 |
|
#6 |
New Member
Join Date: Sep 2013
Posts: 9
Rep Power: 13 |
Diamondx, thanks for the help! I really appreciate it. I'm not a super-user by any means. I'm just getting back into this for work. Some of these problems I've never faced before, so I appreciate the help!
I'm having a helluva time understanding why, and getting rid of penetrating elements. The blocking that pertains to where the penetrating elements are occuring is associated to the geometry. Doing a check on the pre-mesh to check for negative elements and I get nothing. Why would the unstructured mesh be producing penetrating elements? Does it mean that the element is a negative volume, or is it "penetrating" the geomtry? And, is there a quicker way to determine that there will be penetrating elements in the blocking/pre-mesh phase before converting to unstructured and doing a check? My mesh isn't exactly small, so it takes a good while to do the unstructed mesh check. Thanks again! |
|
September 30, 2013, 14:35 |
|
#7 |
Super Moderator
Ghazlani M. Ali
Join Date: May 2011
Location: Tokyo, Japan
Posts: 1,385
Blog Entries: 23
Rep Power: 29 |
To be honest, i've been meshing using ICEM for 2 years , i never met those penetrating elements, I can't tell where they come from or how
So when hearing penetrating elements, first things that comes to my mind are overlapping elements (just an assumption), which in this case can be resulted by blocks over blocks. Try to run the "fix blocks" option in the update blocks tabs. I don't know if having penetrating elements implies having bad quality elements also... if so, try the pre-mesh quality histogram see if you can find something in the criteria of quality. I wish i can help more... use the google search in cfd-online see if you can find something about it. good luck |
|
September 30, 2013, 17:37 |
|
#8 |
New Member
Join Date: Sep 2013
Posts: 9
Rep Power: 13 |
I finally got rid of the penetrating elements by trial and error. I ended up using a combination of unassociating the blocking faces and lines from the geometry and reassociating some blocking lines to surfaces...even if the blocking line was a corner where two geometric surfaces meet.
Where my penetrating elements were occuring was on a surface where on the other side of the surface was outside the domain. Imagine having a rectangular block where one side in an inlet, the other side an outlet, and the other 4 sides are walls. On the other side of those walls are outside the domain. There's no other blocks touching them or around them. That's where my penetrating elements were occuring. I would think that associating the blocking faces and lines to the geometry would prevent penetrating elements. Seems like ICEM would be more robust than this. I did look around on the forum for a definitve answer on what causes penetrating elements, but I couldn't find anything. I would really appreciate it if anybody could explain why penetrating elements happen...I'd really love to know. Simon? |
|
October 1, 2013, 11:34 |
|
#9 |
New Member
Join Date: Sep 2013
Posts: 9
Rep Power: 13 |
Hello all!
I have a periodic problem that I've been trying to tackle and haven't figured out what the issue is. The message I'm getting is: quad (number) has 4 twin nodes but no twin face in the specified families. There exists one in another family. I get that message repeatedly...so much so that it might be for each vertices that is on the periodic face. Then at the end the message is: maximum distance from periodic 3.72215e-15 between vertices (number) and (number); Fixed there are problems with the periodicity. Can anyone tell me why I might be getting this error and how I can fix the problem please? Thanks everyone! |
|
October 1, 2013, 12:38 |
|
#10 |
New Member
Join Date: Sep 2013
Posts: 9
Rep Power: 13 |
Hello all!
I tried something and it worked to get rid of the periodic problem I was having. ICEM was generating faces for one of the block faces on the periodic. So I just tried associating the face of that block to the surface "Periodic", and it worked. Hopefully this thread will be helpful to others having the same problems. |
|
October 2, 2013, 14:27 |
|
#11 |
New Member
Join Date: Sep 2013
Posts: 9
Rep Power: 13 |
I've moved on to another fluid section and I'm having a periodic problem. I've always lumped my curves into a part called "curves", points in a part called "points" and then the other parts are fluids and surfaces. My periodic bouandary, for both sides of my 15 degree sector, is called "symmetry"
For the previous fluids I've gone thru and checked out ok I have, for instance, a part called fluid5 and curves5. This way I can keep track of what curves are associated to a particular fluid I'm working on. I've not had a periodic problem in the past fluids using this method, or any other project for that matter. On this particular fluid I'm working on now I do have a problem and I don't know what is causing it. I've searched thru the forum and can't find anything. The blocking vertices have been setup as periodic always choosing one particular side first and then the other side second. Every vertices has a periodic set. I've turned on vertices and the red arrows show up to show what one vertices is periodically associated to the other vertices. Those are all correct. I don't get any errors in the pre-mesh check. When I converted to unstructured and do a mesh check the only error I get now is this periodic problem. The error is: shell (number) has node (number) which has no twin. This goes on for just about every node that lies on the periodic part "symmetry". Can someone give me a clue as to how to fix this? It's like the blocks are completely ignoring the fact that I've set the vertices of the blocks to be periodic. I've deleted all periodic associations and redone them twice. Still the same problem. Someone...please? NEVERMIND....I guess 3 times a charm on creating periodic vertices. *argh* |
|
October 2, 2013, 15:34 |
|
#12 |
Member
AhmadReza
Join Date: Jul 2012
Posts: 35
Rep Power: 14 |
Hi
Are u have periodic Domain in 15 degree? Can you Show some picture about your geometry to we can help you .... |
|
October 2, 2013, 16:24 |
|
#13 |
New Member
Join Date: Sep 2013
Posts: 9
Rep Power: 13 |
Thanks! I edited my previous post. I resolved the problem. What I did differently was I deleted the periodic associations twice in a row. I've had times where I go to delete something, like a curve, face, whatever, and it didn't delete. So I do it again, and THEN it deletes. So, I thought that maybe the same thing was happening to the periodic associations on the vertices. So I deleted them twice, then recreated all the periodic associations. It worked. Another ICEM bug.
|
|
October 2, 2013, 17:11 |
|
#14 |
Member
AhmadReza
Join Date: Jul 2012
Posts: 35
Rep Power: 14 |
thanks god that your problem solved
|
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Is it worth it? | Jason Bardis | Main CFD Forum | 47 | July 27, 2011 05:52 |
Needed Benchmark Problems for FSI | Mechstud | Main CFD Forum | 4 | July 26, 2011 13:13 |
Some problems with Star CD | Micha | Siemens | 0 | August 6, 2003 14:55 |
unstructured grid | sreekanth | Main CFD Forum | 1 | August 6, 2001 16:09 |
Inverse problems | Aleksey Alekseev | Main CFD Forum | 0 | May 12, 1999 16:38 |