CFD Online Discussion Forums - OpenFOAM Bugs

OF1.6.x:localBlended schemes missing correction funtions

dominik_christ — Wed, 08 Sep 2010 10:01:16 GMT

Hello everyone,

when comparing fixedBlended.H and localBlended.H then localBlended is missing the member functions "correction" and "corrected". These should be necessary when using e.g. linearUpwind as one of the two blending schemes.
I attached a suggested fix, where I copied the two member functions with a little adjustment because the blending factor in localBlended.H is a field.

Best Regards
Dominik Christ

P.S.: Thanks to Sven Degner and Ulf Bunge who discovered this bug.

Attached Files

localBlended.H (6.6 KB)

1.5-dev: faceInterpolate in parallel crashes

matteoL — Tue, 07 Sep 2010 15:33:10 GMT

Hello,
on a boundary pacth, I am trying to interpolate values from the face centers to the vertices ( I need it for the displacementLaplacian mesh motion which requires the value specified on vertices and not face centres) using:

primitivePatchIntepolation< polyPatch> interp
{
mesh.boundaryMesh()[patchID]
}

pointDispPatch==
interp.faceToPointInterpolate
{
...
}

This works nicely in serial but when when started in parallel it crashes saying that the field generated by the interpolation is smaller than the (point)boundary size...

Any idea why?
is there an easy solution to the problem?

thanks,
matteo

Doxygen search doesn't work

l_r_mcglashan — Tue, 07 Sep 2010 12:04:14 GMT

The search function at http://www.openfoam.com/docs/cpp/ doesn't work for me. Does it for anybody?

OpenCFD mantis does not allow to submit issues due to empty product version list

alberto — Mon, 06 Sep 2010 03:21:51 GMT

Hello,

when trying to submit a bug on OpenCFD's Mantis, the product version is a requested field, but the drop-down list is empty.

This results in an error message which prevents to submit the bug.

Thanks.

Best,

Error during writing of fields in massive parallel simulations

chbeck — Sun, 05 Sep 2010 19:33:44 GMT

Hello,

I am performing LES simulations on a big cluster using ~1000 cores. In some cases during writing of the fields half of the processor dictionaries get written for time step n and the other half of the processor directories gets written for the time step n+1. This issue becomes apparent when trying to use the stored solutions for restart etc...

-Wall clock time per time steps is ~0.5s.
-Version 1.6 from the git repository from ~Dec 2009
-A lustre file system is used

Some modified settings:

minBufferSize=300000000

OptimisationSwitches
{
fileModificationSkew 10;
commsType nonBlocking; //scheduled; //blocking;
floatTransfer 0;
nProcsSimpleSum 0;
}

mutRoughWallFunction on OF 1.7.0

OMN — Thu, 02 Sep 2010 06:23:44 GMT

Hello

I tried to set up a rough wall for a run with buoyantSimpleFoam in OF 1.7 using the syntax:

wall
{
type mutRoughWallFunction;
Ks uniform 0.005;
Cs uniform 0.5;
value uniform 0;
}

and I got this error message after starting buoyantSimpleFoam:

