|
[Sponsors] |
Why Non-overlap interface occur in 1 to 1 mesh? |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
November 19, 2006, 00:39 |
Why Non-overlap interface occur in 1 to 1 mesh?
|
#1 |
Guest
Posts: n/a
|
As you know, in cfx, we only can specify GGI interface type to a 1 to 1 mesh when modelling rotor stator question. But one question comes out, the non overlap area fraction will occur in the physically matching 1 to 1 interface.That is to say, the non overlap will be regarded as wall defaultly. So this is very surperising. Any one know how CFX determine this ? According what? Which range we can accept? Can we cancle this determination instead of specifying 1 to 1 physically?
|
|
November 20, 2006, 11:51 |
Re: Why Non-overlap interface occur in 1 to 1 mesh
|
#2 |
Guest
Posts: n/a
|
GGI is always used to handle frame changes, regarless of whether the mesh is 1:1 or not. This is nothing to be concerned with. The non-overlap conditions in the boundary condition specification is only used if there are non-overlap regions. If the mesh is truly 1:1, there will be no non-overlap regions.
Read the doc for details. Regards, Robin |
|
November 22, 2006, 22:24 |
Re: Why Non-overlap interface occur in 1 to 1 mesh
|
#3 |
Guest
Posts: n/a
|
Thanks,Robin
In fact,my mesh is truly 1:1,because the mesh is made in icemcfd with a whole block.So this can guartee the mesh node matched.But unfortunally,CFX still report the non-overlap interface region,and which occur a large fraction of the interface. So i am very surprising. My question is: According which criteria does cfx determine this? Which range can we accept? when i check my results, the nov overlap region has been regarded as the wall. |
|
November 23, 2006, 10:26 |
Re: Why Non-overlap interface occur in 1 to 1 mesh
|
#4 |
Guest
Posts: n/a
|
Hi Kake,
Is the solver reporting non-overlap? If it is a Frozen Rotor interface, the interface must be a surface of revolution about your axis of rotation. If it is not, it is possible to get this error. Check that it is and fix it as necessary, then run again. Regards, Robin |
|
November 24, 2006, 04:58 |
Re: Why Non-overlap interface occur in 1 to 1 mesh
|
#5 |
Guest
Posts: n/a
|
My interface type is Stage. I think it is not related to the interface type. So i'd like to know how cfx determine non overlap between two interfaces? If you want to prove my question? you also can check the tutorial case? which have the same question when you run it. it will appear in the solver *out file at the very begining.
|
|
November 24, 2006, 09:12 |
Re: Why Non-overlap interface occur in 1 to 1 mesh
|
#6 |
Guest
Posts: n/a
|
Kake,
It can still be related to your interface type. If it is 1:1 and the edges of the regions match up, a regular GGI will report 0% overlap. That may not be the case with Stage or Frozen Rotor, so I'll ask you again, is your interface a surface of revolution? Are you domain's periodic? Regards, Robin |
|
November 26, 2006, 21:03 |
Re: Why Non-overlap interface occur in 1 to 1 mesh
|
#7 |
Guest
Posts: n/a
|
Thanks Robin,
in fact,i agree with your opinion.in my mesh, there are two interfaces of revolution surfaces, and the simulation domain is periodic.For the requriment of yplus,the mesh near the wall is very samll,which maybe smaller than the the geometric tollerance. So i suppose this maybe the reason. Is it possible to override this determination of non overlap interface area in some expert mode? |
|
November 27, 2006, 09:46 |
Re: Why Non-overlap interface occur in 1 to 1 mesh
|
#8 |
Guest
Posts: n/a
|
If it is a frozen rotor or stage interface, you can manually specify the pitch ratio or pitch angles. Due to the finite nature of the mesh, it is sometimes possible to get some non-overlap due to discrete errors.
-Robin |
|
December 14, 2006, 00:24 |
Re: Why Non-overlap interface occur in 1 to 1 mesh
|
#9 |
Guest
Posts: n/a
|
Are you 100% absolutely certain, without any doubt, that the hub curve (lowest axial or radial position) of your interface mesh forms a perfect circle of revolution around the axis.
Are you 100% absolutely certain, without any doubt, that the hub & shroud curves on both sides of your interface mesh exactly line up, both forming the same circles of revolution around the axis. If not, then you can get non-zero non-overlap area because the solver may not correctly figure out the pitch angles. In this case, just set the pitch angles. |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
[ICEM] Generating Mesh for STL Car in Windtunnel Simulation | tommymoose | ANSYS Meshing & Geometry | 48 | April 15, 2013 04:24 |
[snappyHexMesh] snappyHexMesh won't work - zeros everywhere! | sc298 | OpenFOAM Meshing & Mesh Conversion | 2 | March 27, 2011 21:11 |
Spontaneous failure of moving mesh interface | gareth__it_power | ANSYS | 1 | August 26, 2010 07:50 |
Dynamic Mesh moving interface help | akash.iitb | FLUENT | 0 | August 23, 2010 23:53 |
fluent add additional zones for the mesh file | SSL | FLUENT | 2 | January 26, 2008 11:55 |