CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Running, Solving & CFD (https://www.cfd-online.com/Forums/openfoam-solving/)
-   -   strange pressure behaviour with symmetricPlane boudary condition - interFoam (https://www.cfd-online.com/Forums/openfoam-solving/92524-strange-pressure-behaviour-symmetricplane-boudary-condition-interfoam.html)

duongquaphim September 16, 2011 10:46

strange pressure behaviour with symmetricPlane boudary condition - interFoam
 
3 Attachment(s)
Dear Foamer,

Recently, I tested symmetricPlane boundary condition with interFoam solver and found quite strange pressure behaviour. My problem is rather simple:

- A 2D straight channel with dimension of 310x15 micrometer
- Uniform inlet velocity of 0.003m/s and zerogradient pressure
- Uniform outlet pressure of 0Pa and zerogradient velocity
- The top is symmetricPlane
- The bottom is wall
- Only one phase stay in the channel

I ran the case and the results (velocity and pressure) look fine until 1.5ms. After that, there is an increase of pressure and velocity at both inlet and outlet (as in the attachments). Then those high pressure and velocity propagate into the channel and the results look even much strange. The case is also included if anyone want to take a look.

And I should mention here that I had the above problem with two-phase flow simulations (droplet in a channel) so I decided to test again with only one phase (this case) and still got the same weird results.

It really took me quite sometime but still not understand the reason of that behaviour. It would be very appreciative to hear comments from you on that.

Thanks,

Duong

Andrea_85 December 1, 2011 08:49

Hi Duong,

i faced the same problem as you with symmetric Bc and interFoam. Some strange behaviours near the symmetry wall in the pressure and velocity solution that i can not understand. Did you solved it?


best
andrea

robbirobocop December 1, 2011 09:02

I faced the same problem in a 0.5 million cell case.
Changing "symmetryPlane" to "zeroGradient" fixed the strange velocity behaviour at the symmetry patch. So maybe check that one out!

Andrea_85 December 1, 2011 10:19

Hi again,

What you mean with "zeroGradient"? on the velocity? What you used for pressure?

In my case i have an inlet and an outlet (top and bottom of a rectangular domain) and the flow is from top to bottom, so doesn't matter what happens on the right and left side, but i prefer not to use "no flow". I solved the issue using cyclic condition but i'm curious about why symmetry plane doesn't work.

best

andrea

robbirobocop December 2, 2011 03:04

I used zeroGradient for everything (k, eps, alpha1, U, p_rgh).

I think symmetryPlane might not work if your "patch" is not meshed well. But that's just my opinion and might as well be wrong.

In duongquaphim's case the grid is probably not the problem.

I was trying out his case but since it was build with OF 1.6. I was too lazy to actually change fvSolution and so forth to get it working with OF 2.0.

So maybe Andrea you could check your case with the "zeroGradient" BC and tell me if it works better with it?

duongquaphim December 2, 2011 05:27

Hi,

I am struggling with this problem for more than two months without any solutions. I already reported a bug at http://openfoam.com/bugs/ with job ID 0000297 but still didn't get respond yet. It might be good if you guys can also join and report that problem.

@ Andrea: I did not resolve it yet. Tried different way but still get the same errors.

@ Rob: I dont think zeroGradient will be a good alternative for symmetryPlane since there is a difference between them. In symmetryPlane, the normal velocity of that plane should be 0 and zero gradient for other variables. So using zeroGradient for all of variables is not a proper way I think.

I tried to mimic symmetryPlane bc by applying bc like

- U: mixed boundary condition: zero normal fixed value, zero tangential gradient
- p and alpha1: zerogradient

but still get the same behaviour: after a while there are some pressure accumulation close to the outlet and then propagate back into the domain. That creates a strange pressure and velocity distribution.

I am looking forward to your comments on this.

Regards,

Duong

Andrea_85 December 2, 2011 08:31

Hi Duong,
i agree on the fact that zeroGradient and symmetryPlane are not the same BC, so it depends on what you want to have on that patch.
in my case the symmetry plane is close to another patch (a wall) and so maybe this closeness could create problems. The strange think is that the problem appears only using a fine mesh and not if i use a coarse mesh. Have you tried changing the discretization?

best

andrea

duongquaphim December 2, 2011 08:43

Hi Andrea,

That is true. In my case, I like to simulate flow at the T-junction. And Reynolds number is small, I have laminar flow. Therefore, I will have a symmetry plane which split T-junction into two symmetric part. That's why I am interested in symmetryPlane bc. And I can't use zeroGradient in my case.

I've tried a couple of discretization schemes but it is not work. for one phase flow simulation in a straight channel, using Momentum predictor (in FvSolution) helps but if I applied that to a T-junction, that predictor creates another problem.

As far as I found, in the straight channel case, there is a change in direction of velocity at the outlet: small velocity in normal direction appears at the intersecting cell between my symmetryPlane and the outlet. But at the symmetryPlane patch, normal velocity is 0. I think due to that, this velocity increases and increases and also propagates back to the internal domain. That leads to the accumulation of velocity and pressure.

I don't know if it is really the reason for this problem. I haven't found a solution yet :(. Also I didn't notice on the mesh-dependent part you mentioned. I will give it to try.

Cheers,

Duong

duongquaphim July 26, 2012 10:58

Hi,

For all who are concerning on this BC behavior, I got a solution:

1) Use momentumPredictor (set in fvSolution)
2) Increase number of corrections in PISO (nCorrectors in fvSolution) to around 6-8. You can play with that number by looking at the initial residual of p in the log file. If the residual decreases to 10^(-5), it is enough I think.

By doing that I got the much better results. Also according to Hrvoje's comments, this problem usually appears in microscale cases.

Cheers,

Duong

mxylondon August 20, 2013 03:10

I am struggling on this issue now, will let you guys know the result.

mxylondon August 20, 2013 14:00

Oh, yes, Duong's method is great! I have tried it with good result.


All times are GMT -4. The time now is 08:21.