BUG: inconsistent result for Third-party test case (DEShybrid)

• blending factor seems to behave differently for processor boundries

• reconfirm the blending factor calculation (seem to show some differences)

@Sergio @Mattijs @Koushik

Do you get the same effect if e.g. using a localBlended scheme?

Such effect is not observed with:

div(phi,U) Gauss CoBlended 0.05 LUST grad(U) 1 linearUpwind grad(U);

Is it then the velocity field itself incorrectly setup with DEShybrid scheme?

Sounds as if the blendingFactor surfaceScalarField calculated by the DESHybrid scheme is not correctly calculated on the processor boundaries.

Discussed with Prashant, my 4 concerns are;

• values 0-1 seem to be the wrong way round
• external boundary value of 1.0 is probably right, but switches to 0.0 in the very next cell
• processor boundary as already noted
• smearing of the contours, as already noted

By Fred Mendonca on 2016-01-05T13:43:19 (imported from GitLab project)

mentioned in commit 15f342b1211decce3432a07f5b5b5b3fa0ddd595

• processor boundary problem fixed in LESDelta
• contours are smeared because we are looking at a volScalarField derived from a surfaceScalarField which is from interpolation of an indicator volScalarField
• the indicator field itself can be written through setting the debug flag 'blendedSchemeBase'

Status changed to closed by commit 15f342b1211decce3432a07f5b5b5b3fa0ddd595

By Andrew Heather on 2016-01-08T12:41:03 (imported from GitLab project)