Hello Im computing an airfo
 

Hello

Im computing an airfoil in some cases in 2D. Im interested in the values for lift- and dragforces with second order for my diploma work.
I always got a strange velocity in z-direction, which made no sense. I tried all options I have, to solve this problem, but with no success. So I tried to run one tutorial ( pitzdaily ) in second order and discovered in the results a velocity in z-direction too. The look of this z-velocity in paraFoam is similar to my z-velocities in the case of my airfoil. By the way, computing the pitzDaily-case in first order with upwind, produceses no z-velocity.

For detailed information please look into my topic: "Uz-velocity in 2D" in the "Running / Solving / CFD"-section of this forum

Thx in advance
RW

If the accumulation of discret
 

If the accumulation of discretisation/round-off errors and/or round-off errors in the mesh are causing in 2D cases either the problematic component of the velocity should be explicitly removed or the empty mesh patches converted into symmetry planes in order to constrain the spurious flow in the undefined direction.

Henry

Hello Henry, thank you for
 

Hello Henry,

thank you for your reply. In my airfoilcases I changed the boundary conditions for front- and backplane already to symmetryPlane in hope to fix this problem, but even in this I get a velocity in z-direction. This z-velocity is not that high as it is in empty, but it is increasing iteration by iteration. So after xxx iterations, it may have the same value as in the empty-boundary.
If I got front- and backplane in "symmetryPlane", Uz is not converging, this may destroy my whole computation. So my values for lift and drag are flipping around.

RW

I am getting really bored list
 

I am getting really bored listening about this week after week - could you please pack up the case, I'll run it here and tell you precisely what's wrong.

Hrv

Edit: About removing the prob
 

Edit:
About removing the problematic component: Is there a easy way to patch Uz to 0 in the whole computation for example, or do I have to update some code in the solver?

Anyway, if there is no velocity in z, why does OpenFoam computes a velocity in z-direction? All Im interested in is the lift- and dragforce, but with this Uz- problem, it is hard to evalute the results. I dont know in how far the wrong Uz will have an effect on my results.

RW

Hello Hrv, thank you for yo
 

Hello Hrv,

thank you for your reply and your help. Its not my intention to disturb you the whole time, but as it is a mainpart of my diploma work, I would really appreciate a solution. I hope you understand this. Is it ok, if I mail my case to you?

RW

To remove the z-component of v
 

To remove the z-component of velocity a quick hack is to add

U.replace(vector::Z, 0.0*U.component(vector::Z));

after the velocity corrector in the PISO loop.

Henry

Hello Henry, thank you very
 

Hello Henry,

thank you very much.

RW

Hello Henry Weller, it look
 

Hello Henry Weller,

it looks like removing the z-component did the trick. My residuals look good now, my lift- and dragforces converge to a value, in the past they flipped around, the pictures in paraFoam in case of pressure, Ux and Uy look good. Looks like I can work with the results.

So, thank you very much

RW