View Issue Details

IDProjectCategoryView StatusLast Update
0001410OpenFOAMBugpublic2014-10-14 09:19
Reporteruser1007Assigned Tohenry  
PriorityhighSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
PlatformServerOSRed HatOS Version6.3
Summary0001410: Discontinuity in solution at boundary of horizontal pipe flow
DescriptionUsing the recently developed driftFluxFoam in OpenFOAM-2.3.x, a horizontal pipe steady-state flow (mixture: sand+water) has been simulated, see attached zip-file. Some results are dubious; the volume concentration solids "alpha.sand" over height at 8m downstream (8/10 of total length, where flow is assumed to be fully developed) shows a discontinuity close to the wall (also occurs for variables "k","p_rgh","Udm"). One would expect a continuous solution there.

Is there something wrong in the settings of this simulation (see also the log1-file), or is this more fundamental into the solver driftFluxFoam?

Many thanks in advance, Siemen.
TagsNo tags attached.

Activities

user1007

2014-10-07 15:06

 

user1007

2014-10-09 12:13

 

user1007

2014-10-09 12:15

 

user1007

2014-10-09 12:19

 

user1007

2014-10-09 12:24

  ~0003245

Last edited: 2014-10-09 12:26

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.

henry

2014-10-09 14:45

manager   ~0003246

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;
}

henry

2014-10-13 21:23

manager  

system.tgz (1,793 bytes)

henry

2014-10-13 21:23

manager   ~0003247

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

Issue History

Date Modified Username Field Change
2014-10-07 15:06 user1007 New Issue
2014-10-07 15:06 user1007 File Added: hpipe_driftFluxFoam_wallFunctions.zip
2014-10-09 12:13 user1007 File Added: alphasand_driftFluxFoam_MULESexplicit.png
2014-10-09 12:15 user1007 File Added: alphasand_driftFluxFoam_MULESsemi-implicit.png
2014-10-09 12:19 user1007 File Added: alpha1_settlingFoam-based-solver_noMULES.png
2014-10-09 12:24 user1007 Note Added: 0003245
2014-10-09 12:26 user1007 Note Edited: 0003245
2014-10-09 14:45 henry Note Added: 0003246
2014-10-13 21:23 henry File Added: system.tgz
2014-10-13 21:23 henry Note Added: 0003247
2014-10-13 21:23 henry Status new => resolved
2014-10-13 21:23 henry Resolution open => fixed
2014-10-13 21:23 henry Assigned To => henry