[philippose]

Hello and a blue, warm Saturday to everyone :-)!

I have a question, which hopefully does not come off as being too amateur...

When using incompressible flow solvers (for example simpleFoam), with inlet and outlet boundary conditions defined as fixed pressure values, for the solver itself, only the pure difference in pressure is important, and not the absolute values of the boundary conditions...

Due to this, it is not uncommon for the pressure fields in such simulations to contain fairly large negative values.

Now... if I wanted to calculate the force on specific wall patches due to the pressure acting on these patches, normally I would use the usual:

F = Sum(P[boundary cell] * A[boundary cell face]) * [density of medium]

summed over the required boundary patches.

Suppose these patches are in regions of high flow velocity, the pressure on these patches could have fairly large negative numbers.

The question is.... how do I treat such situations? It would be physically unrealistic if I were to directly use the large negative pressure values to calculate the force. Is it fine (and legal, and physically correct), to assume:

if (p[cell] < 0) then p[cell] = 0

during the force calculation?

Will such an assumption give me forces similar to what would be measured in experiments? Or do I need to do some more corrections?

In simulations involving only the flow, I could simply increase the value of the outlet pressure to some higher absolute value, and increase the input pressure by the same offset in order to prevent negative pressures (like using the reference cell idea already existent).... but I cannot do this when I need to calculate forces, since for force calculations, it is the absolute value of the pressure on the patches that is important.

It would be great if someone would come along and enlighten me :-)!

Have a great weekend!

Philippose

[hjasak]

Hi Philiposse,

Every time you start your post in such a happy manner you really make my day - thank you.

Regarding your pressure question, let us consider 2 situations, with one starting comment. In incompressible flows, absolute pressure value is not determined by equations - they only use a pressure gradient. Thus, I should be free to add or subtract an arbitrary constant number form the complete pressure field, which I will refer to as reference pressure at reference location. The two situations are:

1) you have a closed body, eg. an airfoil. In this case reference pressure does not matter because it will cancel out: sum of face normals on a closed surface is zero. That takes care of all closed bodies, cars, planes etc.

2) You have a free flow hitting a wall. As we said, you can add or subtract a number to your pressure field, which can increase or decrease a force in an arbitrary manner: that would be wrong and physically inconsistent.

Furthermore, consider repeating the same flow simulation at a pressurised chamber at 1000 bar. The flow is still incompressible (meaning low speed, Ma << 1), and our equations are still OK. However, you do get a massive hydrostatic component not accounted for in the equations. Thus:

Is it fine (and legal, and physically correct), to assume:

if (p[cell] < 0) then p[cell] = 0

during the force calculation?

NO. This is not correct and not legal: you would be clipping a field in a arbitrary manner, the level of clipping (= force) would depend on the reference pressure value and location and in general this would be bad. Remember, it is legal to subtract an arbitrary number from your pressure field, which may make all of your wall pressure data negative.

What you should do is to pick a cell in which you know the pressure value, ideally far away from your region of interest and set the reference pressure there. If you are doing air, you can have pRef = 101325 Pa, if you are 100 meters below water, you get a bigger value, which is accounted for in the force. All clear and consistent.

Have a happy shiny Saturday yourself! (I am burried in snow...) Boo.

Hrv

[philippose]

Hello again Hrv,

Sorry for the delay in replying.... I decided to utilise the blue day for a walk in the woods :-)!

Thank you very much for that very clear and simple explanation to my doubts. It helped confirm that nagging feeling I have had for a while now regarding the force calculation method....

I was doing some thinking... and here are some points which I have in mind...

#1: In my case, the only places where I know the value of the pressure in the system, are at either the input, output or sometimes at both, the input and the output patches. Usually, one (or both) of these patches have a fixedValue boundary condition with the pressure value specified.

I was looking into the OpenFOAM source which accounts for the reference value (in fvMatrix.C), and also in the simpleFoam solver. In order to use the reference value, I need to specify the actual number of a cell where I know the pressure.

Would it be ok for me to use a cell located at either the input or the output patches as the reference cell? Or is there a problem with that?

And going further... since I have no easy means of finding out the number of a cell on one of these patches, do you think it would make sense to make it possible to set the reference by specifying the name of a patch (as an optional alternative instead of giving cell number and reference value)?

OpenFOAM could extract the value of the pressure on that patch and use it as the reference pressure. The reference cell number (again, extracted automatically by OpenFOAM), could be the number of any of the cells associated with that patch (since the patch would have a "fixedValue" boundary condition any cell would work - It would not make sense to provide a patch which does not use a "fixedValue" condition as a reference patch).

#2: Just to confirm.... if I have a closed body, this implies that I can use the usual equation for calculating the pressure forces on that body, allowing also the negative pressures into the calculation (like the way it has been calculated in for example the forceAndTorqueFunctionObject), and I should expect to see force values similar to those measured in real experiments.


