CFD Online Logo CFD Online URL
Home > Forums > OpenFOAM

interFoam behavior due to gh*grad(rho)

Register Blogs Members List Search Today's Posts Mark Forums Read

LinkBack Thread Tools Display Modes
Old   May 7, 2012, 16:09
Default interFoam behavior due to gh*grad(rho)
Jon Elvar Wallevik
Join Date: Nov 2010
Location: Reykjavik, ICELAND
Posts: 57
Rep Power: 8
JonW is on a distinguished road
Dear foamers
Today I did something interesting with OF21x, and I think you should know about it (at least you who are using interFoam a lot).

I took the original damBreak case and slided the solution area downward into negative y-direction (basically adding -4 in blockMeshDict in the y direction). I also changed setFieldDict so the case is physically the same as the original one.
Both cases are in damBreakTest.gz (tar xzf damBreakTest.gz)

Note that the density for phase 1 is extremely high in both cases, but similar is obtained with normal density values (but the difference is less clear then). I am often using high density liquids thus this is relevant for me.

The point is that there is a difference between the two cases, and I belevie it is due to the gh*grad(rho) term (remember the "-gh*grad(rho)" term in the governing equation). For the original case, then gh<0 at the interface, while for the new case then gh>0. Now remember that the coordinate system is the same (i.e. y - axis points in the same direction for both the original and the new case). This means that for the original case the "-gh*grad(rho)" points in the same direction as "grad(rho)", meaning downwards. However, for the new case, "-gh*grad(rho)" points in opposite direction (i.e. upward), and thus the difference between the two cases. I think that the reason that the liquid (alpha1) is not going "up" for the new case, is other terms like the grad(eta) and surface tension (and perhaps other effects) are forcing it down.

Strictly speaking this is not a code error (in my opinion), it is just how the gh*grad(rho) behaves, and you (interFoam user) should be aware of this. The point is, make sure that the origin of the coordinate system is at the lowest point in your system (at least this is what I do).

Hope this is of help
If you find other reason for the above difference, and if I am wrong in my conclusions, please post
Attached Images
File Type: jpg damBreak_orginal.jpg (22.0 KB, 29 views)
File Type: jpg damBreak_yNegCoord.jpg (22.6 KB, 29 views)
Attached Files
File Type: gz damBreakTest.gz (3.3 KB, 0 views)
JonW is offline   Reply With Quote

Old   May 8, 2012, 03:01
Senior Member
Join Date: Sep 2009
Location: Delft
Posts: 790
Rep Power: 13
Bernhard is on a distinguished road
In this bug-report, Henry Weller explains this issue:
Bernhard is offline   Reply With Quote

Old   May 8, 2012, 07:56
Jon Elvar Wallevik
Join Date: Nov 2010
Location: Reykjavik, ICELAND
Posts: 57
Rep Power: 8
JonW is on a distinguished road
Thanks for the info Bernhard,
appreciate this
JonW is offline   Reply With Quote


gh grad(rho) interfoam

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On

Similar Threads
Thread Thread Starter Forum Replies Last Post
InterFoam stops after deltaT goes to 1e14 francesco_b OpenFOAM Running, Solving & CFD 8 July 31, 2013 02:29
Segmentation fault in interFoam run through openMPI voingiappone OpenFOAM 16 November 2, 2011 07:49
Slow interFoam compared with other CFD tools? Ralph M OpenFOAM Programming & Development 1 November 17, 2010 07:46
Temporal discretisation in interFoam sebonator OpenFOAM 2 August 21, 2009 07:39
Open Channel Flow using InterFoam type solver sxhdhi OpenFOAM Running, Solving & CFD 3 May 5, 2009 21:58

All times are GMT -4. The time now is 17:09.