|
[Sponsors] |
[ICEM] Disable Matching of Nodes on Parallel Edges |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
January 2, 2021, 23:42 |
Disable Matching of Nodes on Parallel Edges
|
#1 |
Senior Member
Kira
Join Date: Nov 2020
Location: Canada
Posts: 435
Rep Power: 9 |
Hello All,
I am currently creating a structured mesh for my geometry in ICEM. From trying and as stated in the ICEM Tutorial Manual, when the number of nodes is changed on one edge, all parallel edges will automatically have the same number of nodes. Is there a way to disable this from occurring for a structured mesh? The the ICEM Help Manual, p.272 (the attached image), depicts what I want, but this mentions it has to do with patch dependent options (?), and I believe merging two different meshes, so I do not think it applies for my case. Thanks in advance. |
|
January 3, 2021, 10:06 |
|
#2 |
Senior Member
Sebastian Engel
Join Date: Jun 2011
Location: Germany
Posts: 567
Rep Power: 21 |
Hi Kira,
for a fully structured(mapped) mesh it is not possible to have different element counts on parallel edges. However, you can integrate (partly-) unstructured blocks within a blocking topology. In the following menu you can switch block types from mapped to free: Blocking tab > Edit Block > Convert Block Type. Such a free block uses the unstructured-mesh settings to fill it with elements. You could use for example a hexa/quad-dominant mesh to fill the block. In 3D you also have the option of a so-called swept block. It is a prismatic-elements block where only top and bottom faces are free/unstructured meshes. If hybrid meshes (structured + unstructured) are not an option, you would have to deal with more complex strategies In order to replace the impossible block with a blocking structure which matches your given edge counts. You can find the so-called nesting strategy. As far as i know, ICEM does not have a feature to create it automatically on the blocking level. However, if you use different refinement levels on adjacent blocks, you can choose to resolve the difference in edge count. This only works if the edge counts differs by a factor of three. In other cases you end up having so-called hanging nodes - practically an internal interface. Many solvers nowadays can deal with hanging nodes, though. Best, Sebastian |
|
January 3, 2021, 10:39 |
|
#3 |
Senior Member
Kira
Join Date: Nov 2020
Location: Canada
Posts: 435
Rep Power: 9 |
Hello Sebastian,
Thank you so much for your very detailed reply. You have confirmed my suspicion that it is not possible the way I have been trying it. The geometry is 3D, so I would have to look into using these swept blocks, or use nesting as you have mentioned. |
|
January 15, 2021, 00:19 |
|
#4 | |
Senior Member
Kira
Join Date: Nov 2020
Location: Canada
Posts: 435
Rep Power: 9 |
Quote:
Do you have any tutorials/examples of the nesting strategy you were talking about, as well as refinement levels on adjacent blocks? Thanks in advance |
||
January 15, 2021, 03:59 |
|
#5 |
Senior Member
M
Join Date: Dec 2017
Posts: 703
Rep Power: 13 |
Kira, have a look around page 177 of this slide show: https://manualzz.com/doc/7414055/ice...r-cfd-analysis
|
|
January 15, 2021, 11:00 |
|
#6 | |
Senior Member
Kira
Join Date: Nov 2020
Location: Canada
Posts: 435
Rep Power: 9 |
Quote:
It states that this is used for unstructured mesh only? So there would be no way to do this for my structured mesh? |
||
January 15, 2021, 14:39 |
|
#7 |
Senior Member
Sebastian Engel
Join Date: Jun 2011
Location: Germany
Posts: 567
Rep Power: 21 |
Resolving a refinement is indeed an operation which can only be run on an unstructured mesh.
However, this might be misleading a little bit since every premesh is converted to unstructured before exporting. Hence, you can consider this feature a post processing step of your premesh. Although it's possible to use this feature on any other unstructured mesh as well. You just cannot run it in the premeshing phase. |
|
January 19, 2021, 23:33 |
|
#8 |
Senior Member
Kira
Join Date: Nov 2020
Location: Canada
Posts: 435
Rep Power: 9 |
Thank you again Sebastian and AtoHM,
I am hoping I could get some last points of clarification; If I were to implement this separate refinement in my mesh, it would introduce some skew to my cells, right? Right now, I have a perfectly orthogonal mesh (100% quality and min. angle of 90 degrees), and I wish to keep this. EDIT: I did the block refinement and it tells me there is no skew, even when I use the 'resolve refinements' option. Interesting! Along that line of thinking, if I were to have one mesh that was orthogonal and another that wasn't, I would need more nodes for the orthogonal case to 'make up' for the orthogonality, right? Hope what I am asking is clear. Last edited by aero_head; January 20, 2021 at 23:32. Reason: Did refinement |
|
January 21, 2021, 00:10 |
|
#9 |
Senior Member
Kira
Join Date: Nov 2020
Location: Canada
Posts: 435
Rep Power: 9 |
Sebastian and AtoHM,
Thank you so much for your replies. The block refinement was exactly what I was looking for! I'll be sure to make the transition from the other blocks that I did not refine as smooth as I can. |
|
May 23, 2024, 11:17 |
Disable Matching of Nodes on Parallel Edges
|
#10 |
New Member
Manaf Muhammed
Join Date: Oct 2018
Posts: 21
Rep Power: 8 |
If anybody find a way to do this please let me know.
I did it by making the block inside the geometry free and then delete it. |
|
Tags |
icem, meshing, structured mesh |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
[snappyHexMesh] SnappyHexMesh for internal Flow | vishwa | OpenFOAM Meshing & Mesh Conversion | 24 | June 27, 2016 09:54 |
Something weird encountered when running OpenFOAM in parallel on multiple nodes | xpqiu | OpenFOAM Running, Solving & CFD | 2 | May 2, 2013 05:59 |
[snappyHexMesh] external flow with snappyHexMesh | chelvistero | OpenFOAM Meshing & Mesh Conversion | 11 | January 15, 2010 20:43 |
parallel computing with non-domain member nodes | luke.christ | FLUENT | 0 | June 27, 2009 07:12 |
CFX4.3 -build analysis form | Chie Min | CFX | 5 | July 13, 2001 00:19 |