View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0002470OpenFOAMBugpublic2017-02-21 12:012017-09-11 16:29
ReporterBenSloof Assigned Tohenry  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
PlatformGNU/LinuxOSUbuntuOS Version14.04
Fixed in Versiondev 
Summary0002470: MULES prevents settling in lower cells.
DescriptionWhen I test the settling of driftFluxFoam in a case where U=0 in the whole field and the initial concentration is 0.25. I see that the settling at the first time-steps goes wrong. This happens also in other cases(also in the Dahl tutorial).

At the bottom of the mesh MULES causes problems. Therefore at the bottom the particles are spread over the bottom cells, which should not be done.
Steps To Reproduce
1. Copy the Dahl tutorial case

2. In 0/U make the velocity at the inlet 0 and in 0/k make the initial condition 0.

3. Adjust in the controlDict the following:
endTime 0.001;
deltaT 0.0001;
writeControl adjustableRunTime;
writeInterval 0.0001;


4. Run with driftFluxFoam and open paraFoam. You will see that at the first time-step in the third- and fourth-lowest cells the concentration is higher than the concentration in the lowest and second-lowest cell.
Additional InformationThe problem is that MULES changes alphaPhi at the bottom to zero. This makes sure no paricles can go into the bottom cells.

When in fvSolutions I change 'MULESCorr' to 'no' and when lines 96 to 103 in alphaEqn.H are removed(or made comment), the problem is solved. But of course I want to use MULES.

I think MULES has problems with the boundary condition at the bottom. When I create a bed with setFields and then run the case it doesn't have this problem. Then the settling looks normal.
TagsMULES

Relationships

related to 0002697 closedhenry Phase fraction close to the wall presents an almost constant value along several cells for different mesh refinements. 

Activities

henry

2017-02-21 13:01

manager   ~0007784

Try with OpenFOAM-dev.

> The problem is that MULES changes alphaPhi at the bottom to zero.

What do you think alphaPhi should be set to at the bottom?

BenSloof

2017-02-21 16:03

reporter   ~0007789

I tried it with OpenFOAM-dev, but I still see the same problem.

I now see that making lines 96 to 103 in alphaEqn.H comment, doesn't solve the problem.


>> The problem is that MULES changes alphaPhi at the bottom to zero.
>
>What do you think alphaPhi should be set to at the bottom?

In the beginning of the simulation the concentration is everywhere the same. This means the settling velocity should be the same everywhere. So alphaPhi(in vertical direction) should also be the same everywhere. But at this moment MULES makes it zero at the bed. That is wrong.

