[farazarbabi]

Hi guys,

I am trying to follow the following paper and model a simple single bubble rising in a tank filled with water:

Hysing et al., "Quantitative benchmark computations of two-dimensional bubble dynamics", International Journal for Numerical Methods in Fluids, 2009.

The problem is that, I am not getting the same results as reported in this paper (I have modeled other test cases in other papers, but got the same problem). I attached my results for test case 2, and considered the parameters shown in the table below (nu for water and air were set to 0.01 and 0.1, respectively), but my bubble looks to move through a more viscous medium!
Does anybody have any idea where I might have made a mistake? I checked everything, and everything looks to be correct. Has anybody faced the same problem?

Thank you.

[Mojtaba.a]

Dear Faraz,

I have validated these results before,
You have got to be more specific about your setup to be able to know where the problem is.

[farazarbabi]

Hi Mojtaba and thank you for your response,

These are the parameters that I used:

zeroGradient pressure B.C. for for the walls. slip B.C. for the left and right walls, no-slip for the lower and upper walls.
g= -9.8, nu (water)= 0.01, nu (air)= 0.1, rho (w) = 1000, rho (air)= 1.0, and sigma= 1.96,.
Meshing= 160X320. No conversion of the units.

vertices
(
(0 0 0)
(1 0 0)
(1 2 0)
(0 2 0)
(0 0 0.01)
(1 0 0.01)
(1 2 0.01)
(0 2 0.01)
);
===============
I.C.: cylinderToCell

p1 (0.5 0.5 0);
p2 (0.5 0.5 0.01);
radius 0.25;

================

I also added pRefCell and pRefValue= 0 to fvSolutions.

Please let me know if you need any more details,
Thank you for your help,
Faraz

[Mojtaba.a]

How you set your initial condition for alpha?

[farazarbabi]

In setFields:

defaultFieldValues
(
volScalarFieldValue alpha.water 1
);