Selecting RAS turbulence model realizableKE
#0 Foam::error::printStack(Foam::Ostream&) in "/opt/openfoam170/lib/linuxGccDPOpt/libOpenFOAM.so"
#1 Foam::sigFpe::sigFpeHandler(int) in "/opt/openfoam170/lib/linuxGccDPOpt/libOpenFOAM.so"
#2 Uninterpreted:
#3 log in "/lib/tls/i686/cmov/libm.so.6"
#4 Foam::compressible::RASModel::yPlusLam(double, double) const in "/opt/openfoam170/lib/linuxGccDPOpt/libcompressibleRASModels.so"
#5 Foam::compressible::RASModels::mutRoughWallFunctio nFvPatchScalarField::calcMut() const in "/opt/openfoam170/lib/linuxGccDPOpt/libcompressibleRASModels.so"
#6 Foam::compressible::RASModels::mutWallFunctionFvPa tchScalarField::updateCoeffs() in "/opt/openfoam170/lib/linuxGccDPOpt/libcompressibleRASModels.so"
#7 Foam::fvPatchField::evaluate(Foam::Pstream ::commsTypes) in "/opt/openfoam170/applications/bin/linuxGccDPOpt/buoyantSimpleFoam"
#8 Foam::GeometricField::GeometricBoundaryField::evaluate() in "/opt/openfoam170/applications/bin/linuxGccDPOpt/buoyantSimpleFoam"
#9 Foam::compressible::RASModels::realizableKE::reali zableKE(Foam::GeometricField const&, Foam::GeometricField, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField const&, Foam::basicThermo const&) in "/opt/openfoam170/lib/linuxGccDPOpt/libcompressibleRASModels.so"
#10 Foam::compressible::RASModel::adddictionaryConstru ctorToTable::New(Foam::GeometricField const&, Foam::GeometricField, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField const&, Foam::basicThermo const&) in "/opt/openfoam170/lib/linuxGccDPOpt/libcompressibleRASModels.so"
#11 Foam::compressible::RASModel::New(Foam::GeometricF ield const&, Foam::GeometricField, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField const&, Foam::basicThermo const&) in "/opt/openfoam170/lib/linuxGccDPOpt/libcompressibleRASModels.so"
#12
in "/opt/openfoam170/applications/bin/linuxGccDPOpt/buoyantSimpleFoam"
#13 __libc_start_main in "/lib/tls/i686/cmov/libc.so.6"
#14
in "/opt/openfoam170/applications/bin/linuxGccDPOpt/buoyantSimpleFoam"
Floating point exception

Would someone know what the problem is? Everything works fine with mutWallFunction.

I also tried to use mutRoughWallFunction in the hotroom tutorial for buoyantSimpleFoam but I got the same error message. I also tried this with rhoPorousSimpleFoam and got the same error message. Is this a bug or my lack of understanding of the use of mutRoughWallFunction?

Cheers

Olivier

OpenFOAM Bugs Section on cfd-online obsolete?

holger_marschall — Fri, 27 Aug 2010 07:13:57 GMT

Dear OpenCFD�-Team,

