View Issue Details

IDProjectCategoryView StatusLast Update
0002348OpenFOAMBugpublic2016-11-24 09:52
ReportergaZ88 Assigned Tohenry  
Status closedResolutionno change required 
Platformall versionsOSUbuntuOS Versionall versions
Summary0002348: Slip and Symmetry
DescriptionI want to develop a free shear constraint for curved patches. The symmetry conditions already implemented
works well for imposing free shear and I've validated it for the case of flow past a sphere. The slip condition implemented in OpenFoam, instead, doesn't give the same results, and, in particular, it gives wrong values for the drag coefficient.
This is a bit strange because, checking in the source code, slip and symmetry seem to be implemented exactly in the same way, only the patch type changes.
Anyway, now, I need to do a further step: I want to solve for the flow with the free-shear constraint on the surface of the sphere, and I would solve for the temperature with a fixedValue on the surface of the sphere. Symmetry condition doesn't allow to do this because of the check in the source code in order to have all the boundaries of type symmetry.
I've recompiled the symmetry bc, using a different name, and commented the "if" where there is the check on the patch type which allows only symmetry patch. Running simpleFoam what I obtain is that the results are exactly the same of when I use the slip bc, which is wrong because doesn't guarantee free-shear on curved surfaces.
Steps To ReproduceYou can compile the new boundary conditions and check the results, it gives the same results of slip,
but it is built starting from symmetry.
TagsNo tags attached.



2016-11-22 14:44

reporter (244,734 bytes)


2016-11-22 14:55

manager   ~0007274

Symmetry is a geometric constraint and using the 'symmetry' patch type correspondence between the patch-type and BC type is ensured.

'slip' is a BC choice and for a vector field is equivalent to 'symmetry' but is only applied to that field not to associated fields e.g. 'H/A'.

It is not clear from your description if you are proposing that the current 'slip' BC is replaced with the version you supplied, included as an alternative or demonstrates an issue.


2016-11-22 15:29

reporter   ~0007277

What do you mean for associated fields 'H/A'?
I would demonstrate the following issue:
as you said 'slip' should be, for a vector field, equivalent to symmetry,
but then, why it gives different results from the symmetry condition
(in terms of drag coefficient on the sphere, for instance, as you can see in the attached files)?
Moreover, as I can read from the code, both conditions use a Householder reflection and substitute
the value of the field with the value of the field plus its reflection.
Computing the shear stress for the new field, theoretically should be zero (provided that also the normal gradient of the tangential component of the field to the patch is zero), but checking this 'a posteriori'
with paraview, we obtain that it is zero when symmetry is imposed, and it is not zero when slip is imposed. (76,243 bytes)


2016-11-22 15:33

manager   ~0007279

The 'slip' BC is the same as 'symmetry' for the field it is applied to but it is not the same as a 'symmetry' patch type which applies the 'symmetry' BC to ALL of the fields.


2016-11-22 15:40

reporter   ~0007280

Last edited: 2016-11-22 16:24

Ok, I'm sorry, but if this is true, I should expect that, imposing symmetry at a certain boundary, is the same of imposing slip to all the fields at that boundary, right?


2016-11-22 16:23

manager   ~0007282

Last edited: 2016-11-22 16:24

How would you impose slip to all the fields at that boundary?


2016-11-23 08:39

reporter   ~0007291

The fields for which I solve are pressure and velocity at the moment. For velocity I would expect that slip means free-shear,
and for pressure, imposing slip is equivalent to impose zeroGradient and thus it makes sense for pressure at a wall. I would check if imposing slip for all fields at a determined boundary is the same to define that boundary as symmetric: in principle it should be the same, but doing the calculations I obtain different results , thus I conclude that symmetry and slip are different and this should be wrong on the basis of what you have written before and on the basis of what is written in the user guide.


2016-11-23 09:02

manager   ~0007292

There are many other fields created during the solution of the equations, imposing 'slip' an the pressure and velocity is NOT the same and setting the patch type to 'symmetry'.


2016-11-23 09:19

reporter   ~0007293

Thus it seems that there is no way to guarantee free-shear on a patch without imposing symmetry on that patch?


2016-11-23 09:30

manager   ~0007294

Last edited: 2016-11-23 10:18

