[egp]

OF community,

I've recently begun experimenting with OF, and am posting my first question to the message board.

When simulating flow over an axisymmetric body, the User Manual (U-145, U-146) specifies that the wedge-type cells must be 5 degrees, and must straddle one of the coordinate planes.

What is the reason for this restriction?

So that I can understand the implementation, where would I look in the source?

Thank you,

Eric Paterson
Penn State Univ
State College, PA USA

[hjasak]

The angle is a compromise between the "small numbers" and accuracy of the volumes in the slice. You can choose whatever angle you wish (within reason): the important thing is that the wedge boundary should straddle a coordinate plane (of your choice).

The wedge boundary condition implements the appropriate coordinate transfromations for various types and you can find the code in:

/home/hjasak/OpenFOAM/OpenFOAM-1.3/src/finiteVolume/fields/fvPatchFields/derived FvPatchFields/wedge

specifically in wedgeFvPatchField.C, line 128 and beyond.

Please make sure that the front and back of the wedge are in two separate patches.

Enjoy,

Hrv

[mattijs]

Your case has wedge on front and back. So it should not have an 'empty' patch. Make it something else or remove it if there are no faces in it.

[gort]

Hi Mattijs,

thank you for the quick answer.
When i remove this patch it is again created by bloclMesh as defaultFace like
----------------
defaultFaces
{
type empty;
nFaces 0;
startFace 410;
}
---------------
this is what exactly is written in user guide.

So, i've tried to replace it in blockMeshDict through "symmetryPlane axis" (it is actually a plane of symmetry) or "patch axis" with the same result:

--> FOAM Warning :
From function FoamX::IGeometricFieldImpl::load(const dictionary& fieldDict)
in file IGeometricFieldImpl.C at line 509
Incorrect patch field type 'fixedValue' for patch 'inlet'.
Boundary condition specifies 'empty' for field 'p'.
--> FOAM Warning :
From function FoamX::IGeometricFieldImpl::load(const dictionary& fieldDict)
in file IGeometricFieldImpl.C at line 509
Incorrect patch field type 'zeroGradient' for patch 'fixed_wall'.
Boundary condition specifies 'empty' for field 'p'.
--> FOAM Warning :
From function FoamX::IGeometricFieldImpl::load(const dictionary& fieldDict)
in file IGeometricFieldImpl.C at line 509
Incorrect patch field type 'pressureTransmissive' for patch 'outlet'.
Boundary condition specifies 'empty' for field 'p'.
--> FOAM Warning :
From function FoamX::IGeometricFieldImpl::load(const dictionary& fieldDict)
in file IGeometricFieldImpl.C at line 446
Patch dictionary 'axis' not found in field dictionary 'p'.

The last error is very strange, since there is an entry in file p with "axis {type symmeryPlane}".
But it seems to be ignored. the code stops at the line
"Reading field p"

Have you any ideas?

Best regards,

Sergej

[mkraposhin]

Уважаемый Сергей Горшаков! Е�ли Вы владеете ру��ким �зыком и у Ва� е�ть желание �отрудничать, прошу Ва� проче�ть пи�ьмо, по�лнанное мною по адре�у, указанному в Вашей анкете.
Спа�ибо за внимание,
Крапошин Матвей, Ð*Ð�Ц "КИ"

[joakim]

Hi everybody

I have got the same problem as Sergej listed:

I am running a axi-symmetric interfoam problem.
The mesh was constucted in ICEM-CFD. I put wedge conditions on the sides. Now, on the axi of symmetry. I tried to put empty here, then I get the error

--> FOAM FATAL ERROR : This mesh contains patches of type empty but is not 1D or 2D
by virtue of the fact that the number of faces of this
empty patch is not divisible by the number of cells.

If I try other b.c, e.g. wall or symmetry here, the solver starts but crashes when computing the pressure in the first time-step.

Anybody have an idea?

regards

/Joakim

[gort]

Hi Joakim,

finally I got what I want :-) following the hint of Mattijs (put something else as empty for corresponding patch, in my case a symmetryPlane) and running the case from the command line. The problem could be in the combination of boundary conditions which you use. FoamX repaced my b.c. through zero values (may be because i tryed some strange combinations of b.c.) and this was a reason for code crash. Check the values of p,U and T in corresponding files in /0/ folder. If they all are equal to zero, than this is exactly the reason for program termination.

Just find resonable b.c. for your case and run it from the command line. With correct b.c. it should work.

Best regards,
Sergej

[mattijs]

The empty patch type should only be used for cases where there is no influence of the patch in any way on the flow. Patches of type empty hold no data and are not included in any calculation.

[joakim]

Dear Sergej and Mattijs

Thank you for taking an interest in my problem.

Sergej, I used foamX to set up the problem but I run it from commandeline. This worked perfectly in the 2D case, but fails for the axi-symmetric case.

Mattijs, my domain is L shaped, where the fluid enters at the top, flow along the axis of symmetry, turns and leave the domain in the horizontal plane. The flow should be totally symmetric. I remaid the mesh, found a geometry violation. Now I can start the problem with other b.c, e.g. wall or slip-wall, but the cuorrant number just grows as the solver progress. Viewing the solution, one can see pressure and velocity oscillations along the axis.

regards

/Joakim

[gort]

Hi Joakim,

