[sebastian]

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:

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

[sebastian]

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

[sail]

Originally Posted by sebastian

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?

[sebastian]

Originally Posted by sail

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]

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