CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Bugs

Wrong wall distance with cyclic boundaries

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

Reply
 
LinkBack Thread Tools Display Modes
Old   October 26, 2012, 05:40
Default Wrong wall distance with cyclic boundaries
  #1
Member
 
Sebastian Saegeler
Join Date: Nov 2009
Location: Munich
Posts: 70
Rep Power: 7
sebastian is on a distinguished road
Hello everybody,

I recognised that OpenFOAM-1.6-ext calculates a wrong wall distance when using cyclic boundary conditions.

I am simulating some kind of channel flow with swirling fluid and instead of simulating the whole 360 domain, I want to use a 45 slice.

Creating the cyclic rotational boundary patches seems to work fine with createPatch:
Code:
matchTolerance 0.0001;
pointSync true;

// Patches to create.
patchInfo
(
    {
        // Name of new patch
        name periodic;

        // Type of new patch
	dictionary
	{
            type cyclic;
	    transform rotational;
	    rotationAxis (1 0 0);
               rotationCentre (0 0 0);
	    rotationAngle -45;
	}

        // How to construct: either from 'patches' or 'set'
        constructFrom patches;

        // If constructFrom = patches : names of patches. Wildcards allowed.
        patches (symmetry_2 symmetry_1);

        // If constructFrom = set : name of faceSet
        set f0;
    }
);
checkMesh does not give me an error and says that the mesh is fine.

After reaching convergence, the flow field looks reasonable and the transformation of the velocity vectors at the cyclic boundaries seems to work correct.
However when I use the kOmegaSST turbulence model, the blending functions F1 and F2 are wrong. Both functions are depending on the wall distance which is calculated obviously incorrect (see picture).
"Wall-cells" seem to appear randomly within my domain. Again, the flow field is okay, thus it only concernes the calculation of the wall distance.
This problem also occurs for a similar case with 90 cyclic boundaries.

It all works nice with symmetric boundary conditions. So the error must come along with the cyclic boundaries..

Does anybody know about the problem and how to fix it?
In google I found this:
http://www.openfoam.org/mantisbt/view.php?id=92
I am using an old version of 1.6-ext. Does anybody know if this has been fixed in 1.6-ext?

Thanks for your help!!

Sebastian
Attached Images
File Type: png y.png (45.8 KB, 34 views)
File Type: png F1.png (36.9 KB, 27 views)

Last edited by sebastian; October 29, 2012 at 11:27.
sebastian is offline   Reply With Quote

Old   October 30, 2012, 10:25
Default
  #2
Member
 
Sebastian Saegeler
Join Date: Nov 2009
Location: Munich
Posts: 70
Rep Power: 7
sebastian is on a distinguished road
Hello again.

I have installed the latest version of OpenFOAM-1.6-ext.

Now the wall distance seems to be correct at least for serial calculations. For parallel calculations it is still wrong. I have attached two more pictures of the wall distance distribution at two x-locations. The main flow direction is in x-direction. As you can see in the post above, the rotation angle is 45.

One picture shows the wall distance for the serial case, the other shows a parallel calculation.
In the parallel case, at some positions in my domain, the wall distance is randomly set close to zero as if there are wall cells within my flow field. Thus, the blending functions of the kOmegaSST model are wrong there and the model produces wrong results. The distribution of the wall distance within my flow domain is slightly depending on the number of processores I use. The calculated wall distance close to the walls seem to be good in both cases. Again, using symmetric BCs works perfect.

Is there anybody who can help?

Sebastian
Attached Images
File Type: png WallDistance - serial.png (58.6 KB, 17 views)
File Type: png WallDistance - parallel.png (64.4 KB, 17 views)
sebastian is offline   Reply With Quote

Old   October 30, 2012, 11:01
Default
  #3
Senior Member
 
sail's Avatar
 
Vieri Abolaffio
Join Date: Jul 2010
Location: Always on the move.
Posts: 308
Rep Power: 7
sail is on a distinguished road
Quote:
Originally Posted by sebastian View Post
Hello again.

I have installed the latest version of OpenFOAM-1.6-ext.

Now the wall distance seems to be correct at least for serial calculations. For parallel calculations it is still wrong. I have attached two more pictures of the wall distance distribution at two x-locations. The main flow direction is in x-direction. As you can see in the post above, the rotation angle is 45.

One picture shows the wall distance for the serial case, the other shows a parallel calculation.
In the parallel case, at some positions in my domain, the wall distance is randomly set close to zero as if there are wall cells within my flow field. Thus, the blending functions of the kOmegaSST model are wrong there and the model produces wrong results. The distribution of the wall distance within my flow domain is slightly depending on the number of processores I use. The calculated wall distance close to the walls seem to be good in both cases. Again, using symmetric BCs works perfect.

Is there anybody who can help?

Sebastian
any chances that the error is caused by the processor boundaries that are, in this case, seen as solid walls?

I don't have 1.6-ext with me right now so I can't check the code, but i suspect that the error is somewhere there. Hope it helps.

ps, in the 2.x version this behavior does not appear, maybe you can upgrade the version or at least check the working code in it?
__________________
http://www.leadingedge.it/
Naval architecture and CFD consultancy
sail is offline   Reply With Quote

Old   October 31, 2012, 04:58
Default
  #4
Member
 
Sebastian Saegeler
Join Date: Nov 2009
Location: Munich
Posts: 70
Rep Power: 7
sebastian is on a distinguished road
Quote:
Originally Posted by sail View Post
any chances that the error is caused by the processor boundaries that are, in this case, seen as solid walls?

I don't have 1.6-ext with me right now so I can't check the code, but i suspect that the error is somewhere there. Hope it helps.

ps, in the 2.x version this behavior does not appear, maybe you can upgrade the version or at least check the working code in it?
I also had the idea about the processor boundaries. I have checked that. The wrong wall distances are not on the processor patches.

I want to try version 2.1.x, but this will take a while and I am not sure if I can use this version for my purposes.
Any help concerning this problem in 1.6-ext would be highly appreciated.

Sebastian
sebastian is offline   Reply With Quote

Old   October 31, 2012, 11:24
Default
  #5
Member
 
Sebastian Saegeler
Join Date: Nov 2009
Location: Munich
Posts: 70
Rep Power: 7
sebastian is on a distinguished road
I have to revise my statement that the wall distance is calculated incorrect only for the parallel case.
I did some more testings. Also for the serial case there appear "wall cells" within my domain, they are just located at different spots. Thus, the wrong wall distance does not necessarily come along with parallelisation. The wrong wall cells seem to appear randomly within the domain. At least I was not able to figure out any regularity, neither depending on the mesh nor on the parallelisation parameters I have used
sebastian is offline   Reply With Quote

Reply

Thread Tools
Display Modes

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 Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Problem with cyclic boundaries in Openfoam 1.5 fs82 OpenFOAM 37 January 7, 2015 01:31
Parallel refineMesh with Cyclic Boundaries mchurchf OpenFOAM 6 June 20, 2012 13:06
udf error srihari FLUENT 0 February 9, 2009 10:00
Errors running allwmake in OpenFOAM141dev with WM_COMPILE_OPTION%3ddebug unoder OpenFOAM Installation 11 January 30, 2008 21:30
Cyclic Boundaries -> Match Option -> Arbitrary Derek CD-adapco 1 August 4, 2004 22:06


All times are GMT -4. The time now is 23:47.