[Danubi]

Hello all,

I am studying a manifold with one inlet and different outlets. I am facing a problem and it is that I try to find the head loss in the domain and I have a negative head loss.

I am applying the well known Bernoulli's energy conservation equation that states:

p1/rho+v1^2/2 = (sum of i's) pi/rho+vi^2/2  + Head Losses

I have myself written a short postprocess to get the necessary values by getting the patchAverage of p and U at each patch and apply them to compute the head losses.

I do not have gravity (so no 'h' applies) and I do have viscosity.

I found out two weird things:
1) Head losses are negative... So kind of my domain generated pressure or velocity somehow.
2) the values that I got are different from those obtained applying the postProcess totalPressureIncompressible. (but anyway using this postprocess my domain generates mechanical energy somehow)

By the way, it is an incompressible fluid and laminar!

My boundary conditions are:
For the inlet:
p:zerogradient; U: fixedValue (fullydeveloped)
For the main outlet:
p:zerogradient; U: fixedMean (I know the guessed flowrate at this patch)
For the small outlets:
p=0; U: zeroGradient

Can anybody guess what is happening with the phenomena? Have you ever seen this?

[Danubi]

Hello I have been diving the issue.

As it can be seen in the picture I attach, I have 6 patches that are one inlet at the bottom, the main outlet on the top and 4 channels going off the manifold almost in T shape. There is a symmetryPlane in -y patch.

I have found useful the postProcessing utility totalPressureIncompressible, that computed a field of the totalPressure (i.e. dynamic(0.5*rho*U²) + static).

Now I don't understand the results.

I get for the bottom (and only) inlet total pressure the patchIntegrate value of 0.000185 Pa, and for the main (top) outlet the value of 0.000194 Pa...

Since some flow is diverting to the horizontal channels I understand that the velocity in the main outlet will drop (less flow rate for the same area) and perhaps the static pressure could raise a bit (correct me if I am wrong).

But I cannot understand how it can be possible that the patchIntegrate of the totalPressure GROWS while the fluid passes by... it makes no sense to me.

I thought then, go and see the channels patches totalPressures and check if the overall balance makes sense. By the overall balance I mean: totalP(inlet) = totalP(mainOutlet) + totalP(channels1...4) + Head Losses.
I hoped for negative values of totalP at channels but they are between 7e-7 Pa (the halved channel) and 1.38e-6 Pa.

I have also thought on evaluating the forcesIncompressible in the 'walls' of my domain, and they are:

forces forcesIncompressible write:
    sum of forces:
        pressure : (3.767630442e-05 3.867438775e-05 3.926800393e-05)
        viscous  : (-1.824451014e-05 6.674296175e-07 3.468651248e-05)
        porous   : (0 0 0)

I thought that perhaps due to the fact that the fluid is not fully developed at the outlets this could affect... by I don't think this can justify such incoherency.

Thanks in advance,

Dan

[Danubi]

To those who ever stuck in the same situation. I have solved it.

I thought perhaps I had to analyze it in a steadyState solver (SIMPLE) instead that in the PISO solver, due to some possible weird pressure accumulation within the domain... who knows...

I was wrong, since the SIMPLE returned the same incoherency, but I was very surprised that it didn't converge at all. I have been modifying the fvSchemes and fvSolutions dictionaries.

In one of those modifications I had modified, wihtout any hope the gradSchemes, from faceLimited leastSquares 1.0 (which I thougth it was an amazing scheme) to the simple and common Gauss Linear... Suddenly residuals dropped and convergence was obtained instantaniously!

I modified the PISO case and it worked!

Regards all

[Danubi]

Hi all again,

I had been working last weeks in this pressure drop issue. After some work I managed to validate a laminar openFoam case of a square duct to the Darcy-Weisbach (DW) head loss equiation. My precedure was, after computing the case and have it converged with SIMPLE:
1- Calculate total(p) in inlet and outlet patches. Total(p) comes out of executing the totalPressureIncompressible postProcess.
2- Find out the patchAverage of total(p) in each patch.
3- Compare: (total(p)inlet-total(p)outlet)/pipe_length must equal DeltaP/L of DW equation.

When I had to apply this simple validation case procedure to the manifold I am working on, as I applied patchAverage(total(p)) to each patch, I got negative values of pressure drop (again). Then I realized that somehow I need to take patch areas into account.

