
[Sponsors] 
June 17, 2008, 07:52 
Dear fellow users,
I am using

#1 
New Member
Tammo Wenterodt
Join Date: Mar 2009
Posts: 24
Rep Power: 10 
Dear fellow users,
I am using simpleFoam for laminar calculations in axisymmetric domains. I set up the cases by the book, i.e. wedge shaped domain that straddles xyplane with an opening angle of 5deg only one cell in zdirection wedge BCs for front and back (separate patches) empty BC for axis. The calculations converge beautifully, so far no problem. BUT even though the axisymmetric problem is a 2d problem and Uz is initialized with 0, the solver tries to solve the system for the zdirection in every iteration. This does not only waste cputime, but it imposes an unnecessary error to the solution. I would be very glad to know the answers to the following questions: Is this normal behavior for axisymmetric calculations or did I miss something in the setup? Can this be prevented in some way like using "empty" patches in plane 2d calculations? Are there naming conventions that have to be obeyed? Is it possible to manipulate the solver settings or the "solve(UEqn() == fvc::grad(p))"call to achieve this? Thanks, Tammo 

June 17, 2008, 22:47 
I assume that you have already

#2 
Senior Member
Srinath Madhavan (a.k.a pUl)
Join Date: Mar 2009
Location: Edmonton, AB, Canada
Posts: 703
Rep Power: 14 
I assume that you have already seen a related thread on this issue: http://www.cfdonline.com/OpenFOAM_D...tml?1211878793


June 18, 2008, 09:29 
Correct me if I am wrong, but

#3 
Senior Member
Srinath Madhavan (a.k.a pUl)
Join Date: Mar 2009
Location: Edmonton, AB, Canada
Posts: 703
Rep Power: 14 
Correct me if I am wrong, but isn't the Yaxis your third direction according to this mesh definition?
The following statement seems to indicate the same: hex (0 1 2 3 0 1 4 5) (10 1 10) simpleGrading (1 1 1) I don't have the time to go over your setup at this point, but I do get the feeling that you're doing something fundamentally wrong here. 

June 18, 2008, 09:32 
Of course the blocksline has

#4 
New Member
Tammo Wenterodt
Join Date: Mar 2009
Posts: 24
Rep Power: 10 
Of course the blocksline has to read like this:
blocks ( hex (0 1 2 3 0 1 4 5) (10 10 1) simpleGrading (1 1 1) ); But this does not solve the problem... 

June 18, 2008, 10:41 
Hi Tammo,
You can use a sim

#5 
New Member
Shivasubramanian Gopalakrishnan
Join Date: Mar 2009
Location: Amherst, Massachusetts, USA
Posts: 15
Rep Power: 10 
Hi Tammo,
You can use a simple hack to make the Uz=0. This is how we use it in our code if we are running wedge cases. // Remove the swirl component of velocity for "wedge" cases if (piso.found("removeSwirl")) { label swirlCmpt(readLabel(piso.lookup("removeSwirl"))); U.field().replace(swirlCmpt, 0.0); } regards Shiva 

June 19, 2008, 03:05 
Dear Shiva,
thank you for you

#6 
New Member
Tammo Wenterodt
Join Date: Mar 2009
Posts: 24
Rep Power: 10 
Dear Shiva,
thank you for your reply! I tried something alike before, but I wasn't aware that it is possible to set Uz=0 with only one line of code... Setting Uz=0 in every iteration like you proposed does indeed help speeding up the iteration process since the number of iterations for Uz will decrease. However, I would like the solver not to bother about Uz at all since I am dealing with an axisymmetric (i.e. 2d) problem! Does this hack prevent your solver from solving for Uz? In that case it would be clear that I set up my case wrongly, which would be good news, since that would propably be the easiest to correct... As Hrvoje Jasak states here: http://www.cfdonline.com/cgibin/Op...0697#POST10697 the "wedge"BC will cause some transformations, but so far I can see no difference between using "wedge" and "cyclic" BC in an axisymmetric flow from the behavior of the solver. I am puzzled... Regards, Tammo 

June 19, 2008, 22:02 
Hi Tammo,
yes, the hack pr

#7 
New Member
Shivasubramanian Gopalakrishnan
Join Date: Mar 2009
Location: Amherst, Massachusetts, USA
Posts: 15
Rep Power: 10 
Hi Tammo,
yes, the hack provided from our code does not eliminate solving for Uz, it just reduces the number of iterations to something very small. As Hrv says in his post, wedge is used only when the mesh is only one cell thick in the 3rd dimension, i.e the one face will map back to the opposite face of the same cell. Whilst cyclic will be used for periodic boundaries. When you say you see no difference between using "wedge" and "cyclic", have you used both for axisymmetric cases and find no difference? regards Shiva 

June 20, 2008, 03:24 
Shiva, I think my statement th

#8 
New Member
Tammo Wenterodt
Join Date: Mar 2009
Posts: 24
Rep Power: 10 
Shiva, I think my statement there was ambigous. What I meant to say was that I can not see why there must be "wedge" type boundary condition at all, at least how it is implemented in OpenFOAM.
From a physical point of view the cyclic bc should be sufficient to model swirl in axisymmetric flows, since all variables must be the same (i.e. can be mapped directly) on the front and on the back of the domain, especially Uz. Before my first calculations with the wedge bc, I thought it would simplify the problem as to not solve for Uz, thus eliminate any swirl. This would seem reasonable to me (with 1cellthickness in zdirection): with swirl: cyclic without swirl: symmetryPlane without swirl (not solve for Uz): wedge But (and this at last is the answer to your question) OpenFOAM behaves quite differently: wedge: models swirl symmetryPlane: no swirl, looks ok cyclic: gives results that are physically impossible Still I am wondering if there is a way to model axisymmetric flow without swirl and eliminate the uneccessary solving for Uz in that case... Regards, Tammo 

August 2, 2016, 05:19 

#9 
New Member
Graham
Join Date: Feb 2016
Posts: 5
Rep Power: 3 
Hi there,
I am struggling with the same issue: I can't get the "tangential" velocity component to converge when using the wedge boundary type. It seems from above that the only way to fix it is by forcing the component to vanish at each iteration. (I don't know how to implement this.) Is there really still no official fix for this? Best regards, Graham 

March 29, 2017, 06:34 

#10 
New Member
Join Date: Mar 2016
Posts: 7
Rep Power: 3 
Hi everybody,
did anyone solved this issue? Regards. 

Thread Tools  
Display Modes  


Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Preventing negative scalar (UDS) values??  Matthew Brannock  FLUENT  4  May 3, 2017 03:48 
Axisymmetric cases and cavitation solvers in OF 15  marta_colomer  OpenFOAM Running, Solving & CFD  1  January 27, 2010 09:34 
Icemcfd: Preventing prism inflation collisions?  Joe  CFX  1  July 31, 2007 09:13 
Axisymmetric cases Test with blockmesh and icoFoam  frackowi  OpenFOAM Running, Solving & CFD  2  July 11, 2007 19:02 
Benchmark problems for axisymmetric cases in 2D  Malarvizhi  Main CFD Forum  4  February 10, 2006 01:20 