I noted that the new release coincides with a "new" bug reporting system based on Mantis BT on your website (http://www.openfoam.com/support/bug-reporting.php).

Is the OpenFOAM Bug section within this forum obsolete?

best regards,

label/scalar mixup in hierarchGeomDecomp.C

mwild — Thu, 26 Aug 2010 08:13:22 GMT

The bug is in src/decompositionMethods/decompositionMethods/hierarchGeomDecomp/hierarchGeomDecomp.C:

Code:

279         label weightedSize = returnReduce

280         (

281             sortedWeightedSizes[mid] - sortedWeightedSizes[minIndex],

282             sumOp()

283         );

where sortedWeightedSizes is a List. It probably should be fixed by

Code:

--- a/src/decompositionMethods/decompositionMethods/hierarchGeomDecomp/hierarchGeomDecomp.C

+++ b/src/decompositionMethods/decompositionMethods/hierarchGeomDecomp/hierarchGeomDecomp.C

@@ -276,10 +276,10 @@ void Foam::hierarchGeomDecomp::findBinary

 

     while (true)

     {

-        label weightedSize = returnReduce

+        scalar weightedSize = returnReduce

         (

             sortedWeightedSizes[mid] - sortedWeightedSizes[minIndex],

-            sumOp()

+            sumOp()

         );

 

         if (debug)

Michael

wallDist error in OF-1.5.x

elisabet — Thu, 19 Aug 2010 15:27:42 GMT

Hi everybody,

I've experienced some problems with the wallDist function for the case shown below. It consists on two banana shaped channels (inlet at left and outlet at right) and the U-bend that connects both channels. I need to evaluate the wall distance from the patch market in black (at the left of the figure)

Attachment 4458

The wallDist function seems to return the good wall distance for the inlet channel but for the outlet channel it somehow follows what would be a fluid trajectory:

Attachment 4459

In order to obtain the right wall distance I've had to create a new geometry without the separation of both channels and, over it, apply the wallDist function. Afterwards, interpolate the result to the real geometry:

Attachment 4460

In my case, as I needed the wall distance as a pre-processor and not during the simulation, the above mentioned solution was good enough (despite not elegant at all...).

I guess the solution is not straightforward but for those who like maths challenges... here you are!

Regards,

Elisabet

Attached Images

	banana_shape.png (2.7 KB)
	banana_wallDist.png (7.3 KB)
	unifiedBanana_wallDist.png (13.2 KB)

Particle-class uses wallImpactDistance on non-wall patches

gschaider — Thu, 19 Aug 2010 11:54:48 GMT

Versions: this is found in OF-Versions 1.5 till the present (1.7.x)

Description: When calculating the lambda (normalized time to impact on a patch) the wallImpactDistance (basically radius of the particle) is used to take a non-zero thickness into acount when a particle is being reflected on a wall. The problem is that the wallImpactDistance is used for all other types of patches. This leads especially for processor-patches to the problem that the exact time when the particle center crosses onto the other processor is not correctly predicted which for unfortunate circumstances (small timesteps are a big factor, then it happens even with very small particles) can lead to particles being transfered back and forth across a processor boundary (but also for symmetry-boundaries the particle never reaches the symmetry, but is reflected before it).
The picture below is from an uncoupledKinematicParcelFoam-simulation (1.7.x, no modifications to the code) and illustrates the problem:
Attachment 4452
(the strange blocking of the particles is a processor-boundary and is not seen in the serial version of this run)

This patch checks whether a boundary-face is a wall and only then applies the impact distance:
Attachment 4453

After applying the patch in the same simulation particles have no problem to "get to the other side" and the result looks like the serial computation (same decompostion as the original picture):
Attachment 4451

(it can be discussed of course whether the impact distance is relevant for other "regular" patches but for the general case - outlet, inlet - I think the particle center is the better point of reference)

Bernhard

Attached Images

	patchedParticle.jpg (17.1 KB)
	unpatchedParticle.jpg (15.7 KB)

Attached Files

wallParticles.patch (1.2 KB)

foamToVTK & foamDataToFluent problem!

germinal — Mon, 16 Aug 2010 07:57:48 GMT

Hi!

I try to convert my results (fireFoam tutorial im OpenFOAM 1.7) to VTK or .data but I get:

--> FOAM FATAL IO ERROR:

Cannot find 'value' entry on patch base of field IDefault in file "/model/villami/OpenFOAM/villami-1.7.0/run/tutorials/combustion/fireFoam/les/smallPoolFire2D/0/IDefault"
which is required to set the values of the generic patch field.
(Actual type greyDiffusiveRadiation)

Please add the 'value' entry to the write function of the user-defined boundary-condition
or link the boundary-condition into libfoamUtil.so

file: /model/villami/OpenFOAM/villami-1.7.0/run/tutorials/combustion/fireFoam/les/smallPoolFire2D/0/IDefault::boundaryField::.* from line 25 to line 28.

From function genericFvPatchField::genericFvPatchField(con st fvPatch&, const Field&, const dictionary&)
in file genericFvPatchField/genericFvPatchField.C at line 71.

FOAM exiting

Whats up here???
Thanks in advance for your help :-)

Definition of S in SpalartAllmarasDDES::rd

Luise — Thu, 12 Aug 2010 16:51:40 GMT

Hi,

in SpalartAllmarasDDES the denominator of rd uses the magnitude of vorticity, like the RAS-model. In the original paper Spalart uses the magnitude of the gradient of U, "in order to be slightly more robust in irrotational regions".

Regards,
Luise

Bogus setFieldsDict in damBreak4phase{,Fine} tutorial cases

mwild — Tue, 10 Aug 2010 10:15:36 GMT

The volume fraction files are called alpha{air,water,mercury,oil}, and the phases are called air, water, mercury and oil in the transportProperties dictionary, but the setFieldsDict calls them alpha{Air,Water,Mercury,Oil}.

Michael