|
[Sponsors] |
Symmetric 3D Cylinder solver doesn't converge |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
February 27, 2013, 13:11 |
Symmetric 3D Cylinder solver doesn't converge
|
#1 |
Member
Join Date: Feb 2012
Posts: 35
Rep Power: 14 |
Hi Foamers,
I'm experiencing a problem with my solver. I have a 3D cylinder mesh, filled with air, with a rotating top lid at a constant angular velocity. I set my solver starting from pisoFoam, which is an incompressible fluid solver, and then I modified it, introducing all needed for a compressible fluid. Before I run it on the whole cylinder mesh and everything worked well; but after I decided to decrease the calculation effort by means of using just 1/4th of the cylinder cutting it by the 2 available symmetry planes. So, in brief, now I'm running on a 90° part of a cylinder. Since I changed the geometry, the calculation blows up very soon, with just a few time steps, either with bigger or smaller timesteps and independently on the mesh size. I think I defined in a proper way the two simmetry plane with a simmetryPlane patch and every paramether in "0" folder has this defined. Going deeper into the calculation results, I understand that the U velocity calculation is responsible for this and it seems that the BC defined as symmetryPlane are considered as a wall instead; I see this because I have z components of U along the cylinder height which are not expected at all. I'm wondering if there is something else I should define also for a symmetric calculation which I don't know, or if there is some known problem with this issue. Ah, the turbulent model is k-epsilon. Thanks in advance! Matteo |
|
February 28, 2013, 12:29 |
|
#2 |
Member
Join Date: Feb 2012
Posts: 35
Rep Power: 14 |
Has somebody experienced my same troubles with a symmetric volume?
I attach here below a picture of Uz component rising after one timestep (deltat=0.05 s) and of U. I'm expecting not having such a Uz component. I also attach U dictionary file with the starting boundaries values. Code:
FoamFile { version 2.0; format ascii; class volVectorField; object U; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // dimensions [0 1 -1 0 0 0 0]; internalField uniform (0 0 0); boundaryField { top { type rotatingWallVelocity; origin (0 0 10); // è l'asse di rotazione rispetto all'origine degli assi axis (1 1 1); // deve rimanere sempre uguale a (1 1 1) omega constant 1; } side { type fixedValue; value uniform (0 0 0); } bottom { type fixedValue; value uniform (0 0 0); } oneSym { type symmetryPlane; } twoSym { type symmetryPlane; } invisible { type zeroGradient; } } |
|
February 28, 2013, 12:58 |
|
#3 |
Senior Member
Niels Gjoel Jacobsen
Join Date: Mar 2009
Location: Copenhagen, Denmark
Posts: 1,900
Rep Power: 37 |
Hi Matteo,
A symmetry plane does exactly what the name suggest, namely that it keeps the flow variables symmetric across the patch. For all scalar quantities this results in a zeroGradient condition, whereas the component of a vector normal to the patch most be zero, because that it the only possibility. I believe that what you are after is to specify cyclic boundary conditions on the two patches. I have never used them for that type of layout, but the boundary condition do perform a transformation of vectors due to changes in direction of the normal vector for the two patches, thus it should work. An alternative, again something I have never tried, is to consider whether you could benefit from the wedge-type boundary condition. Many post are available on this topic on the forum. Good luck Niels |
|
March 1, 2013, 03:42 |
|
#4 | |
Member
Join Date: Feb 2012
Posts: 35
Rep Power: 14 |
Quote:
thank you for you reply. Now, everthing is clearer to me. I just don't understand how and when using symmetryPlane by the way....I thought it should be implemented for symmetric volume, diving it by means of symmetry axis and mirroring the result of a slice of the volume on the whole volume. What you say about zeroGradient of scalar and vector quantities makes sense to me for my actual results. As suggested by you, I will try to define cyclic or wedge patches, but I have to investigate more about their implementation. Thank you again for now! Matteo |
||
April 21, 2014, 23:51 |
|
#5 | |
New Member
Chad
Join Date: Sep 2011
Posts: 16
Rep Power: 14 |
Quote:
Hi, Matteo, I have exactly the same issue. Do you have any idea how to do with symmetryPlane in OpenFOAM? Thanks in advance. Chao |
||
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
different results between serial solver and parallel solver | wlt_1985 | FLUENT | 11 | October 12, 2018 08:23 |
OpenCL linear solver for OpenFoam 1.7 (alpha) will come out very soon | qinmaple | OpenFOAM Announcements from Other Sources | 4 | August 10, 2012 11:00 |
inviscid 2d computation for M=0.3 flow past cylinder on fine mesh can not converge | boubalos | Main CFD Forum | 3 | March 20, 2011 04:26 |
Working directory via command line | Luiz | CFX | 4 | March 6, 2011 20:02 |
Getting too many iterations by velocity solving (aborting). Changing U - Solver? | suitup | OpenFOAM Running, Solving & CFD | 0 | January 20, 2010 07:45 |