View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002470||OpenFOAM||[All Projects] Bug||public||2017-02-21 12:01||2017-09-11 16:29|
|Fixed in Version||dev|
|Summary||0002470: MULES prevents settling in lower cells.|
|Description||When 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:
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 Information||The 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.
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?
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 << 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)
> 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.
||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.|
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 << 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)
||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.|
> 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)
t=100.png (294,603 bytes)
runge.zip (21,971 bytes)
||With 'You can see this in the first picture.' I mean the picture with the name t=28|
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:
Sorry. It should work now. I uploaded the same case but then with the 'simple' settling model
runge2.zip (21,498 bytes)
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
and you will see that the lower cells increase in value as you would expect.
I have changed the boundary handling of the MULES limiter:
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.
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.
3iterations.png (300,540 bytes)
1iteration.png (337,217 bytes)
> 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
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.
||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?|
||MULES is applied to the bounded advection operator, the dilatation part is handled as a source.|
||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.|
> No. Are you running OpenFOAM-dev with including commit 4a22ab94b5b4d9619954426ce7c446f955091e18
You are right. I did not yet have OpenFOAM-dev including the commit
||Wait a few minutes and I will commit the other change you need.|
||Try with commit cb2bc60fa557943bb5657d46b5f69538101f9e97|
||I believe this is now resolved, please reopen if this is not the case.|
|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|