decompose with wallfunctions

linnemann · September 14, 2009, 05:06

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:ropeller 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.

santoo_cfd · September 14, 2009, 11:23

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..

linnemann · September 14, 2009, 12:22

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 :-)

cwang5 · October 16, 2009, 06:03

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

mcarpe · October 16, 2009, 07:41

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.

September 14, 2009, 05:06	decompose with wallfunctions	#1
linnemann Senior Member Niels Nielsen Join Date: Mar 2009 Location: NJ - Denmark Posts: 556 Rep Power: 27	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:ropeller 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.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
[CGNS] CGNS converters available	mbeaudoin	OpenFOAM Meshing & Mesh Conversion	137	December 14, 2018 05:20
Wallfunctions onoff	gjesing	OpenFOAM Running, Solving & CFD	5	February 11, 2010 00:55
Regarding wallFunctions	Hectux	OpenFOAM Running, Solving & CFD	0	May 29, 2009 04:23
Serial OK parallel failsmesh conversion problem	r2d2	OpenFOAM Running, Solving & CFD	15	July 31, 2008 16:04
Bug in twoPhaseEulerFoam wallfunctions	alberto	OpenFOAM Bugs	1	February 9, 2007 15:15

September 14, 2009, 11:23		#2
santoo_cfd Member santhosh Join Date: Apr 2009 Location: India Posts: 70 Rep Power: 17	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..

September 14, 2009, 12:22		#3
linnemann Senior Member Niels Nielsen Join Date: Mar 2009 Location: NJ - Denmark Posts: 556 Rep Power: 27	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 :-)

October 16, 2009, 06:03		#4
cwang5 Member John Wang Join Date: Mar 2009 Location: Singapore Posts: 73 Rep Power: 17	Humm... I've read some post that uses value $internalField; not sure what it does, but seems to be working.

October 16, 2009, 07:41		#5
mcarpe New Member Matteo Carpentieri Join Date: Mar 2009 Posts: 28 Rep Power: 17	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.