i am also so far: growing Co number and termination after some dozen time steps. It seems to be generally more difficult to organize the solution for axisymmetric body. But for other cases it works. I tryed a simple wedge geometry in icoFoam and got a convergent solution. So why it should not work in other cases? Try to play with solvers and solver tolerances. May be the information from thread
http://www.cfd-online.com/cgi-bin/Op...how.cgi?1/3655
can be useful.
If i will find any way to solve the problem i'l let you know.

May be somebody from experienced Foam users can comment on this problem: how to get the convergent solution for axisymmetric body?

good luck,
Sergej

[joakim]

Hi Sergej

Thanks for the thread. When you tried the icoFoam case, what condition did you use on the degenerated face?

I did check mesh on my mesh and there is alot of complains about "zero size or very small edge size detected", which is maybe natural think of the axi-symmetry. But thinking of the error message, is it that there is actually a small area and Foam thinks it is 3D even though it isn't? That would explain the error message. As I said before, the mesh was constructed in ICEM and then exported in star-format. Can there be a translation problem or maybe a tolerence problem?

Regards

/Joakim

[gort]

Hi Joakim,

i've used the symmetryPlane for that face. The geometry is exactly like on Fig.6.3 page U-143with
fixed walls on the left and on the right and moving wall on cylindrical surface. The solution is similar to standard case but the velocity magnitude is higher, which is naturally taking into account conditions described above.

When i check the mesh with checkMesh it gives me a lot of warning concerning the skewness but everything else is ok. From some discussions on this board i understood that the high skewness is not a problem and is unavoidable in wedge geometry.

About the second question: probably you have to improve the mesh. I am not an expert in mesh import/export, but if you will look through the board you will find that all routines were carefully tested; i.e. they should work correctly.
checkMesh creates a list of problem zones and it should be possible to identify the position of them on your mesh. Unfortunately i don't know how to do this.

About the small areas: it is recommended to have the wedge angle small, but big enough (around 5 degree) to avoid numerical problems. May be you just need to increase the angle.

In any case try to follow the suggestions concerning the discretisation schemes and solvers, may be this will help.

regards
Sergej

[vatant]

Hello:

Using a wedge boundary condition and cyclic faces how does OF remove the singularity that occurs at r=0 ? Can someone highlight how axi-symmetric problems are treated for this purpose?

Also, cyclic boundary condition ..does it effectively indicate periodic nature.if so having a one-cell thick problem is it 2D , 3D or say 2 1/2 dimension problem?

Since OF also solves for z dimension what does it indicate?

Thanks for your help

[hjasak]

Heya,

On a pole of a wedge geometry (singularity), you can either collapse the faces or leave a small face area. Having a small face is not really a problem because all terms are multiplied by face area.

If you wish to use a FEM-based automatic mesh motion solver, you keep a small face to control the mesh motion.

A cyclic/periodic condition is equivalent to iternal mesh connection: fully implicit coupling coefficients in the matrix off-diagonal. Doing this on a 1-cell thick geometry where a cell is cyclic back onto itself is a bit problematic: the additional coupling coefficient really belongs to a diagonal. I have done a few of those simulations (2-D wedge with swirl) and it's OK.

Since OF also solves for z dimension what does it indicate?

It indicates that all vectors in OpenFOAM are 3-D in the global Cartesian coordinate system.

Enjoy,

Hrv

[vatant]

USing an empty "axis", does OF use a reflecting symmetry boundary condition?

[hjasak]

No.

Hrv

[vatant]

Hello Hrv:
How does OF treat the axis? What are the boundary conditions for the variables?

If a 3D global cartesian co-ordinate system is utilized, how is the axis worked out?

Kindly help me understand the methodology.

Thanks,

Vatant

[joakim]

Hi everybody

I continued to do some testing with an axisymmetric interFoam case. Instead of using ICEM-tetra to create the mesh, I used blockmesh. With this, everything works perfect. I simply put empty as b.c. on my degenerated face, and all works perfectly. So my conclusion is that either ICEM makes a strange mesh or the converter starToFoam do something funny. I also tried giving a little area to the degenerated face, then since we have a true 3D mesh, no problems are reported and OF runs perfectly.
Anybody experienced any similar problems?

Regards

/Joakim

[hjasak]

I am very uneasy with the "empty" boundary condition: it basically means "do nothing" so if the area is really really zero it won't make a difference but if the area is "small but non-zero" it may cause you trouble.

In order to avoid using the Marooney Maneouvre :-) you could try making a small symmetry plane or a small zeroGradient b.c. instead of empty. Could you tell me if that works - it would be a good indication whether the mesh is fine or not.

Hrv

[joakim]

Dear Hrv

Thx for taking the time and looking into the matter. So i tried replacing the empty b.c with a symmetry plane for the two cases:

Case 1) For the blockmesh case, everything works perfectly as it did using empty

Case 2) For the star-mesh, the solver starts now, but regardless of what time step I choose, the solver diverge in the first step.

Looking at the output from the checkMesh

Case 1) All good!

Case 2) All seems fine until it writes zero or negative face area... Fase area magnitude = 0.
...
This mesh is invalid.
Doesn't this seem stange, the mesh should have some cells with 0 face area?
Looking at the thread "StarToFoam, checkMesh problems", you wrote "Star is using tolerance-based mesh manipulation, which causes errors when the cells ". Can it be some tolerence problem causing the starToFoam to do what it should?

Best regards

/Joakim