|
2014-10-07 15:06
|
|
|
2014-10-09 12:13
|
alphasand_driftFluxFoam_MULESexplicit.png (109,565 bytes) |
|
2014-10-09 12:15
|
alphasand_driftFluxFoam_MULESsemi-implicit.png (109,051 bytes) |
|
2014-10-09 12:19
|
alpha1_settlingFoam-based-solver_noMULES.png (99,044 bytes) |
|
|
I furthermore attached three screenshots of comparable cases. Screenshots: 1st: driftFluxFoam using MULES explicit. 2nd: driftFluxFoam using MULES semi-implicit. 3rd: settlingFoam-based-solver in which no MULES is implemented. From this it turns out that the semi-implicit MULES suffers more from the discontinuity at the bottom and top of pipe, whereas when using the explicit MULES the discontinuity reduces drastically (almost negligible). The third screenshot (a case with slightly different transportProperties --> particle size) shows a fully continuous solution from bottom to top of pipe, in which MULES was not used at all by a settlingFoam-based-solver in OpenFOAM-2.2.x. Concluding, I think that the bug is somewhere in the (semi-implicit) MULES. |
|
|
The issue is not a bug but a consequence of the operator splitting caused by the diffusion operation being separated from advection in order to guarantee boundedness of each. The splitting is different between the explicit and implicit MULES formulations: in the former the diffusion is performed after advection and in the latter combined with the bounded implicit prediction step. If the diffusion operation is performed after advection for both implicit and explicit MULES then the results become almost identical. I will consider the options further to see if the splitting error can be reduced. Also when running the case I improved the schemes, in particular it is a VERY bad idea to limit all gradients: the pressure gradient should NEVER be limited. I suggest gradSchemes { default Gauss linear; grad(U) cellLimited Gauss linear 1; } |
|
|
|
|
|
I have resolved the problem but it was more complicated than expected with an interaction between the CMULES limiter and the advection-diffusion splitting error. In order to handle the phase-fraction extrema generated by the drift-flux I have added an experimental option to allow the phase-fraction to exceed the local bounds but not the global bounds by specifying e.g. extremaCoeff 0.1; which allows the phase-fraction to exceed the local bounds by up to 0.1 of the allowable range. See attached system directory for full case specification. Resolved by commit 365b20becb277b9978b129ae5e628f45e9e66abc |
- Anonymous
