[JonW]

Dear Foamers

I have a problem with interFoam (same with interDyMFoam) on a non-orthognal (and skewed) mesh .

The case file is "water_splash.tgz" for the interested. (for the very OpenFOAM newcomers, read the run_readme.txt file about how to run the case)

The mesh is not fancy as shown with "figure1.png"

The case file is typical of what I have to work with, I.e. I have to work with mesh systems where non-orthogonal and orthogonal meshes meets. The case file here is just artificially created, not for any purpose other than to demonstrate the problem with alpha1 and interface compression.

The case consists of water column flowing by the action of gravity, as shown below (time = 0 sec) as shown with "figure1.png"

The problem is shown in "figure2.png" and consist of that a wave (or wiggle) phenomenon occurs in alpha1 where two grid system meets (i.e. the orthogonal and the non-orthogonal).
I have the same problems with other types of non-orthogonal meshes, even where zero skewness is present. (The problem also persists when running interDyMFoam).

I have tried everything (I think ),...
I have changed mesh configuration (making cell size in the two mesh system similar in size).
I have reduced time step (very much), reduced Courant numbers (also for alpha1)
put momentumPredictor to yes,
changed nCorrectors, nNonOrthogonalCorrectors, nAlphaCorr, nAlphaSubCycles.

NOTE: The only thing that solves this is if I put cAlpha to zero (“cAlpha 0;”). The result is shown with "figure3.png"

The solution putting cAlpha to zero, might suggest that the problem lies in the interface compression! ?? . But, as far as I can see, everything is correct for the compression in “alphaEqn.H”, so I don't understand this.

The problem of using cAlpha 0, is that the alpha1 get “diffused” throughout the system, and a clear boundary get "dissolved". Thus using cAlpha 0, is not a solution!


So any ideas?

[Andrea_85]

Hi Jon,
i do not know exactly if this is what you are looking for but....
i have worked a bit with interFoam and non orthogonal mesh, basically i have been able to find acceptable results by changing the fvSchemes to take into account bad mesh. I found good results using the pointLinear schemes instead of linear schemes for gradient and interpolation. Also leastSquares works fine for my simulation.
Hope this can help you

andrea

[JonW]

Hi Andrea and thanks for the reply

Unfortunately, neither

interpolationSchemes
{
default pointLinear;
}

...or...

gradSchemes
{
default leastSquares;
}

...solved the problem

[JonW]

Dear foamers, I know this post is old, but I think this is important, so here we go (part solution):

I was working on a project last week with interFoam. The system were such that the alpha wave problem should not occur (at least not in my mind), but there it was. In my problem, the aspect ratio of the mesh was greater than 1 (about 3) to save cpu time [aspect ratio = length of cell/width of cell, etc.]. Increasing the mesh resolution (and thus gaining aspect ratio of 1) made the alpha problem to go away.

I tried the same thing with the setup descriped in the beginning of this post, and the wave problem dissapered.

So here you have it,... one way in avoiding the problem, keep your aspect ratio close to 1 in your mesh system (if there is a wave problem).

cheers
JonW

[JonW]

Dear foamers