When you copy Info << "alphaPhi: " << alphaPhi[1] << endl; before and after MULES(in line 96. You see MULES makes it zero.

I also made an IOobject of alphaPhi. There you see the same. At the faces near the bed alphaPhi becomes zero. If you place alphaPhi.write() before MULES you see it has the value it should have. The faces near the bed have the same alphaPhi as in the rest of the domain.

Later in the simulation when the concentration reaches at the bottom reaches alphaMax, then of course alphaPhi has to become zero. But at the beginning this shouldn't happen.

I btw also attached the dahl case I runned to test this.
dahl.zip (4,251,573 bytes)

henry

2017-02-21 16:42

manager   ~0007790

> But at this moment MULES makes it zero at the bed. That is wrong.

Are you saying alphaPhi should be non-zero on the bottom wall?

Is the bottom actually a wall in your case or is it open or some kind of filter allowing either or both phases to pass through it?

The last time I ran the dahl case the results were fine and as I would expect. I will run it again and check nothing has changed.

henry

2017-02-21 16:50

manager   ~0007791

I am running the dahl case and the results look fine, the bed settles as expected. If alphaPhi were zero no settling would occur but it clearly does.

BenSloof

2017-02-22 08:29

reporter   ~0007795

Thank you for your quick replies!

I attached a picture. If you follow the 'steps to reproduce' you will get the same.

> Are you saying alphaPhi should be non-zero on the bottom wall?

No at the bottom wall it should be zero. But in the faces above the bottom wall it should not be zero. When you copy Info << "alphaPhi: " << alphaPhi[1] << endl; before and after MULES(in line 96). You see MULES makes it zero.
Face 1 is a horizontal face directly above the bottom wall(not the bottom wall it self)

> Is the bottom actually a wall in your case or is it open or some kind of filter allowing either or both phases to pass through it?

No it is a wall. Right now I'm used the dahl case(in the picture). There it is a wall at the bottom. In the case where I discovered this problem. I also had a wall at the bottom.

I'm going to make a case where you see this effect more clearly than in the Dahl case. I will post it within an hour.
Selection_077.png (308,124 bytes)

henry

2017-02-22 08:37

manager   ~0007796

I ran the dahl in OpenFOAM-dev and I get settling in to the bottom row of cells indicating that alphaPhi in non-zero into those cells. The case converges and the solution looks correct.

BenSloof

2017-02-22 09:37

reporter   ~0007798

> I ran the dahl in OpenFOAM-dev and I get settling in to the bottom row of cells indicating that alphaPhi in non-zero into those cells. The case converges and the solution looks correct.

Yes after a while alpaPhi becomes non-zero, but totally at the beginning(for example in the photo: t=0.00012) alphaPhi is zero.

I attached another case. I think I already should have done that at the beginning. Sorry for that. In this case the effect is a lot more clear. In this case I try to replicate the experiments of Runge(1999). It is a big column in which settling occurs.

What I see in my simulation in this:
1. At first MULES partially limits the material going into the lowest cell. Therefore the concentration in the four lowest cells is constant. You can see this in the first picture. In reality this does not occur. In reality settling starts to occur from the beginning. So in OpenFoam this means that the concentration in the lowest cell should be higher than in the second-, third- and fourth-lowest cell.
2. At t=75 the concentration in the four cells at the bottom reaches alphaMax. After this the settling starts to work as it should be. The settling occurs cell by cell. When one cell is 'full' the cell above that one is filled.
I also attached a picture at t=100

I tried to make the mesh finer and use a smaller dT, but that doesn't help.

The same effect you can see in the Dahl tutorial when you make U at the inlet 0. You see that at t=0.0012s MULES totally limits the material going into the lowest cell. Later on, MULES partially limits the material going into the lowest cell.
t=28.png (290,652 bytes)

BenSloof

2017-02-22 09:37

reporter  

t=100.png (294,603 bytes)

BenSloof

2017-02-22 09:40

reporter  

runge.zip (21,971 bytes)

BenSloof

2017-02-22 09:41

reporter   ~0007799

With 'You can see this in the first picture.' I mean the picture with the name t=28

henry

2017-02-22 10:07

manager   ~0007800

The case you send does not run:

--> FOAM FATAL ERROR:
Unknown time scale model type richardson, constructor not in hash table

    Valid time scale model types are:

2
(
general
simple
)

BenSloof

2017-02-22 10:49

reporter   ~0007801

Sorry. It should work now. I uploaded the same case but then with the 'simple' settling model
runge2.zip (21,498 bytes)

henry

2017-02-22 13:45

manager   ~0007802

The issue is that MULES guarantees both local and global boundedness and with the bottom BC for alpha set to zeroGradient MULES sets the limiter such that the neighbouring cell values are no larger than the boundary value which is set to the cell value. The only reason the value changes at all is that the number of iterations of the limiter is limited, in your case set to 3 which means that the lower 4 layers of cells increase in value uniformly. To test this try

    bottomWall
    {
        type fixedValue;
        value 0.6;
    }

and you will see that the lower cells increase in value as you would expect.

henry

2017-02-22 15:44

manager   ~0007804

I have changed the boundary handling of the MULES limiter:

commit 4a22ab94b5b4d9619954426ce7c446f955091e18
Author: Henry Weller <http://cfd.direct>
Date: Wed Feb 22 15:34:13 2017 +0000

    MULES: Adjust limiter only at boundaries for which the field value is fixed
    
    Resolves bug-report https://bugs.openfoam.org/view.php?id=2470

which allows your case to run correctly even with zeroGradient lower BC. However, it does cause the dahl to behave quite differently because the surface layer becomes more concentrated which increases the viscosity significantly and the inlet from to separate from it causing a lot flow disturbance.

BenSloof

2017-02-23 10:33

reporter   ~0007809

Thank you very much! The simulation with the Column(runge) works well when I use fixedValue 0.6 at the bottom and fixedValue 0 at the top. Also some other cases show better results right now!

> which allows your case to run correctly even with zeroGradient lower BC. However, it does cause the dahl to behave quite differently because the surface layer becomes more concentrated which increases the viscosity significantly and the inlet from to separate from it causing a lot flow disturbance.

I ran the dahl case with OpenFOAM-dev. I see this(3iterations.png). Do you see the same? It is interesting to see that the 4 layers of cells at the bottom have a higher concentration.

When I do the same case, but then change 'nLimiterIter' to 1, I see the following(1iteration.png'). Clearly the number of iterations has influence. Apperently the combination of zeroGradient and MULES still doesn't work properly.

BenSloof

2017-02-23 10:33

reporter  

3iterations.png (300,540 bytes)

BenSloof

2017-02-23 10:34

reporter  

1iteration.png (337,217 bytes)

henry

2017-02-23 10:47

manager   ~0007810

> I ran the dahl case with OpenFOAM-dev. I see this(3iterations.png). Do you see the same?

No. Are you running OpenFOAM-dev with including commit 4a22ab94b5b4d9619954426ce7c446f955091e18

> Clearly the number of iterations has influence.
> Apperently the combination of zeroGradient and MULES still doesn't work properly.

Yes it does now, I fixed this yesturday in commit 4a22ab94b5b4d9619954426ce7c446f955091e18

tniemi

2017-02-23 10:57

reporter   ~0007811

Hi

I also tried to run the test case, but I could only get it working as intended by giving a positive extremaCoeff. Without it the case worked similarly as before the commit.

tniemi

2017-02-23 11:26

reporter   ~0007812

Actually now that I looked at the MULES code, I can't quite figure out how it is supposed to work in cases where there is eg. packing. It would seem that MULES enforces the volume fraction to stay within the neighboring values (if extremaCoeff=0), but this is problematic if in reality there should be packing and the local volume fraction should increase. Is there something I'm missing?

henry

2017-02-23 11:36

manager   ~0007813

MULES is applied to the bounded advection operator, the dilatation part is handled as a source.

henry

2017-02-23 11:40

manager   ~0007814

I have found the problem, I didn't include in the commit the final part of the changes I made, I am double-checking now and will commit shortly.

BenSloof

2017-02-23 11:44

reporter   ~0007815

> No. Are you running OpenFOAM-dev with including commit 4a22ab94b5b4d9619954426ce7c446f955091e18

You are right. I did not yet have OpenFOAM-dev including the commit

henry

2017-02-23 11:49

manager   ~0007816

Wait a few minutes and I will commit the other change you need.

henry

2017-02-23 12:10

manager   ~0007817

Try with commit cb2bc60fa557943bb5657d46b5f69538101f9e97

henry

2017-03-05 12:34

manager   ~0007855

I believe this is now resolved, please reopen if this is not the case.

Issue History

Date Modified Username Field Change
2017-02-21 12:01 BenSloof New Issue
2017-02-21 12:01 BenSloof Tag Attached: MULES
2017-02-21 13:01 henry Note Added: 0007784
2017-02-21 16:03 BenSloof File Added: dahl.zip
2017-02-21 16:03 BenSloof Note Added: 0007789
2017-02-21 16:42 henry Note Added: 0007790
2017-02-21 16:50 henry Note Added: 0007791
2017-02-22 08:29 BenSloof File Added: Selection_077.png
2017-02-22 08:29 BenSloof Note Added: 0007795
2017-02-22 08:37 henry Note Added: 0007796
2017-02-22 09:37 BenSloof File Added: t=28.png
2017-02-22 09:37 BenSloof Note Added: 0007798
2017-02-22 09:37 BenSloof File Added: t=100.png
2017-02-22 09:40 BenSloof File Added: runge.zip
2017-02-22 09:41 BenSloof Note Added: 0007799
2017-02-22 10:07 henry Note Added: 0007800
2017-02-22 10:49 BenSloof File Added: runge2.zip
2017-02-22 10:49 BenSloof Note Added: 0007801
2017-02-22 13:45 henry Note Added: 0007802
2017-02-22 15:44 henry Note Added: 0007804
2017-02-23 10:33 BenSloof Note Added: 0007809
2017-02-23 10:33 BenSloof File Added: 3iterations.png
2017-02-23 10:34 BenSloof File Added: 1iteration.png
2017-02-23 10:47 henry Note Added: 0007810
2017-02-23 10:57 tniemi Note Added: 0007811
2017-02-23 11:26 tniemi Note Added: 0007812
2017-02-23 11:36 henry Note Added: 0007813
2017-02-23 11:40 henry Note Added: 0007814
2017-02-23 11:44 BenSloof Note Added: 0007815
2017-02-23 11:49 henry Note Added: 0007816
2017-02-23 12:10 henry Note Added: 0007817
2017-03-05 12:34 henry Assigned To => henry
2017-03-05 12:34 henry Status new => resolved
2017-03-05 12:34 henry Resolution open => fixed
2017-03-05 12:34 henry Fixed in Version => dev
2017-03-05 12:34 henry Note Added: 0007855
2017-09-11 16:29 henry Relationship added related to 0002697