[sharonyue]

Hi guys:

In the dambreak tutorial,water is set to the right side of the box. after I set the alpha is like this:you can see the mesh is fine.

but what happend to the velocity field? I just alter the alpha field. and it should be stationary.so the velocity should be zero rite?

[wyldckat]

Greetings Forrest,

Without knowing the exact steps you've taken, it's a bit complicated to replicate your images... so... what exact steps did you take?

Best regards,
Bruno

[sharonyue]

Originally Posted by wyldckat

Greetings Forrest,

Without knowing the exact steps you've taken, it's a bit complicated to replicate your images... so... what exact steps did you take?

Best regards,
Bruno

hi Santos~

The time step is absolutely the same with the original dambreak tutorial. What I change is ONLY the alpha field.

defaultFieldValues
(
    volScalarFieldValue alpha1 0
);

regions
(
    boxToCell
    {
        box (0 0 -1) (1 0.292 1);
        fieldValues
        (
            volScalarFieldValue alpha1 1
        );
    }
);

This is my setfield dictionary. try it and blockMesh setFields ,interFoam. and see the weired velocity field. ~






contralDict is attached.

application     interFoam;

startFrom       startTime;

startTime       0;

stopAt          endTime;

endTime         1;

deltaT          0.001;

writeControl    adjustableRunTime;

writeInterval   0.05;

purgeWrite      0;

writeFormat     ascii;

writePrecision  6;

writeCompression uncompressed;

timeFormat      general;

timePrecision   6;

runTimeModifiable yes;

adjustTimeStep  yes;

maxCo           0.5;
maxAlphaCo      0.5;

maxDeltaT       1;

[insane_alien]

It's likely to be to do with the mesh. There is a different mesh size used above the obstacle, the boundary between these meshes is likely causing the issue.

i'm suprised there is not also an effect in the areas lower than the top of the obstacle as there is also a mesh boundary there.

[wyldckat]

Greetings to all!

Stephen is right about the mesh. Since the cells aren't evenly shaped, they induce the concentration of those vortices.

After doing some tests, since I was very curious about this and I finally had the opportunity to play with it, here's what I found out:

1. If the mesh is uniform, namely with the following adjusted sizes:
   

       hex (0 1 5 4 12 13 17 16) (46 8 1) simpleGrading (1 1 1)
       hex (2 3 7 6 14 15 19 18) (38 8 1) simpleGrading (1 1 1)
       hex (4 5 9 8 16 17 21 20) (46 84 1) simpleGrading (1 1 1)
       hex (5 6 10 9 17 18 22 21) (4 84 1) simpleGrading (1 1 1)
       hex (6 7 11 10 18 19 23 22) (38 84 1) simpleGrading (1 1 1)

   Then you won't see as much preferential concentration of vortices. They'll be more inclined to form as an influence of the corners.
2. Boundary conditions:
   1. The top is a "pressureInletOutletVelocity"/"totalPressure" boundary, which means that air can flow in and out through that opening and that "total pressure" calculations are used.
   2. Left, right and bottom are basically all walls, so nothing gets through.
3. The lower part filled with water can't move, since there is nowhere to go and it's too heavy, in comparison with air.
4. If you use glyphs to see the direction where the velocity, you'll see vortices forming... more specifically, at the first 0.2s, it looks as if the air is falling.
5. If you think about the initial fields, the speed is all zero, alpha is what we can see in the first post, and the pressure is all 0 as well, since it's calculated in reference to a pressure level.
6. But the pressure is being calculated taking into account the weight of the fluids, i.e. the "rgh" part (rho * gravity acceleration * height). But if the whole pressure field starts at 0, then it needs to flow into equilibrium, in order to respect the weight-induced pressure distribution... which is why it looks like the air is falling!

In theory, after several seconds, if not hours, the air should all come to a stand still.

Now that I come to think of it, I very vaguely remember some presentation on this subject...


Anyway, there you go, the result is explained

Best regards,
Bruno

[sharonyue]

Hi Bruno,

Thanks very much. just as you said ,Its caused by the mesh. but I cant catch whats this mean.

Originally Posted by wyldckat

If you think about the initial fields, the speed is all zero, alpha is what we can see in the first post, and the pressure is all 0 as well, since it's calculated in reference to a pressure level.

But the pressure is being calculated taking into account the weight of the fluids, i.e. the "rgh" part (rho * gravity acceleration * height). But if the whole pressure field starts at 0, then it needs to flow into equilibrium, in order to respect the weight-induced pressure distribution... which is why it looks like the air is falling!

can you explain it more explicitly?

And I tried some other cases.

1) alpha is uniform 0; namely its all air. and in 1 sec, the max is 9e-30,looks like its normal.the image is attached.

2) alpha is uniform 1, its totally water. and I set the BC is this:

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

so the water can get in and out .and in 1 sec. I get the same velocity field, the max is 9e-30,I think its normal too.so dont need the image.

3) alpha is uniform 1, its totally water too. and I set

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

namely the air can get in and out. I got this:the image is attached.