regions
(
cylinderToCell
{

p1 (0.5 0.5 0);
p2 (0.5 0.5 0.01);
radius 0.25;

fieldValues
(
volScalarFieldValue alpha.water 0
);

}

and in alpha.water.org zeroGradient is set for all boundaries.

[farazarbabi]

Correction:
g=-0.98, as stated in the mentioned paper.

Originally Posted by farazarbabi

Hi Mojtaba and thank you for your response,

These are the parameters that I used:

zeroGradient pressure B.C. for for the walls. slip B.C. for the left and right walls, no-slip for the lower and upper walls.
g= -9.8, nu (water)= 0.01, nu (air)= 0.1, rho (w) = 1000, rho (air)= 1.0, and sigma= 1.96,.
Meshing= 160X320. No conversion of the units.

vertices
(
(0 0 0)
(1 0 0)
(1 2 0)
(0 2 0)
(0 0 0.01)
(1 0 0.01)
(1 2 0.01)
(0 2 0.01)
);
===============
I.C.: cylinderToCell

p1 (0.5 0.5 0);
p2 (0.5 0.5 0.01);
radius 0.25;

================

I also added pRefCell and pRefValue= 0 to fvSolutions.

Please let me know if you need any more details,
Thank you for your help,
Faraz

[Mojtaba.a]

OK,

I have attached the case I had used for validation. Just run Allrun script and you will be fine.

It works on OF 2.3.

Hope it helps,
Good luck.

[farazarbabi]

Thank you so much Mojtaba, it helped so much.
I realized that I had set the top-wall pressure B.C. to zeroGradient, which should be fixedValue.
Can you please explain why we must use fixedValue instead of zeroGradient? I thought the appropriate B.C. for walls is zeroGradient, and we have a wall at top, don't we?

Thank you again!

[Mojtaba.a]

Originally Posted by farazarbabi

Thank you so much Mojtaba, it helped so much.
I realized that I had set the top-wall pressure B.C. to zeroGradient, which should be fixedValue.
Can you please explain why we must use fixedValue instead of zeroGradient? I thought the appropriate B.C. for walls is zeroGradient, and we have a wall at top, don't we?

Thank you again!

Well I have set outlet boundary as patch since it is not a wall. Check boundary file.
As I far as I remember that wasn't set to wall in the paper.

Best.

[farazarbabi]

I just noticed that writeInterval is a main reason for contradiction between our results. Its value has a huge effect on the solution. using deltaT=1e-04, and writeInterval=0.1 gives me wrong results, while writeInterval=0.01 gives me (more) correct results!
I used to think the writeInterval sets the steps that we want our results to be recorded, and thus it does not have any effect on the solution, can you please correct me?
Here are my results at t=2.2 sec, for writeIntervals equal to 0.1 and 0.01 in comparison with the reported result by Hysing et al.

[Mojtaba.a]

Originally Posted by farazarbabi

I just noticed that writeInterval is a main reason for contradiction between our results. Its value has a huge effect on the solution. using deltaT=1e-04, and writeInterval=0.1 gives me wrong results, while writeInterval=0.01 gives me (more) correct results!
I used to think the writeInterval sets the steps that we want our results to be recorded, and thus it does not have any effect on the solution, can you please correct me?
Here are my results at t=2.2 sec, for writeIntervals equal to 0.1 and 0.01 in comparison with the reported result by Hysing et al.

Well actually your sentence regarding "writeInterval sets the steps that we want our results to be recorded" is absolutely true. But there is one misunderstanding though.
I just checked OpenFOAM Time and data input/output control and got this:

- adjustableRunTime
Writes data every writeInterval seconds of simulated time, adjusting the time steps to coincide with the writeInterval if necessary — used in cases with automatic time step adjustment

It says that it changes timeStep to coincide with the writeInterval. Here choosing adjustableRunTime has forced the solver to change deltaT. Therefore in fact, it is deltaT which has effects on the solution.

[farazarbabi]

I see your point, but I think (according to OpenFOAM) as long as the Courant number is below 1, the solution should be correct. Neither writeInterval equal to 0.1 nor 0.01 causes the Courant number reach even close to 1.
This is important for me since I want to run more complex simulations, so I must use adjustableRunTime, and if Co < 1 constraint does not work properly, I need to set the maximum Co to a more reliable number.

[Mojtaba.a]

Originally Posted by farazarbabi

I see your point, but I think (according to OpenFOAM) as long as the Courant number is below 1, the solution should be correct. Neither writeInterval equal to 0.1 nor 0.01 causes the Courant number reach even close to 1.
This is important for me since I want to run more complex simulations, so I must use adjustableRunTime, and if Co < 1 constraint does not work properly, I need to set the maximum Co to a more reliable number.

I see, well how about checking to see what are the differences between timeSteps in the two simulations?

However I just found a link which I think is helpful:

http://www.idurun.com/?p=371

Another thing, maybe you can solve the problem by setting a lower value for maxDeltaT ?!

[farazarbabi]

Hi Mojtaba,

I reran the case for different maxCo (and maxalphaCo) numbers, for writeIntervals equal to 0.1:

Co= 0.5; Execution Time= 106 s
Co= 0.3; Execution Time= 190 s
Co= 0.1; Execution Time= 758 s
Co= 0.05 Execution Time= 1484 s

It is clear from the results that despite what OpenFOAM manual suggests, at least in multiphase modeling, we will not obtain realistic results by using Courant numbers higher than 0.1. Even limiting Courant number to below 0.05, still there is a minor discrepancy between our result and what reported in the literature.
The execution time is too high, but can be moderated by running in parallel.

[mreza_cfd]

Hello!

I did a simple run: 2d bubble rising with solver interFoam.

The problem is that when I run on a finer mesh, the results have more error with comparison to Hysing et al.*

Do you know why?!

You can see the code and results in attachment.


Thanks a lot in advance!

* http://www.karlin.mff.cuni.cz/~hron/...3/1934_ftp.pdf

[zeynab hoseini]

Originally Posted by Mojtaba.a

OK,

I have attached the case I had used for validation. Just run Allrun script and you will be fine.

It works on OF 2.3.

Hope it helps,
Good luck.

Hello Mojtaba
I have validated above paper and now I have some question:
1- In this paper , units have not been mentioned so it means i can choose cm unit ? If i can , which parameter must be changed ? Changing units in blockMesh and setFields are enough or other parameters must be changed according to dimensionless numbers? How can I change them ?
2 – the bubble behavior in both case should be similar or not ? ( it is reasonable that in cm case runtime increases because bouancy force reduces while surface tention and gravity force are constant ).
If It's Possible Please Guide Me .
With Best Regards

[Tobi]

Hi guys,

we will keep the thread in the validation sub-forum because there are some nice results. However, in general the thread is more about solving the problem rather than showing a validation which has good comparison.

Some hints to your cases:

If you lower the Courant number, you will lower the time step and therefore you get more accurate results based on the fact that you are using a 1st order time discretization. Personally I would say, that here you have the problem rather than that it is a problem of FOAM. It's more the numerical aspects which has to be considered. Another example is the laplacian discretization. I think you have a orthogonal case, so you should set also appropriate discretization for that term and not a corrected one

I know that this thread is a bit old but maybe someone will re-check it with more accurate numerical schemes.

Good luck.

[minh khang]

"Another example is the laplacian discretization. I think you have a orthogonal case, so you should set also appropriate discretization for that term and not a corrected one"

I don't understand this.

[Lookid]

Originally Posted by minh khang

"Another example is the laplacian discretization. I think you have a orthogonal case, so you should set also appropriate discretization for that term and not a corrected one"

I don't understand this.

Your input on fvSchemes should depend a lot on your mesh quality. Basically, if you have a perfect mesh, you put very accurate schemes, if you have a bad mesh, you put robust scheme, but less accurate. It's always a compromise between accuracy and stability. To know more about this, please read this : http://www.wolfdynamics.com/wiki/fvm_crash_intro.pdf
It's full of great information, you won't lose your time

For example, for laplacian terms, you'll put orthogonal if you have a high quality hexa-mesh, and as the quality of your mesh goes down, you'll use corrected, limited and finally uncorrected. So try to put "Gauss linear orthogonal;" and see if it helps you

[piu58]

I calculated this example too. It is a good exercise to set all the parameters appropriate to the problem. I used accurate schemes for discretisation. The most important parameter was the maxCo, which influenced the accuracy most. I ended with as low as 0.01, 0.003 was only very slightly better. I measured this against the center of mass y_c after 3 seconds.