Unfortunately you did not supply a case which demonstrates the issue so I am unable to reproduce it or investigate further.


2016-11-23 09:31

reporter   ~0007295

I add the case now.


2016-11-23 09:36

reporter   ~0007296

The mesh is done with cfMesh using cartesianMesh, I cleared the constant folder for the upload size limit, thus it has been built with that routine. (661,761 bytes)


2016-11-23 10:20

manager   ~0007297

Could you provide a simple 2D case generated with blockMesh? Flow around a half-cylinder should be sufficient.


2016-11-23 10:40

reporter   ~0007298

The fact that the patch is a sphere is fundamental because we have a curved surface in each direction and thanks to this the shear is not zero on the surface. Anyway I will provide the 2D case soon.


2016-11-23 10:59

manager   ~0007299

I doubt that the issue is specifically 3D but you could demonstrate that by creating simple 2D and 3D cases. Note that the blockMesh is OpenFOAM-dev has support for projecting the points onto surfaces so meshing a sphere is much easier.


2016-11-23 13:56

reporter   ~0007300

I added the case for the cylinder, where I reproduce the same issue. The cases are already run and the solution and the respective postProcessing evaluation are present in the respective slip-symmetry folders.
The wallShearStress has been computed and is inside the time folder. I hope it is all clear. (344,366 bytes)


2016-11-23 14:48

manager   ~0007301

I am running the cylinderBugRepSlip case but it did not run with OpenFOAM-4.0 and I had to put in some effort to upgrade it. How did you run it with OpenFOAM-4.0?

Also the blockMeshDict and the field files are inconsistent so after I ran blockMesh I could not run the case without some changes to the field files.

Using the wallShearStress functionObject I get 0 values for the body with both 'slip' and 'symmetry' because the wallShearStress in OpenFOAM-4/dev only evaluates the shear-stress for walls. I corrected your case so that the body is of type 'wall' and then I get non-zero values for the wall shear-stress. I then changed the wallShearStress functionObject so that it generated the shear-stress for 'symmetry' patches and ran the case with 'symmetry' on the body and again I get non-zero wall shear-stress values for the body with value very similar to those using 'slip'.

How are you calculating the shear-stress on the body?


2016-11-23 15:26

reporter   ~0007303

I'm using OpenFOAM-2.3.x but I've noticed the same issue with OpenFOAM-4.0 and my original case.
The file blockMesh is inconsistent because I run the following sequence of commands:
blockMesh>mirrorMesh>autoPatch '45' -overwrite
to do the mesh consistent with the boundary conditions in the 0 folder of the cases I've sent you.
I calculate the shear-stress typing wallShearStress -latestTime after I have computed the solution,
and apparently it calculates the shear stress also on generic patches.
Thus, are you suggesting that the difference is in the way of calculating the wallShearStress? And what about the difference between slip and symmetry in the drag coefficient computed in the forceCoeffs functionObject placed in the controlDict?
Moreover, I have calculated by hand the shear stress at body_0, using the value of the field imposed in -basicSymmetryFvPatchField.C and it should be zero.


2016-11-23 15:33

reporter   ~0007304

I'll repost in a while the same cases ran with 4.0 version


2016-11-23 15:48

manager   ~0007308

I calculate the shear-stress on the body surface to be non-zero for both the 'slip' AND 'symmetry' boundary conditions because of the way in which the transpose part of the gradient is handled; it is evalutated in the cell and projected to the boundary rather than being evaluated on the boundary.

It is not clear to me how you are evaluating the shear-stress on the boundary with either 'slip' or 'symmetry' in OpenFOAM-4.0; the wallShearStress functionObject only evaluates the shear-stress on 'wall' patches.


2016-11-23 15:58

reporter   ~0007309