What do you think of the idea in #1, and do you think it would be better if I implemented it locally, or if you made the change in the SVN? Ideal would be, if both methods are existent, so that the user has the flexibility of deciding which way to specify the reference pressure.

Have a nice Sunday!!

Philippose

[hjasak]

Hi Philippose,

I think you are complicating your life: if you know the pressure on a boundary, just specify its absolute level. The rest of the code and force calculation will take care of itself

In any case, if you have a fixed value pressure boundary, setReference function will do nothing. In that case, absolute pressure level is already known from the boundary condition and modification is not needed.

Enjoy your Sunday CFD,

Hrv

[philippose]

Hello again Hrv :-)!

Okkk... now things are making more sense :-)!! After looking at the "setReference" code yesterday, I was wondering how the system would work, if I have fixedValue boundary conditions for pressure, and additionally I give a reference pressure, which would be added onto the the whole pressure field again...

Cool... so... usually, I specify my "fixedValue" boundary conditions based on the physical absolute pressure I do the experiments with.

For example, if the inlet is 25 bar... I set the "fixedValue" boundary condition to [25*1.01325e+5]/[density of medium], and if the outlet is 1 bar, then the corresponding boundary condition becomes [1*1.01325e+5]/[density of medium].

So basically, since these values are already specified in terms of the absolute pressure, I guess I don't have to worry about the whole force calculation issue at all.... I can directly use the pressure distribution on the required patches without any changes or clipping of any sort, and run it through the force calculation equation...

Thats really nice :-)! So that basically implies that I don't need to make any changes to any of the code I have written so far... except to take out the option of clipping the field to zero.

And... I should remember not to pay too much attention to weird ideas that pop into my head on Friday evenings :-)!

Thank you very much for taking the time out to explain this to me :-)!

Have a nice week ahead!

Philippose

[zabar]

Hi all,
i try understand what is the right b.c. for force calculation. i have very simple flow domain inside a pipe as you can see in attached file.i need calculate force only on a green surface.i have velocity input ,and fixed pressure output.
note that the green part has an area protected from the flow by the black colored body.
fluid - is air, with pressure a little bit more then atmospheric pressure. Re=20000.
if i use simpleFoam with fixed pressure in the "outlet" equal to zero i have good agreement with experiment(i tried it on different geometries).
if "played" with the outlet pressure value (for example i changed it to 1e5) i have drastically changed force magnitude and the force's direction. i can understand this due the fact that the left side has a smaller area than the right side, and because the term U^2 negligible in comparison to P therm (Ptot=p+U^2/2) .
as expected i have a pressure drop between inlet and outlet equal in all cases (same velocity and flow field, different outlet pressure).
also i tried to solve it with rhoSimpleFoam (fixed pressure at outlet 10^5) and result look like result from simpleFoam with same pressure at outlet.
i feel confused.
so i want to ask you :
1. why do the results come out correct only when I use simpleFoam with zero pressure at outlet?
2.how i can solve it with rhoSimplefoam. do i need put some reference pressure anyway - if yes,where?

thanks in advance
sasha

[zabar]

Hi,
sorry i get wrong information, so problem solved.

[pizicai]

Originally Posted by hjasak

Hi Philiposse,



What you should do is to pick a cell in which you know the pressure value, ideally far away from your region of interest and set the reference pressure there. If you are doing air, you can have pRef = 101325 Pa, if you are 100 meters below water, you get a bigger value, which is accounted for in the force. All clear and consistent.



Hrv

Hi,

I have been suffered from pRef for some time, and I am glad to see your post.

below is another post I seen before;
---------------
in OF, pRef is used only if your BC are set in such a way not to prescribe any reference for the pressure
for example.
if you open a duct open to the atomosphere at the outlet, and you specified velocity at the inlet, you should specify p equal to zero at the outlet.
if you have a situation where p has only Neumann (zerogradient) conditions, the pRef value will be used , settting p=pRefVal in the cell of index pRefcell
---------------

you said "pick a cell" and it says "you specified velocity at the inlet" in the post above , I wonder how can I do this? I mean how can locate a cell and assign it as a reference cell.

Thanks for your attention, and if you have any confusion with my expression, just tell me, I will try to explain it well.

Yalong

[silvan]

I would like to discuss on this topic, but for compressible solvers. For this reason, I opened the following thread:
http://www.cfd-online.com/Forums/ope...tml#post561193

Looking forward to your good ideas and explanations!
Have a happy day,
Silvan

[faiazk]

Hello,

I hope you all are doing well. I have been following the previous posts on different topics related to CFD and Openfoam. Could you please take a look at my post

Calculating pressure coefficient on surface of an object in ABL simulation


I have been trying to simulate atmospheric boundary layer flow with a small building inside the domain. I have 0 p-value on the outlet and velocity specified on the inlet.

In order to obtain pressure coefficient on the surface of the small building, do I need to subtract or add anything from the p-value I get from paraview? Or I just can just take the P-value (pressure/rho) from paraview and process the pressure coefficient from there on?

I have been reading different posts but unfortunately, I think I am confusing myself.