I converted the above wiggle wave experiment from OpenFOAM 2.2.1 over to OF-9 (this should work for OF-10 as well, but I haven't tested it on 10). See the download wigglesOpenFOAM9.zip

The two cases within this tarball, namely "a_withWiggles" and "b_withoutWiggles" are identical, except for the slight difference in the blockMeshDict. As you can see the wiggle wave problem is still present in OF-9 version of interFoam. See also the attached figures.

The good thing about the two above test cases is that they run quickly, several minutes, so if you want to test different setups in your fvSchemes file, then these cases are OK for that.

I have been wondering if the wiggle-wave problem in interFoam is actually a ParaView problem,... more specifically problem with the VTK engine that ParaView is using???
I have tested other visual programs with the same result, but I suspect that these are using the same VTK engine as ParaView(???).
I know very little about the core in ParaVies, so maybe others can put light on this?

cheers
Jon

[alexj]

Dear Jon,

thanks for that testcase and the follow up on this issue. I face the same problem in granular rheology flows so I got interested in your test case.

As of OpenFOAM-v9 there are new interface capturing techniques available:
http://https://cfd.direct/openfoam/f...ace-capturing/

I changed your testcase a_withWiggles slightly, based on the current setup in the OpenFOAM-10 tutorial case "damBreakWithObstacle" which uses the MPLIC scheme and called it c_withoutWiggles (case file attached). I kept your grid configuration from a_withWiggles

Some screenshots are attached.

It looks like the MPLIC interface capturing scheme improves things significantly. Have a look at my config and let me know what you think.

Cheers,
Alex

[alexj]

Originally Posted by JonW

I have been wondering if the wiggle-wave problem in interFoam is actually a ParaView problem,... more specifically problem with the VTK engine that ParaView is using???
I have tested other visual programs with the same result, but I suspect that these are using the same VTK engine as ParaView(???).
I know very little about the core in ParaVies, so maybe others can put light on this?

Me again. I have been wondering the same thing. However if one uses a threshold filter instead of a contour filter in paraview and visualizes cell values instead of point values, then one can see the pure cell values visualized. (see screenshots of the same time steps as in the last post)

Unfortunately the instabilities exist as well on the cell data level. This gives me confidence that the instabilities are actually in the numerical solutions and not in the paraview visualization. But I am no expert in VTK and how paraview handles the visualizations internally.

Cheers,
Alex

[JonW]

OK, great to know, thanks for the info

[JonW]

Hi again Alex

I noticed that you were using...
div(rhoPhi,U) Gauss upwind;
...which is 1st order accurate and will add an extra diffusive component to the simulation.

Maybe rather use...
div(rhoPhi,U) Gauss limitedLinearV 1;
which is second order and bounded.

cheers
Jon

[alexj]

Hi again Jon,

sharp observation, you are right. I have re-run the test case with your suggested scheme, here are the comparison frames.

Thanks for checking my config.

Cheers,
Alex

[JonW]

For those of you who are new to the Volume of Fluid (VOF) and the interFoam solver, then be aware that the theory VOF can be divided between two families. The text below is from the following paper: "Analysis of shear rate inside a concrete truck mixer, Cement and Concrete Research, Volume 95, May 2017, Pages 9-17", see also https://www.sciencedirect.com/scienc...08884616310961

"In each and every computational cell, the following is always valid α1 + α2 = 1, meaning if the quantity of phase 1 is known by α1, then so is the quantity of phase 2 by α2 = 1 − α1. This means it is sufficient to calculate only the interface advection for α1. This interface is moved through a fixed mesh and is captured by a phase transport equation. Relative to this specific equation, the VOF can be divided between two families, namely the direct methods and the reconstruction methods [24]. For the latter approach, the phase transport equation is approximated typically in two steps, first by a geometric interface reconstruction step and thereafter by an interface propagation step [24]. Examples of such approaches are the PLIC [26] and SLIC [27].

Unlike geometric interface reconstruction methods, the direct methods do not introduce geometrical representation of the interface, but rather try to maintain sharply defined interface by properly chosen discretization scheme, commonly known as compressive differencing scheme [28]. Example of such are the CICSAM [29], [30] and HRIC [31]. Another method, which could be considered to belong to the direct methods is the so-called Weller-scheme [32], [33]. However, instead of using compressive differencing scheme like done in CICSAM, the compression of the interface is achieved by applying an extra compression term directly into the phase transport equation [23], [33]. This approach is used here and thus better explained below..."

Apparently, with the new MPLIC like Alex talked about previously above, the interFoam solver can now do both families. There is also another solver, named interIsoFoam, which I think belongs to the "reconstruction-family" (i.e. some kind of geometric interface reconstruction step). But it is only available in the ESI version of OpenFOAM (openfoam.com).

Hope this is of help
cheers
Jon