I uploaded the same cases for OpenFOAM-4.0. I reproduced exactly you said. In both cases (slip and symmetry) the wallShearStress is different from zero (I haven't verified it for symmetry because, as you said wallShearStress calculates the stress only on walls, but I trust in you). The difference in the forceCoeffs in the postProcessing folder is due to the fact that symmetry treats in a different way the "hidden" fields phiHbyA, A, etc.
But then, I don't understand why the shear stress is different from zero, if the value of the field at the symmetry/slip patch is that one defined in the evaluate member function of basicSymmetryFvPatchField.C (the field itself plus its HouseHolder reflection divided by 2).
reportOF40.tar.gz (351,905 bytes)


2016-11-23 16:10

manager   ~0007311

The shear-stress on the body surface is non-zero for both the 'slip' AND 'symmetry' boundary conditions because of the way in which the transpose part of the gradient is handled; it is evalutated in the cell and projected to the boundary rather than being evaluated on the boundary.


2016-11-23 16:32

reporter   ~0007312

Then, if it could be evaluated on the boundary it should be zero? If it was the case I should expect a small deviation from zero..anyway, I guess there is no way to guarantee zero-shear at a surface already implemented, even if symmetry should guarantee this? Am I right?


2016-11-23 16:42

manager   ~0007313

The easiest way to ensure the shear-stress is zero on the boundary is to set the viscosity to 0 on the boundary.


2016-11-23 16:51

reporter   ~0007314

But in that way you completely change the physics of the problem.


2016-11-23 17:01

manager   ~0007315

The viscosity on the boundary would only be used to calculate the stress on the boundary which you expect to be zero so in what way does setting the viscosity to zero on the boundary change the physics of the problem?


2016-11-24 08:30

reporter   ~0007316

Do you mean only in a post processing phase to compute the wallShearStress 'a posteriori' or during the solution step?


2016-11-24 08:58

manager   ~0007317

Either or both.


2016-11-24 09:12

reporter   ~0007318

Can 'nu' be specified in the transportProperties as a nonuniform field with specific value on each patch?


2016-11-24 09:17

reporter   ~0007320

Anyway I think we are going far from the subject of the issue. You can close it. Thank you.

Issue History

Date Modified Username Field Change
2016-11-22 14:44 gaZ88 New Issue
2016-11-22 14:44 gaZ88 File Added:
2016-11-22 14:55 henry Note Added: 0007274
2016-11-22 15:29 gaZ88 File Added:
2016-11-22 15:29 gaZ88 Note Added: 0007277
2016-11-22 15:33 henry Note Added: 0007279
2016-11-22 15:40 gaZ88 Note Added: 0007280
2016-11-22 16:23 henry Note Added: 0007282
2016-11-22 16:24 henry Note Edited: 0007282
2016-11-22 16:24 henry Note Edited: 0007280
2016-11-23 08:39 gaZ88 Note Added: 0007291
2016-11-23 09:02 henry Note Added: 0007292
2016-11-23 09:19 gaZ88 Note Added: 0007293
2016-11-23 09:30 henry Note Added: 0007294
2016-11-23 09:31 gaZ88 Note Added: 0007295
2016-11-23 09:36 gaZ88 File Added:
2016-11-23 09:36 gaZ88 Note Added: 0007296
2016-11-23 10:18 henry Note Edited: 0007294
2016-11-23 10:20 henry Note Added: 0007297
2016-11-23 10:40 gaZ88 Note Added: 0007298
2016-11-23 10:59 henry Note Added: 0007299
2016-11-23 13:56 gaZ88 File Added:
2016-11-23 13:56 gaZ88 Note Added: 0007300
2016-11-23 14:48 henry Note Added: 0007301
2016-11-23 14:52 henry View Status private => public
2016-11-23 15:26 gaZ88 Note Added: 0007303
2016-11-23 15:33 gaZ88 Note Added: 0007304
2016-11-23 15:48 henry Note Added: 0007308
2016-11-23 15:58 gaZ88 File Added: reportOF40.tar.gz
2016-11-23 15:58 gaZ88 Note Added: 0007309
2016-11-23 16:10 henry Note Added: 0007311
2016-11-23 16:32 gaZ88 Note Added: 0007312
2016-11-23 16:42 henry Note Added: 0007313
2016-11-23 16:51 gaZ88 Note Added: 0007314
2016-11-23 17:01 henry Note Added: 0007315
2016-11-24 08:30 gaZ88 Note Added: 0007316
2016-11-24 08:58 henry Note Added: 0007317
2016-11-24 09:12 gaZ88 Note Added: 0007318
2016-11-24 09:17 gaZ88 Note Added: 0007320
2016-11-24 09:52 henry Assigned To => henry
2016-11-24 09:52 henry Status new => closed
2016-11-24 09:52 henry Resolution open => no change required