Please let me know

Thank you

Regards,
Faiaz

[cyberpr123]

Hello,

I m new to openfoam, I am trying to find resistance (drag force) using interfoam, I tried to run DTChull, results came out to be well, But, when i m trying for some other vessel, pressure and viscous forces are coming out to be very high, in order of e+85, which is not normal at all.

Can anyone help me in resolving this?? What could be the reason ??
I tried few options by changing mesh sizes but failed.

Pls help.

Time = 2148

PIMPLE: iteration 1
smoothSolver: Solving for alpha.water, Initial residual = 7.29708e-005, Final residual = 5.28954e-009, No Iterations 2
Phase-1 volume fraction = 0.815793 Min(alpha.water) = -2.41545e-006 Max(alpha.water) = 1.35443
Applying the previous iteration compression flux
MULES: Correcting alpha.water
MULES: Correcting alpha.water
MULES: Correcting alpha.water
Phase-1 volume fraction = 0.815793 Min(alpha.water) = -2.41545e-006 Max(alpha.water) = 1.35443
GAMG: Solving for p_rgh, Initial residual = 1.28439e-005, Final residual = 1.03427e-007, No Iterations 3
time step continuity errors : sum local = 5.22673e+037, global = -6.09951e+036, cumulative = 9.77898e+038
GAMG: Solving for p_rgh, Initial residual = 3.75921e-006, Final residual = 7.93703e-008, No Iterations 3
time step continuity errors : sum local = 4.21171e+037, global = -4.3646e+036, cumulative = 9.73533e+038
smoothSolver: Solving for omega, Initial residual = 0.00010478, Final residual = 6.98713e-008, No Iterations 1
bounding omega, min: -1.81228e+021 max: 6.35442e+026 average: 2.03578e+024
smoothSolver: Solving for k, Initial residual = 0.000384225, Final residual = 1.98798e-008, No Iterations 1
bounding k, min: -2.55763e+014 max: 1.4019e+024 average: 3.5087e+019
ExecutionTime = 164582 s ClockTime = 164581 s

forces forces write:
sum of forces:
pressure : (4.52581e+085 -2.7136e+085 1.77392e+086)
viscous : (9.16004e+050 -1.42432e+051 1.27924e+051)
porous : (0 0 0)
sum of moments:
pressure : (-1.70696e+085 1.21296e+086 -5.91694e+085)
viscous : (-3.65584e+050 -4.75749e+050 4.2562e+049)
porous : (0 0 0)

Flow time scale min/max = 5.88292e-049, 3.61508e-038
Smoothed flow time scale min/max = 5.88292e-049, 8.83246e-044
Damped flow time scale min/max = 5.88292e-049, 8.83246e-044
Time = 2149

PIMPLE: iteration 1
smoothSolver: Solving for alpha.water, Initial residual = 7.33024e-005, Final residual = 3.88666e-009, No Iterations 2
Phase-1 volume fraction = 0.815791 Min(alpha.water) = -2.41542e-006 Max(alpha.water) = 1.35415
Applying the previous iteration compression flux
MULES: Correcting alpha.water
MULES: Correcting alpha.water
MULES: Correcting alpha.water
Phase-1 volume fraction = 0.815791 Min(alpha.water) = -2.41542e-006 Max(alpha.water) = 1.35415
GAMG: Solving for p_rgh, Initial residual = 1.20107e-005, Final residual = 9.54606e-008, No Iterations 3
time step continuity errors : sum local = 5.10977e+037, global = -2.125e+036, cumulative = 9.71408e+038
GAMG: Solving for p_rgh, Initial residual = 3.56776e-006, Final residual = 6.52874e-008, No Iterations 3
time step continuity errors : sum local = 3.46326e+037, global = -1.40111e+036, cumulative = 9.70007e+038
smoothSolver: Solving for omega, Initial residual = 0.000105244, Final residual = 7.05973e-008, No Iterations 1
bounding omega, min: -2.05451e+021 max: 6.35399e+026 average: 2.03598e+024
smoothSolver: Solving for k, Initial residual = 0.000388022, Final residual = 2.28441e-008, No Iterations 1
bounding k, min: -1.25364e+014 max: 1.40181e+024 average: 3.50822e+019
ExecutionTime = 164671 s ClockTime = 164671 s

forces forces write:
sum of forces:
pressure : (1.22343e+086 1.83395e+086 4.74901e+086)
viscous : (9.27397e+050 -1.43113e+051 1.28971e+051)
porous : (0 0 0)
sum of moments:
pressure : (-2.35683e+085 3.20271e+086 -1.59697e+086)
viscous : (-3.68524e+050 -4.69672e+050 4.74484e+049)
porous : (0 0 0)

Flow time scale min/max = 6.45755e-049, 3.59681e-038
Smoothed flow time scale min/max = 6.45755e-049, 5.96376e-044
Damped flow time scale min/max = 6.45755e-049, 5.96376e-044
Time = 2150


and this continues....