
[Sponsors] 
December 10, 2007, 07:14 
Hello Armin,
I hope the lin

#101 
Member
vof_user
Join Date: Mar 2009
Posts: 67
Rep Power: 10 
Hello Armin,
I hope the link will be of any help. http://openfoamwiki.net/images/4/4a/Simple2DFlow.tar.gz 

December 18, 2007, 12:40 
Dear Saha
Mnay Rhanks about

#102 
New Member
Armin Hosseinian
Join Date: Mar 2009
Location: Perth, Western Australia, Australia
Posts: 17
Rep Power: 10 
Dear Saha
Mnay Rhanks about the comments. Appreciate about that. Reagrds Armin 

January 1, 2008, 03:59 
Hello all
I am going to run a

#103 
New Member
ehsan yasari
Join Date: Mar 2009
Location: Gothenburg, Sweden
Posts: 14
Rep Power: 10 
Hello all
I am going to run a channel395 with channel oodles solver, when i choose mixedsmagorinskey model and laplace filter, after some iteration, courant number diverged. but when i used simple filter it works,and also when i changed the mesh into uniform mesh, it works. I would appreciate any comments. Best Regards Ehsan 

January 30, 2008, 07:27 
Dear All,
I am running (or

#104 
Senior Member
Gavin Tabor
Join Date: Mar 2009
Posts: 181
Rep Power: 10 
Dear All,
I am running (or attempting to run at any rate) a surfacemounted cube case using LES. I have it running successfully on a fairly coarse mesh (72000 cells) with a timestep which gives a maximum Courant number of around 0.1. I attempted to refine the mesh somewhat, taking it to 140,000 cells, then mapping the existing solution across and restarting with a timestep 1/5th of the original. Trouble is, after about 20 timesteps (with max courant number of around 0.06) the solution blows up, and I cannot make sense of what the problem is. Initially the k field seemed to be going unbounded, followed by the Courant number exploding; however swapping SGS models (from oneEqEddy to Smagorinsky or to dynOneEqEddy) makes no difference. I have also tried drastically smaller timesteps, nonorthogonal correctors, and some changes to the differencing schemes used; without success. Any other suggestions as to what might be amiss here would be gratefully accepted. On a broader note; is there any source of information about what is available in the LES modelling area in OpenFOAM at the moment? The Users Guide is rather terse on this issue, and the usual reference papers from the 1990's are possibly out of date. I'd be particularly interested in nearwall modelling. Gavin 

January 30, 2008, 19:43 
What does checkMesh say about

#105 
Member
Andrew Burns
Join Date: Mar 2009
Posts: 36
Rep Power: 10 
What does checkMesh say about your new finer mesh? I haven't got any experience with LES but generally when my solution blows up with unbounding k and epsilon it's due to a poor mesh. You could try switching from linear corrected to linear limited 0.5 or so for k and epsilon too.


February 28, 2008, 12:33 
Hi,
I would like to take a

#106 
Senior Member
Fabian Braennstroem
Join Date: Mar 2009
Posts: 407
Rep Power: 12 
Hi,
I would like to take a look at my mesh resolution and check, if it is fine enough. There are actually a couple of different methods like the checking the energy spectra . Another way is the to check the turbulence resolution, i.e. the ratio of modelled to resolved turbulent kinetic energy. Does anyone know, how I can postprocess this using openfoam? Fabian 

February 28, 2008, 12:48 
Sounds fairly straightforward.

#107 
Senior Member
Gavin Tabor
Join Date: Mar 2009
Posts: 181
Rep Power: 10 
Sounds fairly straightforward. You have the U and k fields; write a code to read these in and calculate 0.5*sqr(U)/k.
Gavin 

February 29, 2008, 06:41 
@(August 10, 2005  04:50 pm)

#108 
Senior Member
Maka Mohu
Join Date: Mar 2009
Posts: 305
Rep Power: 11 
@(August 10, 2005  04:50 pm)
\quote(nuSgs doesn't matter because it is calculated from k and delta.) I have a related question. I've been using channelOodles for a while now. But suddenly, I asked myself why do we need to specify an initial and boundary condition for nuSgs if it is calculated from resolved (like Sij) and modeled variables like k) variables which have an initial and boundary condition of their own. I know that in case of wall functions for example specifying a boundary condition on nuSgs is useful but will such b.c. be consistent with the suface value that can be calculated from the resolved and modeld fields. I'm confused :(. Would you please give me some feedback on this. Best regards, Maka. 

February 29, 2008, 06:51 
Hi Gavin,
thanks, fairly st

#109 
Senior Member
Fabian Braennstroem
Join Date: Mar 2009
Posts: 407
Rep Power: 12 
Hi Gavin,
thanks, fairly straightforward; I would do it as a postprocessing step, but using the Smagorinsky I get no written k for the internal field. I actually tried to add: k_ ( IOobject ( "k", runTime_.timeName(), mesh_, IOobject::MUST_READ, IOobject::AUTO_WRITE ), mesh_ ), and added: volScalarField k_; to the Smagorinsky class... but this is not enough. Do you have an idea? Fabian 

February 29, 2008, 07:48 
Hi Fabian,
You are right 

#110 
Senior Member
Gavin Tabor
Join Date: Mar 2009
Posts: 181
Rep Power: 10 
Hi Fabian,
You are right  Smag does not use k. I'm tempted to suggest you switch to the 1equation model, at least for a bit to check the mesh. Alternatively, the basic equation for the viscosity from the Smag model is nu = C_s^2 \delta^2 S and you have nu, so I guess you could fiddle with this to get an estimate for k. Was this what you tried? I wouldn't bother adding it to the smagorinsky class  overkill, and it breaks the elegant relationship between the mathematical structure of the various models and the class inheretance (sorry; I designed that bit of the code!) Gavin 

March 6, 2008, 15:42 
Hi Gavin,
Thanks!
Actually

#111 
Senior Member
Fabian Braennstroem
Join Date: Mar 2009
Posts: 407
Rep Power: 12 
Hi Gavin,
Thanks! Actually the implementation of Smagorinsky uses: // Return SGS kinetic energy // calculated from the given velocity gradient tmp<volscalarfield> k(const tmp<voltensorfield>& gradU) const { return (2.0*ck_/ce_)*sqr(delta())*magSqr(dev(symm(gradU))); } // Return SGS kinetic energy tmp<volscalarfield> k() const { return k(fvc::grad(U())); } And I thought I could write these values to a file using the earlier mentioned lines for k!? Fabian 

April 1, 2008, 10:22 
Hi,
what do you have in the t

#112 
Member
ville vuorinen
Join Date: Mar 2009
Posts: 67
Rep Power: 10 
Hi,
what do you have in the turbulenceProperties dictionary as the LESmodel? Ville 

April 1, 2008, 14:06 
Hi Ville,
I know 'turbulenceP

#113 
Senior Member
Fabian Braennstroem
Join Date: Mar 2009
Posts: 407
Rep Power: 12 
Hi Ville,
I know 'turbulenceProperties' just in combination with the actual calculation!? The above problem occurs when compiling a small posttool, which needs the filter width. Fabian 

April 8, 2008, 12:36 
I actually solved the above pr

#114 
Senior Member
Fabian Braennstroem
Join Date: Mar 2009
Posts: 407
Rep Power: 12 
I actually solved the above problem using these lines:
#include "fvCFD.H" #include "incompressible/LESmodel/LESmodel.H" #include "incompressible/singlePhaseTransportModel/singlePhaseTransportModel.H" #include "incompressible/transportModel/transportModel.H" dimensionedScalar smallU ("smallU", dimensionSet(0,1,1,0,0), SMALL); // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // int main(int argc, char *argv[]) { # include "addTimeOptions.H" # include "setRootCase.H" # include "createTime.H" // Get times list instantList Times = runTime.times(); // set startTime and endTime depending on time and latestTime options # include "checkTimeOptions.H" runTime.setTime(Times[startTime], startTime); # include "createMesh.H" # include "turbRes.H" Info<< "delta = " << sgsModel>delta() <<endl; return(0); } // ************************************************** *********************** // and the 'turbRes.H' file: Info<< "Reading field p\n" << endl; volScalarField p ( IOobject ( "p", runTime.timeName(), mesh, IOobject::MUST_READ, IOobject::AUTO_WRITE ), mesh ); Info<< "Reading field U\n" << endl; volVectorField U ( IOobject ( "U", runTime.timeName(), mesh, IOobject::MUST_READ, IOobject::AUTO_WRITE ), mesh ); # include "createPhi.H" label pRefCell = 0; scalar pRefValue = 0.0; setRefCell(p, mesh.solutionDict().subDict("PISO"), pRefCell, pRefValue); singlePhaseTransportModel laminarTransport(U, phi); autoPtr<lesmodel> sgsModel ( LESmodel::New(U, phi, laminarTransport) ); I get problems, when running the code. It tries to open a 'k' file, which is not available, but where in these lines does this happen!? Fabian 

June 26, 2008, 08:25 
Hi all
Before going around

#115 
Senior Member
Niels Gjoel Jacobsen
Join Date: Mar 2009
Location: Deltares, Delft, The Netherlands
Posts: 1,746
Rep Power: 29 
Hi all
Before going around submitting it as a bugreport, I'd like to discuss if I am off track first. In nuSgsWallFunctionFvPatchScalarField.C the friction velocity is calculated as: scalar utau = sqrt((nuSgsw[facei] + nuw[facei])*magFaceGradU[facei]); with magFaceGradU being U.snGrad(). In anything but steady state and exceptionally simple geometries, there will be a normal velocity component at the wall, thus the gradient in this normal to the wall is incorporated in U.snGrad(), thus mag(U.snGrad()) != mag(Uf). Shouldn't U.snGrad() be projected onto the wall to avoid the normal stress in the bed shear stress? I am looking forward to hear your point of view. Best regards, Niels
__________________
Please note that I do not use the Friendfeature, so do not be offended, if I do not accept a request. 

June 27, 2008, 06:19 
This issue is known. The ratio

#116 
Senior Member
Eugene de Villiers
Join Date: Mar 2009
Posts: 725
Rep Power: 14 
This issue is known. The rationalization for keeping it as it is is as follows:
1. The wall normal gradient of velocity will tend to be small compared to the tangential gradient. 2. If there is a significant wall normal gradient then the wall functions are no longer valid in any case and the relative contribution of the error made by including the magnitude of the wall normal gradient is diminished due to the error incurred by assuming equilibrium. All that said, subtracting the normal component before calculating the gradient would be more correct. 

June 27, 2008, 07:11 
Thanks for the explanation.

#117 
Senior Member
Niels Gjoel Jacobsen
Join Date: Mar 2009
Location: Deltares, Delft, The Netherlands
Posts: 1,746
Rep Power: 29 
Thanks for the explanation.
Would you have any reference on the implemented wall function? Best regards, Niels
__________________
Please note that I do not use the Friendfeature, so do not be offended, if I do not accept a request. 

July 4, 2008, 07:21 
What does wallPointYPlus::yP

#118 
Senior Member
Maka Mohu
Join Date: Mar 2009
Posts: 305
Rep Power: 11 
[vanDriestDelta]
What does wallPointYPlus::yPlusCutOff = 500; do? any reason behind that? Thanks. Best regards, Maka. 

July 4, 2008, 07:42 
Hi Maka
In the vanDriest, a

#119 
Senior Member
Niels Gjoel Jacobsen
Join Date: Mar 2009
Location: Deltares, Delft, The Netherlands
Posts: 1,746
Rep Power: 29 
Hi Maka
In the vanDriest, a damping function given as exp(yPlus) is used (cannot recall if that is the exact expression), anyway, as yPlus exceeds some value, exp(yPlus) is effectively 0. The cutOff is used in the this part of the code: /OpenFOAM/OpenFOAM1.4.1/src/finiteVolume/fvMesh/wallDist/wallPointYPlus as this calculates the distance to the wall in yPluscoordinates, it also needs to know the bed shear stress in the nearest wall face, thus as I see it, it is a upper limit for this interconnection between distance and wall. Best regards, Niels
__________________
Please note that I do not use the Friendfeature, so do not be offended, if I do not accept a request. 

July 4, 2008, 08:59 
The expression is:
delta_ =

#120 
Senior Member
Maka Mohu
Join Date: Mar 2009
Posts: 305
Rep Power: 11 
The expression is:
delta_ = min ( static_cast<const>(geometricDelta_()), (kappa_/Cdelta_)*((scalar(1) + SMALL)  exp(y/ystar/Aplus_))*y ); at high y/ystar the exp term is zero and the expression reduces to: min(geometricDelta_(), (kappa_/Cdelta_)*y) I tried to understand what the cutOff do to y from src/finiteVolume/fvMesh/wallDist/wallPointYPlus but it was not clear. What I understood is that after the cutOff value it does not update y? // only propagate if interesting (i.e. y+ < 100) scalar yPlus = Foam::sqrt(dist2)/w2.data(); if (yPlus < yPlusCutOff) { // update with new values distSqr() = dist2; origin() = w2.origin(); data() = w2.data(); return true; } But what is the value of y when it is not updated? Thanks for your help. 

Thread Tools  
Display Modes  

