View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002348 | OpenFOAM | Bug | public | 2016-11-22 14:44 | 2016-11-24 09:52 |
| Reporter | gaZ88 | Assigned To | henry | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Platform | all versions | OS | Ubuntu | OS Version | all versions |
| Summary | 0002348: Slip and Symmetry | ||||
| Description | I 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 Reproduce | You can compile the new boundary conditions and check the results, it gives the same results of slip, but it is built starting from symmetry. | ||||
| Tags | No tags attached. | ||||
|
|
|
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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? |
|
|
How would you impose slip to all the fields at that boundary? |
|
|
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. |
|
|
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'. |
|
|
Thus it seems that there is no way to guarantee free-shear on a patch without imposing symmetry on that patch? |
|
|
Unfortunately you did not supply a case which demonstrates the issue so I am unable to reproduce it or investigate further. |
|
|
I add the case now. |
|
|
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. |
|
|
Could you provide a simple 2D case generated with blockMesh? Flow around a half-cylinder should be sufficient. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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? |
|
|
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. |
|
|
I'll repost in a while the same cases ran with 4.0 version |
|
|
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. |
|
|
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. Right? 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). |
|
|
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. |
|
|
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? |
|
|
The easiest way to ensure the shear-stress is zero on the boundary is to set the viscosity to 0 on the boundary. |
|
|
But in that way you completely change the physics of the problem. |
|
|
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? |
|
|
Do you mean only in a post processing phase to compute the wallShearStress 'a posteriori' or during the solution step? |
|
|
Either or both. |
|
|
Can 'nu' be specified in the transportProperties as a nonuniform field with specific value on each patch? |
|
|
Anyway I think we are going far from the subject of the issue. You can close it. Thank you. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-11-22 14:44 | gaZ88 | New Issue | |
| 2016-11-22 14:44 | gaZ88 | File Added: myZeroShear.zip | |
| 2016-11-22 14:55 | henry | Note Added: 0007274 | |
| 2016-11-22 15:29 | gaZ88 | File Added: postProcessing.zip | |
| 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: res1.zip | |
| 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: report.zip | |
| 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 |
