CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Running, Solving & CFD

Preventing solving for Uz in axisymmetric cases

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Display Modes
Old   June 17, 2008, 07:52
Default Dear fellow users, I am using
  #1
New Member
 
Tammo Wenterodt
Join Date: Mar 2009
Posts: 24
Rep Power: 8
wenterodt is on a distinguished road
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 x-y-plane with an opening angle of 5deg
-only one cell in z-direction
-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 z-direction in every iteration. This does not only waste cpu-time, 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
wenterodt is offline   Reply With Quote

Old   June 17, 2008, 22:47
Default I assume that you have already
  #2
Senior Member
 
Srinath Madhavan (a.k.a pUl|)
Join Date: Mar 2009
Location: Edmonton, AB, Canada
Posts: 698
Rep Power: 12
msrinath80 is on a distinguished road
I assume that you have already seen a related thread on this issue: http://www.cfd-online.com/OpenFOAM_D...tml?1211878793
msrinath80 is offline   Reply With Quote

Old   June 18, 2008, 09:29
Default 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: 698
Rep Power: 12
msrinath80 is on a distinguished road
Correct me if I am wrong, but isn't the Y-axis 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.
msrinath80 is offline   Reply With Quote

Old   June 18, 2008, 09:32
Default Of course the blocks-line has
  #4
New Member
 
Tammo Wenterodt
Join Date: Mar 2009
Posts: 24
Rep Power: 8
wenterodt is on a distinguished road
Of course the blocks-line 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...
wenterodt is offline   Reply With Quote

Old   June 18, 2008, 10:41
Default Hi Tammo, You can use a sim
  #5
New Member
 
Shivasubramanian Gopalakrishnan
Join Date: Mar 2009
Location: Amherst, Massachusetts, USA
Posts: 15
Rep Power: 8
shivasub is on a distinguished road
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
shivasub is offline   Reply With Quote

Old   June 19, 2008, 03:05
Default Dear Shiva, thank you for you
  #6
New Member
 
Tammo Wenterodt
Join Date: Mar 2009
Posts: 24
Rep Power: 8
wenterodt is on a distinguished road
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.cfd-online.com/cgi-bin/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
wenterodt is offline   Reply With Quote

Old   June 19, 2008, 22:02
Default Hi Tammo, yes, the hack pr
  #7
New Member
 
Shivasubramanian Gopalakrishnan
Join Date: Mar 2009
Location: Amherst, Massachusetts, USA
Posts: 15
Rep Power: 8
shivasub is on a distinguished road
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
shivasub is offline   Reply With Quote

Old   June 20, 2008, 03:24
Default Shiva, I think my statement th
  #8
New Member
 
Tammo Wenterodt
Join Date: Mar 2009
Posts: 24
Rep Power: 8
wenterodt is on a distinguished road
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 1-cell-thickness in z-direction):
-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
wenterodt is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
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
Preventing negative scalar (UDS) values?? Matthew Brannock FLUENT 3 February 15, 2002 08:10


All times are GMT -4. The time now is 01:58.