[mgdenno]

Hello,

I am experiencing weird results at the outlet of a tank I am trying to simulate. The simulation is a tank that is open to the atmosphere at the top and has two pipes in the bottom, one is the inlet (taller one) and one is the outlet (shorter one). Solver is interFoam.

Overview

Both the inlet and outlet pipes have fixed value velocities of 0.77 m/s in the z-direction. The inlet seems to work as needed but the outlet does not. It appears (I believe) that because the outlet boundary is a vector acting in the negative z-direction, the y-direction and x-direction components of the flow approaching the outlet ultimately get reflected back upward back into the domain. Does this makes sense? See the following images and boundary conditions.

Based on what I am seeing it appears that the fixed value outlet boundary is not correct for what I am trying to achieve. Is there an average magnitude outlet boundary such that the outlet flow rate is maintained but the direction of the velocity vector is not limited to being normal to the patch? Any other suggestions? I would like to be able to control both the inlet and outlet flow rates.

Alpha1 Slice

Velocity Slice

Velocity Slice Close-up

U

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  2.2.0                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       volVectorField;
    object      U;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions      [0 1 -1 0 0 0 0];

internalField   uniform (0 0 0);

boundaryField
{
    inlet
    {
        type            fixedValue;
        value           uniform (0 0 0.7700);
    }

    outlet
    {
        type            fixedValue;
        value           uniform (0 0 -0.7700);
    }

    "walls_.*"
    {
        type            fixedValue;
		value           uniform (0 0 0);
    }

    atmosphere
    {
        type            pressureInletOutletVelocity;
        phi             phi;
        value           uniform (0 0 0);
    }

}

// ************************************************************************* //

p_rgh

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  2.2.0                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       volScalarField;
    object      p_rgh;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions      [1 -1 -2 0 0 0 0];

internalField   uniform 0;

boundaryField
{
    inlet
    {
        type            buoyantPressure;
        value           uniform 0;
    }

    outlet
    {
	    type            inletOutlet;
	    inletValue      uniform 0;
	    value           uniform 0;
    }

    "walls_.*"
    {
        type            buoyantPressure;
        value           uniform 0;
    }

    atmosphere
    {
        type            totalPressure;
        p0              uniform 0;
        U               U;
        phi             phi;
        rho             none;
        psi             none;
        gamma           1;
        value           uniform 0;
    }

}

// ************************************************************************* //

alpha1