As I understand from momentum equation in a steady state the sum of all forces must equal zero. Therefore total(p)*A must be the force applied in each patch.

Ok so I applied the postProcess patchIntegrate to obtain the force=total(p)*A at each patch and then I applied the following expression: force_inlet - force_outlets = friction_forces.

Now friction_forces were of positive sign (good).

Analyzing carefully the results I found that in some outlet patches there were some eddies, so some part of the outlet patch had inlet flows.

Here it comes my question:

Total(p) = p+rho*u²/2 [Pascals]. This is a scalar. By doing patchIntegrate I am adding all those scalars, and when I arbitrary give a sign to the force balance, I am assuming an inlet/outlet direction of the patch.

Shouldn't my force balance take into account this velocity inlet/outlet direction?

I have thought to modify the total(p) postProcess and call it perhaps total(p)_dir, so that it is able to return negative values on patches when velocity direction goes outwards and positive then inwards, I would therefore be able to asses my friction forces by only the total(p) sum of all patchIntegrates values, regardless of what I think is inlet or outlet...

Does it make any sense? Am I right/wrong?

I have made a test case for this. I attach an image of this test case where total(p) can be seen always positive in a patch with a pressure field fixedValue (uniform 0) and a velocity field is coming in and out. It can be seen that total(p) doesn't take care if velocity goes in or out.

Thank you for your patience.

[dickcruz]

Originally Posted by Danubi

Hi all again,

I had been working last weeks in this pressure drop issue. After some work I managed to validate a laminar openFoam case of a square duct to the Darcy-Weisbach (DW) head loss equiation. My precedure was, after computing the case and have it converged with SIMPLE:
1- Calculate total(p) in inlet and outlet patches. Total(p) comes out of executing the totalPressureIncompressible postProcess.
2- Find out the patchAverage of total(p) in each patch.
3- Compare: (total(p)inlet-total(p)outlet)/pipe_length must equal DeltaP/L of DW equation.

When I had to apply this simple validation case procedure to the manifold I am working on, as I applied patchAverage(total(p)) to each patch, I got negative values of pressure drop (again). Then I realized that somehow I need to take patch areas into account.

As I understand from momentum equation in a steady state the sum of all forces must equal zero. Therefore total(p)*A must be the force applied in each patch.

Ok so I applied the postProcess patchIntegrate to obtain the force=total(p)*A at each patch and then I applied the following expression: force_inlet - force_outlets = friction_forces.

Now friction_forces were of positive sign (good).

Analyzing carefully the results I found that in some outlet patches there were some eddies, so some part of the outlet patch had inlet flows.

Here it comes my question:

Total(p) = p+rho*u²/2 [Pascals]. This is a scalar. By doing patchIntegrate I am adding all those scalars, and when I arbitrary give a sign to the force balance, I am assuming an inlet/outlet direction of the patch.

Shouldn't my force balance take into account this velocity inlet/outlet direction?

I have thought to modify the total(p) postProcess and call it perhaps total(p)_dir, so that it is able to return negative values on patches when velocity direction goes outwards and positive then inwards, I would therefore be able to asses my friction forces by only the total(p) sum of all patchIntegrates values, regardless of what I think is inlet or outlet...

Does it make any sense? Am I right/wrong?

I have made a test case for this. I attach an image of this test case where total(p) can be seen always positive in a patch with a pressure field fixedValue (uniform 0) and a velocity field is coming in and out. It can be seen that total(p) doesn't take care if velocity goes in or out.

Thank you for your patience.

Hello Danubi,

I'm sorry that no one else has taken interest in your posts here. I have a question for you, when you did your pressure subtraction, did you multiply your pressure data by the density of your fluid?

[Danubi]

Hello JD,

I indeed took into account the density. I just last week found out the solution, which took me several months...

As I see, there is no builtin application in OpenFOAM that calculates properly the pressure drop in such a consistent and robust way that it can work for any case.

I eventually did my own postProcessing tool.

If you are interested, the key is to work out the energy conservation equation. You can find it very well explained in the following link:

Sample_Chapter_McGrawHill

Note the alpha correction factor for the kinetic energy term, because it is of severe importance.

Regards!