[maka]

nuSgs boundary condition:

case details: SUSE linux 10.2, OpenFOAM1.3, channelOodles - tutorial case (channel395).

how to reproduce it:

cd channel395;
rm -r 0;
cp -r 0.org 0;
change nuSgs b.c. on the bottom wall to:
bottomWall
{
type nuSgsWallFunctionWrongLetter;
value uniform 1;
}
assume that you had a new boundary condition defined but while typing the name you misspelled. The solver will run and seems to calculate nuSgs base k b.c.; It would be hard to know whether your new b.c. was applied without checking the fields and doing some hand calculation. This is because the code does not check for "type" to be a valid boundary condition, as long as you provide a value.

Best regards,
Maka.

[maka]

correction: ... calculate nuSgs based on k value; ...

Best regards,
Maka

[henry]

There is an option in .OpenFoam-1.4/controlDict

disallowDefaultFvPatchField 0;

which if set to 1 disallows undefined boundary conditions which is useful for testing.

Henry

[maka]

Thanks Henry.

[maka]

paraFoam
when disallowDefaultFvPatchField is set to 1,

paraFoam will refuse to process any case that uses a user defined wallFunction; This was tested in channelOodles. It only allows built-in boundary conditions. On the other hand OpenFOAM works well after setting such switch to 1. Thanks.

Best regards,
Maka.

[henry]

Yes that is the point of the switch, this is not a bug but an important feature.

[maka]

nuSgsWallFunction broken link with paraFoam:

I got that point from your first message but here is what I mean after I understood it better:

paraFoam does not accept nuSgsWallFunction which is an LES wall function that is distributed with the standard release. May be this is because it is compiled into libincompressibleLESmodels.so together with other LES sub-filter models, which is not felt by paraFoam.

Check the following error message. You can reproduce it by using the wall function with standard channelOodles tutorial. My guess is that paraFoam needs to know about the fact that some b.c. are compiled into libincompressibleLESmodels.so

--> FOAM FATAL IO ERROR : Unknown patchField type nuSgsWallFunction for patch type wall

Valid patchField types are :

28
(
fixedGradient
symmetryPlane
syringePressure
oscillatingFixedValue
freestreamPressure
turbulentInlet
freestream
wallBuoyantPressure
default
empty
fixedFluxPressure
fixedValue
uniformFixedValue
cyclic
mixed
processor
calculated
slip
timeVaryingUniformFixedValue
directionMixed
sliced
partialSlip
outletInlet
inletOutlet
wedge
zeroGradient
totalPressure
pressureTransmissive
)


file: /data/maka/OpenFOAM/run-1.3/channelOodles.01/delete/0/nuSgs::bottomWall from line 34 to line 35.

From function fvPatchField<type>::New(const fvPatch&, const Field<type>&, const dictionary&)
in file lnInclude/newFvPatchField.C at line 115.

FOAM exiting

Best regards,
Maka.

[maka]

I was thinking about a solution. Not only paraFoam need to know about the names of b.c. (wall functions) defined in libincompressibelLESmodels.so but also any user defined ones. If you read in this posted link in message: Maka Mohu on Thursday, June 21, 2007 - 11:43 am. You will find that LES wall function are special in such a way that one can not use foamUser library to add them, since they will be exposed to solvers which does not need nuSgs (icoFoam, ...). What I came up with is to make a foamUserLESmodelsIncompressible which is linked with libincompressibelLESmodels.so, which worked. As a result if paraFoam is need to be aware of LES wall functions in libincompressibelLESmodels.so, where that latter is linked to foamUserLESmodelsIncompressible.so. This will provide a solution where the precompiled version of paraFoam will work not only with LES standard-release wall functions but with user defined ones also. This solution may reflect my lack of knowledge of openFOAM, but it is the best I came up with.

Best regards,
Maka

[henry]

Why not simply set

disallowDefaultFvPatchField 0;

in .OpenFoam-1.4/controlDict then paraFoam will post-process BCs it does not know the details of.

[maka]

I recently got a strange error from channelOodles tutorial (channel395) in its standard setup. I did not find similar error posted on the forum. I found this error before and when I run the tutorial again I do not get the error in the same time step.


Time = 440
Courant Number mean: 0.0632141 max: 0.336486
BICCG: Solving for k, Initial residual = 0.00724241, Final residual = 4.61516e-06, No Iterations 2
BICCG: Solving for Ux, Initial residual = 0.00863137, Final residual = 7.95612e-06, No Iterations 2
BICCG: Solving for Uy, Initial residual = 0.0497597, Final residual = 7.79092e-07, No Iterations 3
BICCG: Solving for Uz, Initial residual = 0.0526165, Final residual = 8.45029e-07, No Iterations 3
ICCG: Solving for p, Initial residual = 0.140782, Final residual = 9.45507e-07, No Iterations 94
time step continuity errors : sum local = 2.98458e-10, global = -1.88345e-18, cumulative = -3.82092e-15
ICCG: Solving for p, Initial residual = 0.00933368, Final residual = 9.56856e-07, No Iterations 76
time step continuity errors : sum local = 3.02209e-10, global = -1.70725e-18, cumulative = -3.82263e-15
Uncorrected Ubar = 0.1335 pressure gradient = 4.95291e-05
ExecutionTime = 6807.97 s ClockTime = 22454 s


--> FOAM FATAL ERROR : NO_READ specified for read-constructor of object Bmean of class IOobject

From function regIOobject::readStream(const word&)
in file db/regIOobject/regIOobjectRead.C at line 53.

FOAM aborting

Foam::error::printStack(Foam:stream&)
Foam::error::abort()
Foam::regIOobject::readStream()
Foam::regIOobject::readStream(Foam::word const&)
Foam::regIOobject::read()
Foam::regIOobject::readIfModified()
Foam::objectRegistry::readModifiedObjects()
Foam::objectRegistry::readIfModified()
Foam::objectRegistry::readModifiedObjects()
Foam::Time::operator++()
channelOodles [0x419f9c]
__libc_start_main
__gxx_personality_v0



Best regards,
Maka.

[maka]

I noticed that the time step when the solver stops with such error is when the solver are about to write output to the disk.

[henry]

This is a complex file time-stamp interaction problem that took sometime to fix. Try version OpenFOAM-1.5.x, I am sure that will solve the problem for you.

H

[maka]

I will be very grateful if you could give me a small hint on which files to update between V1.3 and 1.5.x; I know I may be asking too much but I can not go through an upgrade now since, I'm facing a close deadline. Many Thanks.
best regards,
Maka