View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001403||OpenFOAM||Bug||public||2014-09-25 02:55||2018-07-10 11:17|
|Priority||immediate||Severity||major||Reproducibility||have not tried|
|Status||resolved||Resolution||no change required|
|Platform||Unix||OS||Other||OS Version||(please specify)|
|Summary||0001403: Problem with gravity|
|Description||I ran the same case file in previous versions of OF which gave me good results but in OF 2.3.0, though I use the gravity in -Y axis, it acts in +Y axis. I am using compressibleMultiphaseInterFoam. I tried to correct it by using gravity in +Y axis and now the gravity acts in +Y axis only.|
I am attaching the case file and also the video made from that simulation. Please do verify and help me to solve this issue.
|Tags||compressibleMultiphaseInterFoam, gravity, multiphase|
earth3b_of.7z (1,157,015 bytes)
I tested the provided case with two meshes:
- original: (240 80 240) simpleGrading (1 20 1)
- 1st test: (120 40 120) simpleGrading (1 20 1)
- 2nd test: (50 25 50) simpleGrading (1 1 1)
The 1st test I did gave me the same effect of gravity working as if it was over +Y.
The 2nd test worked just fine with and gravity worked as intended.
I did not run the 2nd test with a higher resolution mesh, because it would take some considerable long time to run, namely around 3h to run, as did the 1st test, which only got me to 0.00725s of simulation... versus 20 minutes on the 2nd test, which got me to 0.011s.
Anyway, I believe this proves that the actual problem is that the mesh was designed incorrectly and that the cells where the liquid drop was placed in mid air, are too stretched along the Y, which leads to a severe distortion of the fields. In my 1st test, I witnessed the drop expanding over X and Z, as well as gaining upward momentum.
The 2nd test seems to prove that by using a uniform mesh, the fields can more easily transfer data around.
"I ran the same case file in previous versions of OF"
Could you be specific: in which versions of OpenFOAM did the case run as expected?
I've got some more news on this topic:
- Since there was one or two recent issues fixed on a few related solvers, so I took another look into this (recent build 2.3.x-11ddd071091a). I retried a test case with a non-uniform mesh with the following configuration: (50 25 50) simpleGrading (1 20 1)
It's essentially the 2nd test case described in my previous comment, but with different grading over Y. The result was somewhat surprising: the drop fell with gravity without any problems, as it was meant to do, i.e. the opposite of what happens with the original bug report. This was easy to test, since the case had a relatively small cell count.
- So I tested again the "1st test" from my previous comment and I got a weirder effect: the drop did not go up as I had originally witnessed and instead part of the drop separated and floated towards -X (-Y is the correct gravity direction in this case) and another part sort-of kept floating in mid-air. The latest snapshot was at around 0.0167s, which is more than twice the simulation time I reached in the previous "1st test". Although I did continue the simulation in parallel from 0.011s, which could have affected some very little detail.
As for the previous versions stated by krishtej23, my guesses are that:
a) the actual solver that was used in the past might have been "compressibleInterFoam";
b) or another mesh resolution was used;
c) or other settings in "fvSchemes" were used, as an influence from "compressibleInterFoam".
I don't have a machine powerful enough for testing this faster, therefore I'm not able to easily isolate this issue in regards to the actual origin of this problem. It seems to be related to both the non-uniform finer meshes and the settings selected in "fvSchemes", which are leading to these very weird results.
I can provide the base set-up test cases I've used, but it feels that it would only add entropy/confusion to this bug report, since they are only small variations of the original test case.
Nonetheless, one particular detail might come in handy - I used the "simple" decomposition for running in parallel, with these settings:
n ( 2 3 1 );
Potentially this could affect results... although I used this same configuration with the coarser test cases.
||In order to take this further I really need to know from the reporter in which versions of the OpenFOAM the results were good so I can study the changes between that version and the latest.|
Last edited: 2015-03-01 21:34
Hi wyldckat and henry,
Thank you for working on my case.
I ran the same type of simulations with the same type of mesh and had no problems. The drop didn't stretch along Y axis.
The previous versions of OF are: 2.1.0, 2.2.1 and 2.2.2.
||Can you reproduce this behavior on a smaller case? It is very slow testing changes on a case this big.|
It appears that the p-U system is diverging with the setup you have. I have tuned the settings:
and in OpenFOAM-dev the drop falls as expected. I haven't tested OpenFOAM-2.3.x due to the time it takes to run but this solver has not changed substantially between these versions so with the above settings it should also run for you.
||File Added: earth3b_of.7z|
||Tag Attached: multiphase|
||Tag Attached: compressibleMultiphaseInterFoam|
||Tag Attached: error|
||Tag Attached: gravity|
|2015-02-15 22:01||wyldckat||Note Added: 0003791|
|2015-02-15 22:23||henry||Note Added: 0003792|
|2015-03-01 20:53||wyldckat||Note Added: 0003929|
|2015-03-01 20:59||henry||Note Added: 0003930|
||Note Added: 0003934|
||Note Edited: 0003934|
||Note Edited: 0003934|
|2015-03-02 10:15||henry||Note Added: 0003936|
|2015-03-02 15:37||henry||Note Added: 0003943|
|2015-03-02 15:37||henry||Status||new => resolved|
|2015-03-02 15:37||henry||Resolution||open => no change required|
|2015-03-02 15:37||henry||Assigned To||=> henry|
|2018-07-10 11:17||administrator||Tag Detached: error|