What confused me is, in reality, if there is a bottle filled with water(for example 3 in which air can flow)， There should not be like air can drop in the water,even like this there should be much more bubbles.

Why I am testing this is because when I am doing my 3D case I find the same problem about the velocity.so I turn to the dambreak tutorial and make a comparision.then problem arises.

Well, You absolutely handled much problems,if you can explain it more ,I would be very grateful.Thanks in advance.

[wyldckat]

I didn't show any images before because it seemed simple enough. First about the set-up in ParaView:

1. I jumped to time = 1s, set to display the "p_rgh" field and changed the scale to logarithmic.
2. Added the source "Annotate Time".
3. Then went back to 0s.

The mesh is uniform, as indicated on the previous post.

Now, comparing snapshots (notice the names of the images! They are not sorted in time):

• "0s.png" - At time = 0s, the "p_rgh" field is defined as being all 0. That's 0 Pascal, relative to a reference pressure value (can be 1 atm or 10 atm, probably won't matter much).
• "0.05s.png" - At time = 0.05s, which is the first snapshot at time > 0s, the pressure has been distributed accordingly to the weights of each fluid. As you can see on the respective image, the water reveals it's own 2846 Pa of pressure! If you calculate how much force that equates to, you'll understand why the air is flowing all over the place!!
• During the time until 1s, it almost looks like there is a massive storm brewing inside the box, because the air is flowing all around, after that instantaneous difference in pressure that the water enforced on the air!
• "1s.png" - At time = 1s, it gives a sense that things are becoming more stable, although if you look at 0.95s (no image provided), there was a backlash of pressure from one side to the other.

So, what about the water? What happens pressure-wise to the water? It's simple, we can switch off the logarithmic scale and change the range to be between 2846 and 2846.77 Pa and these are what you get:

• "0.05s_water.png" - There you can see that the massive change in pressure also affected the water! If you see the time steps over time, you'll see that it also goes all around flowing to where it can.
• "1s_water.png" - As you can see, this one also seems a bit more stable, but there is a major indication that things are not yet stable: the lower part of the water has a pressure lower than the top, which means that the water is still faaaaaaar away from being stationary!

This reminds me of this interesting analysis of whether a glass was in fact half-empty/half-full: http://what-if.xkcd.com/6/

In conclusion:

• The correct way of doing this would be to also initialize the pressure field with the according weight induced pressure levels. For that, you can either use funkySetFields (it's part of swak4Foam) or see the old 1.7.x tutorial "hotRoom": https://github.com/OpenCFD/OpenFOAM-...oom/setHotRoom
• As for the original mesh, it's simple to explain: imagine how the flow is calculated between two parallelepipedic cells in a diagonal direction. The distance between the center of their cells is farthest in one of the directions, either Y or X; while between two cube-shaped cells is uniform on both X-Y. If you take into account these distances and the shapes of the faces that connect the surrounding cells, you'll see that it's very complicated to preserve a uniform flow on a non-uniform mesh!

Best regards,
Bruno

[sharonyue]

Originally Posted by wyldckat

I didn't show any images before because it seemed simple enough. First about the set-up in ParaView:

1. I jumped to time = 1s, set to display the "p_rgh" field and changed the scale to logarithmic.
2. Added the source "Annotate Time".
3. Then went back to 0s.

The mesh is uniform, as indicated on the previous post.

Now, comparing snapshots (notice the names of the images! They are not sorted in time):

• "0s.png" - At time = 0s, the "p_rgh" field is defined as being all 0. That's 0 Pascal, relative to a reference pressure value (can be 1 atm or 10 atm, probably won't matter much).
• "0.05s.png" - At time = 0.05s, which is the first snapshot at time > 0s, the pressure has been distributed accordingly to the weights of each fluid. As you can see on the respective image, the water reveals it's own 2846 Pa of pressure! If you calculate how much force that equates to, you'll understand why the air is flowing all over the place!!
• During the time until 1s, it almost looks like there is a massive storm brewing inside the box, because the air is flowing all around, after that instantaneous difference in pressure that the water enforced on the air!
• "1s.png" - At time = 1s, it gives a sense that things are becoming more stable, although if you look at 0.95s (no image provided), there was a backlash of pressure from one side to the other.

So, what about the water? What happens pressure-wise to the water? It's simple, we can switch off the logarithmic scale and change the range to be between 2846 and 2846.77 Pa and these are what you get:

• "0.05s_water.png" - There you can see that the massive change in pressure also affected the water! If you see the time steps over time, you'll see that it also goes all around flowing to where it can.
• "1s_water.png" - As you can see, this one also seems a bit more stable, but there is a major indication that things are not yet stable: the lower part of the water has a pressure lower than the top, which means that the water is still faaaaaaar away from being stationary!

This reminds me of this interesting analysis of whether a glass was in fact half-empty/half-full: http://what-if.xkcd.com/6/

In conclusion:

• The correct way of doing this would be to also initialize the pressure field with the according weight induced pressure levels. For that, you can either use funkySetFields (it's part of swak4Foam) or see the old 1.7.x tutorial "hotRoom": https://github.com/OpenCFD/OpenFOAM-...oom/setHotRoom
• As for the original mesh, it's simple to explain: imagine how the flow is calculated between two parallelepipedic cells in a diagonal direction. The distance between the center of their cells is farthest in one of the directions, either Y or X; while between two cube-shaped cells is uniform on both X-Y. If you take into account these distances and the shapes of the faces that connect the surrounding cells, you'll see that it's very complicated to preserve a uniform flow on a non-uniform mesh!

Best regards,
Bruno

http://what-if.xkcd.com/ this is funny!
This is a huge information for me. Iam a beginner.HOO.But its veru useful. I will check it out later and try some other cases to testify. Thanks very much for you consistant assistance Bruno.now it seems more clear.

[Islem]

Originally Posted by wyldckat

I didn't show any images before because it seemed simple enough. First about the set-up in ParaView:

1. I jumped to time = 1s, set to display the "p_rgh" field and changed the scale to logarithmic.
2. Added the source "Annotate Time".
3. Then went back to 0s.

The mesh is uniform, as indicated on the previous post.

Now, comparing snapshots (notice the names of the images! They are not sorted in time):

• "0s.png" - At time = 0s, the "p_rgh" field is defined as being all 0. That's 0 Pascal, relative to a reference pressure value (can be 1 atm or 10 atm, probably won't matter much).
• "0.05s.png" - At time = 0.05s, which is the first snapshot at time > 0s, the pressure has been distributed accordingly to the weights of each fluid. As you can see on the respective image, the water reveals it's own 2846 Pa of pressure! If you calculate how much force that equates to, you'll understand why the air is flowing all over the place!!
• During the time until 1s, it almost looks like there is a massive storm brewing inside the box, because the air is flowing all around, after that instantaneous difference in pressure that the water enforced on the air!
• "1s.png" - At time = 1s, it gives a sense that things are becoming more stable, although if you look at 0.95s (no image provided), there was a backlash of pressure from one side to the other.

So, what about the water? What happens pressure-wise to the water? It's simple, we can switch off the logarithmic scale and change the range to be between 2846 and 2846.77 Pa and these are what you get:

• "0.05s_water.png" - There you can see that the massive change in pressure also affected the water! If you see the time steps over time, you'll see that it also goes all around flowing to where it can.
• "1s_water.png" - As you can see, this one also seems a bit more stable, but there is a major indication that things are not yet stable: the lower part of the water has a pressure lower than the top, which means that the water is still faaaaaaar away from being stationary!

This reminds me of this interesting analysis of whether a glass was in fact half-empty/half-full: http://what-if.xkcd.com/6/

In conclusion:

• The correct way of doing this would be to also initialize the pressure field with the according weight induced pressure levels. For that, you can either use funkySetFields (it's part of swak4Foam) or see the old 1.7.x tutorial "hotRoom": https://github.com/OpenCFD/OpenFOAM-...oom/setHotRoom
• As for the original mesh, it's simple to explain: imagine how the flow is calculated between two parallelepipedic cells in a diagonal direction. The distance between the center of their cells is farthest in one of the directions, either Y or X; while between two cube-shaped cells is uniform on both X-Y. If you take into account these distances and the shapes of the faces that connect the surrounding cells, you'll see that it's very complicated to preserve a uniform flow on a non-uniform mesh!

Best regards,
Bruno

Hi Bruno,
Thx for the explanation !!

As for the original mesh, it's simple to explain: imagine how the flow is calculated between two parallelepipedic cells in a diagonal direction. The distance between the center of their cells is farthest in one of the directions, either Y or X; while between two cube-shaped cells is uniform on both X-Y. If you take into account these distances and the shapes of the faces that connect the surrounding cells, you'll see that it's very complicated to preserve a uniform flow on a non-uniform mesh!

Would you please explain further ??

I am currently modeling a dam Break case, I used same settings as the damBreak tutorial, when the mesh is coarse the simulation works fine whether turbulence is included or not, but when I refine the mesh to satisfy the y+ condition imposed by the turbulence model, the simulation crash due to spurious current i.e velocity go crazy thus deltaT decreases. The smallest element I am using is 3e-04 m. If I try to run the problem as a laminar case using the same mesh, the simulation doesn't crash but It takes a long time.

I will have to refine the mesh further, beacuse I will run KW sst model which requires y+=1 near the wall to solve the boundary layer thus a finer mesh that the one required by k-epsilon, The first cell height should 9.6e-06m near the wall which will lead to more spurious current as the latter increases when the mesh decreases.

I would say that my mesh (that I used to run k-epsilon model leading the simulation to crash) is structured mesh except that I have sudden change in the mesh size in some zones of the computational domain and some non-orthogonal faces in some area, I just wanted to reduce the number of cells to gain in computation time but as I said it is causing problem when turulence modelling is included.

Any advice in how the mesh should be in relation to spurious current and turbulence modelling ??

I appreciate you help in advance
Regards,
islem