decompose with wallfunctions
 

Hi

I'm having some problems decomposing a case with wallfunctions.
If I run it in serial there are no problems but when trying to decompose I get this error (below).

If I add the "value uniform 0;" below the kqRWallFunction line I can decompose but I don't see why this should be required when using high Re turb model in parallel.

My k and epsilon entry for the wall

propeller
{
type kqRWallFunction;
}

propeller
{
type epsilonWallFunction;
}

Cannot find 'value' entry on patch propeller of field k in file "/home/nini/OpenFOAM/nini-1.6/run/Full3d/P1410_4/0/k"
which is required to set the values of the generic patch field.
(Actual type kqRWallFunction)

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

file: /home/nini/OpenFOAM/nini-1.6/run/Full3d/P1410_4/0/k::propeller from line 55 to line 55.

From function genericFvPatchField<Type>::genericFvPatchField(con st fvPatch&, const Field<Type>&, const dictionary&)
in file fields/fvPatchFields/basic/generic/genericFvPatchField.C at line 72.

I also faced this problem. One trickier solution would be to run in serial till the openFOAM creates new k and epsilon files and moves old files as k.old and epsilon.old, try decomposepar then.

But It would be nice if decomposePar utility changed to consider keqWallfunction boundary too.

Santosh..

I did something similar.

I just decomposed and then deleted the "value" line in each of the k/epsilon files under each processor folder, not a nice approach but it works :-)

Humm... I've read some post that uses
value $internalField;
not sure what it does, but seems to be working.

Hi,
as far as I understand the behaviour of the wall function routines in OpenFOAM, I believe that the values in the BC are just placeholders. They are not used by the solvers and are re-calculated for the wall patches. However, some of the utilities will complain if a value is not provided (decomposePar and paraFoam, for example). I believe this is a bug, and the only solution, for now, is to provide 'dummy' values (for example the same value as the internal field, or 0).

This is just my opinion, maybe someone more expert than me will deliver a better answer :)

@cwang5: I think that statement is just another way of using the internal field values; as I was saying above, it should not have any effect on the calculations.