/*--------------------------------*- C++ -*----------------------------------*\
| =========                 |                                                 |
| \\      /  F ield         | OpenFOAM: The Open Source CFD Toolbox           |
|  \\    /   O peration     | Version:  2.2.0                                 |
|   \\  /    A nd           | Web:      www.OpenFOAM.org                      |
|    \\/     M anipulation  |                                                 |
\*---------------------------------------------------------------------------*/
FoamFile
{
    version     2.0;
    format      ascii;
    class       volScalarField;
    object      alpha1;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //.

dimensions      [0 0 0 0 0 0 0];

internalField   uniform 0;

boundaryField
{
    inlet
    {
        type            fixedValue;
	    value		    uniform 1;
    }

    outlet
    {
        type            inletOutlet;
        inletValue      uniform 1;
        value           uniform 0;
    }

    "walls_.*"
    {
        type            zeroGradient;
    }

    atmosphere
    {
        type            inletOutlet;
        inletValue      uniform 0;
        value           uniform 0;
    }
}

// ************************************************************************* //

[wyldckat]

Greetings Matthew,

From what I could very briefly see, specially when I look at "p_rgh", I think you should read this: http://www.cfd-online.com/Forums/ope...tml#post404292 post #7

Best regards,
Bruno

[mgdenno]

Bruno,

Thank you for the suggestion. I have initialized the p_rgh field using funkySetFields. I will post back with my findings.

Matt

[mgdenno]

Just a quick update: I ran the simulation after initializing the the p_rgh field, but unfortunately it did not change the result.

Any other thoughts?

[wyldckat]

Hi Matthew,

Can you show the snapshot of the "p_rgh" field at time "0" and another from a time a little bit later?

In addition, a snapshot that shows what the mesh looks like.

Best regards,
Bruno

[mgdenno]

Hi Bruno,

Thanks for your interest in my problem. I have created the screen shots that you requested, and a few extras too.

Here is of the p_rgh field at t=0 seconds . This reflects to field values that I set using setFields which I calculated in a spreadsheet shown here.

Here is the p_rgh field at t=1 second re-scaled to show the full range of values.

Here is a closeup of the mesh and the velocity field.

Here is a screen shot (at t=1) only showing the range of p_rgh values between the maximum value at t=0 and the maximum value at t=1, and here is a similar close-up of the outlet.

Thanks again.

Matt

[wyldckat]

Hi Matthew,

From the image with Uz of the mesh at the outlet, it looks like you've got serious mesh resolution problem. Basically you're seeing the opposite of a jet stream. I'll try to explain without images:

1. Imagine the jet coming out of an F-16 jet engine.
   • Something like this: http://www.astecinc.com/images/produ...et_image1b.jpg
   • Or better yet, something like this: http://iutp.univ-poitiers.fr/gte/IMG..._bruleur-2.jpg
2. Now, imagine that you generated a mesh over the jet, where the mesh refinement is only greater from the engine outlet to half of the jet's length.
3. What do you see after this more refined region? A big blob of kinetic energy trying to flow away from the jet engine

So, my advice, based on these images you've shown, is to increase the refinement zone around the outlet, so that the simulated fluid can better reflect the real nature of the flow.


Another advice is to first simplify you case into a 2D case. This way you can first diagnose what you need to do in this case, for the mesh and the boundary conditions.

Best regards,
Bruno

[mgdenno]

Bruno,

Thank again for your help.

I had considered setting up a 2D version for this case, but thought that this one was going to be straight forward. That was foolish of me .

Anyway, I have now setup a 2D case with the same mesh refinement as the 3D case. Oddly, it doesn't suffer the same problem as the 3D case, but this may be because the flow patterns in the 2D case are quite different than the 3D case due to the inlet and outlet pipes obstructing the entire domain instead of just a small part like in the 3D one.

Here is a screen shot of the 2D case.

I think I will try adding refinement to the 3D case and try that.

I will report back with my results.

Matt

[mgdenno]

Hi Bruno,

So, I added some more refinement near the inlet and outlet of the tank. The resulting velocity (in the z direction) is here and a close-up showing the mesh refinement is here. At this point the cells nearest the outlet are approximately 0.01 meters and the velocity through the outlet is 0.77 m/s. Unfortunately the behavior seems to be the same only more well defined. Do you think that the mesh needs more refining? Or maybe the wrong boundary condition? Or as I am writing this I am thinking that I haven't really tried any different discretization schemes.

I currently have for the velocity:

div(rho*phi,U)  Gauss upwind;

I think I will try a second order scheme and see what happens.

Matt

[akidess]

Originally Posted by mgdenno

Hi Bruno,

I think I will try a second order scheme and see what happens.

Matt

I strongly doubt that will help. A second order scheme will reduce diffusion, but diffusion is not the culprit here. Either your boundary conditions at the outlet are not appropriate, or your simulation is not converging. Did you compare your boundary conditions with tutorial cases, e.g. interFoam/ras/waterChannel?

- Anton

[immortality]

setting velocity at outlet isn't correct.you better set there the pressure.

[mgdenno]

Sorry for the delayed response. I appreciate your feedback, but got wrapped up in some other projects.

@Anton
You are correct. The schemes had little to no affect on the behavior that I am seeing. I also suspected that this would be the case, but thought that I would see for myself. Thanks for the recommended tutorial case. I have run quite a few what I will call "open channel" cases successfully in the past, unfortunately, this tank case with a specified outlet flow rate has some interesting (unwanted) behavior at the outlet. I feel certain that it is an issue with the outlet boundary condition; in order to specify a flow rate it appears that the available BCs assume the flow is normal to the face. I believe that this is the source of my problems.

@immortality
I have tried the pressure boundary in the past and it works fine, except it doesn't give me the easy control over the outlet flow rate that I was hoping for. However, I may have to reconsider the setup such that I can use the pressure boundary instead.

Thanks

Matt

[wyldckat]

Greetings to all!

@Matt: I was going to suggest that you set the pressure BC on the inlet and outlet to zero gradient, but then it came to me:

• What's the actual inlet and outlet area/diameter sizes?
• Have you confirmed in ParaView?
• Are you using the mesh/geometry in millimetres or in metres?
• Have you confirmed that you're using the correct fluid properties?

Because if my guess is correct, the geometry/mesh is in millimetres and 0.77 m/s at either inlet/outlet implies that you'll see some gruesome water effects, such as the sort-of-capillary-rise of the backlash at the outlet, where the water being sucked out from the sides squeezes the water near the centre axis into going up and at higher speeds!

Best regards,
Bruno

[immortality]

Hi Bruno
whats gruesome water effects?

[wyldckat]

Hi Ehsan,

Originally Posted by immortality

whats gruesome water effects?

Well... imagine any task you do every day, such as opening a door or picking up a glass. Now imagine that you use 1000 times the nominal force you usually use. What would happen to the door and glass?

This is the kind of image I was trying to convey. By using 0.77 m/s on an inlet or outlet, where the size of said inlet/outlet are 1000 times smaller then they were meant to be, then it means that the fluid will have to be sort-of-squished 1000 times more than it was originally intended. Which is what I deduce that is what's occurring in this case, since the outlet is squeezing a massive jet of fluid in the wrong direction!

Or imagine the opposite: if the geometry was at the right scale, but the fluid were set to move 1000 times faster, that would mean 770 m/s. Water at this speed is... well... extremely dangerous?

Best regards,
Bruno

[mgdenno]

Hi Bruno,

I believe that my geometry is in meters as intended and that the fluid properties are correct (water and air). I have checked the dimensions in paraview and they are appear to be correct.

While using a pressure outlet boundary seems to solve the issue of the flow being reflected back into the domain, I was hoping to eventually be able to specify time series inflow and outflow pumping rates and see how the flow patterns in the tank change. This would require that I be able to specify flow rates at both the inlet and the outlet to the tank.

I am thinking that in order to specify a flow rate at the outlet I may need to change the extent of my domain to include part of the outlet pipe, such that the point where the flow is converging to exit the tank is not at the boundary. Thoughts?

The case can be found here if anyone is interested. This case is not a real project case, but just a test case to iron out this kind of issue before starting any "real" cases.

Any feedback is welcome.

Matt

[wyldckat]

Hi Matt,

Many thanks for sharing the case! I think I found the reason why you have the outlet re-injecting flow back into the tank

Remember when we talked about mesh resolution? Well, there are two more details you should have checked:

1. Time resolution, but only in the sense of inspecting what was happening around the outlet. And what happens during the first second is extremely important, so you should have saved more time snapshots for the first second.
2. Resulting from the previous point, the conclusion is that the extension of the high resolution zone around the outlet is not nearly enough for the flow to properly stabilize!

I honestly have to say that this is another one of those crazy CFD cases I really like! Check the sequence of attached images!

So, what I did for examining this case, was:

1. Change the run time settings in "controlDict" to simulate only 1 second and to save every 0.01s.
2. Used the "Slice" filter to view the flow near the outlet.
3. Changed the representation to Uz and the scale limits to around +-0.095 m/s.
4. Applied the "Glyph" filter to the "Slice" entry and chose to display the glyphs as 2D arrows, with the "Scale Mode" off, the respective factor at 0.02 and unchecked the "Mask Points" option.

The explanation of what happened is as follows:

1. After 0.01s, the flow was already well oriented, after some pressure adjustment had already occurred.
2. At around 0.06s, a circulation centre appeared (aka a vortex) near the centre of the outlet boundary.
3. At around 0.15s, there is a clear shape inside the refined zone, which looks like a ball-reshaped vortex of fluid (imagine a conic vortex, constrained a bit at the top of the cone).
4. This shape is moving upwards, away from the outlet.
5. At around 0.25s, the centre of this ball-reshaped vortex hits the boundary between the high refinement zone and the lower refined zone of the mesh, near the outlet.
6. After that, at around 0.28s, the ball-reshaped vortex is changing shape, due to the loss of mesh resolution, leading the Finite Volume algorithm to do it's best to preserve the mass flow inside the cells. This makes the centre of the vortex completely change its dynamics and it's as if the refinement boundary became a flow bouncing wall.
7. At around 0.33s, the centre ball-reshaped vortex completely outside of the high refinement zone and has got a centre of upward flow of around 0.04 m/s!
8. At around 0.36s, the centre of the vortex has already managed to create a massive upward suction effect (>0.09 m/s) near the boundary between refinement levels, which has already lead the FV algorithm to propagate the suction effect from the centre of the high refinement zone!
9. At around 0.60s, the high suction effect that was felt inside the high refinement zone, has reached the boundary between the levels. And the awesome detail is that the centre inside the high refinement zone has already reached an upward speed of 0.985 m/s!
10. At 1.0s, the end of my simulation, shows that the maximum upward speed reduced to 0.935 m/s and is located above in the lower refinement zone.

And so, the reason for the problem is now explained! It's not the boundary conditions themselves to be blamed here, nor a problem with a high Courant number, nor even the schemes! The problem is the mesh refinement that is not respecting the requirements of the flow itself.


In a few minutes I'll upload the modified case to my Dropbox account, along with some images of the flow.

edit: The links to the files on my Dropbox:

• This is the slightly modified case I used for the diagnosis (6MB): https://www.dropbox.com/s/6wyycur7qa...ank_3D.7z?dl=0
• This is the full image sequence, with snapshots every 0.01s from 0.0s to 1.0s (25MB): https://www.dropbox.com/s/j8groc8skb...quence.7z?dl=0
• This is the Summary sequence, with 10 evenly spaced snapshots from 0.01s to 1.0s (4MB): https://www.dropbox.com/s/i1hgy31f7g...quence.7z?dl=0

Best regards,
Bruno

[mgdenno]

Wow, Bruno thanks for looking at the case and for providing such a detailed description of what is happening and how you came to the conclusion. I am just getting back from traveling (away from the internet ). I am going to download the files you uploaded right now an dig into them. I will post back after I have had a chance to process.

Also, I am almost done developing a new mesh that also includes the outlet pipes. It should be interesting to see how the solution for the new mesh compares. I will share it once it is "done".

[Bodo1993]

Hi,

I am wondering if the mesh refinement worked for you to resolve the case of vortex initiation.

Thanks and looking forward to hearing from you.