nuSgs boundary condition: c
nuSgs boundary condition:
case details: SUSE linux 10.2, OpenFOAM1.3, channelOodles - tutorial case (channel395).
how to reproduce it:
rm -r 0;
cp -r 0.org 0;
change nuSgs b.c. on the bottom wall to:
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.
correction: ... calculate nuSg
correction: ... calculate nuSgs based on k value; ...
There is an option in .OpenFoa
There is an option in .OpenFoam-1.4/controlDict
which if set to 1 disallows undefined boundary conditions which is useful for testing.
paraFoam when disallowDefaul
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.
Yes that is the point of the s
Yes that is the point of the switch, this is not a bug but an important feature.
nuSgsWallFunction broken link
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 :
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.
I was thinking about a solutio
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.
Why not simply set disallo
Why not simply set
in .OpenFoam-1.4/controlDict then paraFoam will post-process BCs it does not know the details of.
I recently got a strange error
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.
I noticed that the time step w
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.
This is a complex file time-st
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.
I will be very grateful if you
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.
|All times are GMT -4. The time now is 19:42.|