CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Running, Solving & CFD

Atmospheric boundary layer

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Display Modes
Old   June 16, 2010, 09:47
Default
  #21
Member
 
Michael
Join Date: Mar 2009
Posts: 48
Rep Power: 7
farbfilm is on a distinguished road
Hi,

the profile at the inlet looks ok - the other profiles not!
It seems that your roughWallCondition is not working...
(Do you really use 1.6.x - maybe you have to reinstall it)

My first cell height is 1m! I used the mesh from Hargreaves&Wright: "On the use of the k-e model in commercial CFD software to model the neutral atmospheric boundary layer"

Do you know the requirements for the mesh when you want to simulate a rough wall??
If not, see (for example): Blocken et al: "CFD Simulation of the atmospheric boundary layer - wall function problems"
Ks shouldn't be higher than the half of the first cell!!
farbfilm is offline   Reply With Quote

Old   June 16, 2010, 10:12
Default
  #22
Senior Member
 
Daniele
Join Date: Feb 2010
Posts: 134
Rep Power: 6
Daniele111 is on a distinguished road
I'm getting crazy! I'm using your bc, my mesh is 250X10 cell 250 along main flow and 10 along height. First cell height is 0.9 m

vertices
(
(0 0 0)
(1000 0 0)
(1000 100 0)
(0 100 0)
(0 0 5)
(1000 0 5)
(1000 100 5)
(0 100 5)
);

blocks
(
hex (0 1 2 3 4 5 6 7) (250 10 1) simpleGrading (1 15 1)
);


I'm respecting blocken condition, I don't understand! I try to recompile 1.6.x boh...
Daniele111 is offline   Reply With Quote

Old   June 17, 2010, 08:25
Red face
  #23
Senior Member
 
maddalena's Avatar
 
maddalena
Join Date: Mar 2009
Posts: 436
Rep Power: 11
maddalena is on a distinguished road
Quote:
Originally Posted by farbfilm View Post
It seems that your roughWallCondition is not working...
Hello,
I also have problems with nutRoughWallFunction. I am sure I am using OF 1.6.x, but whenever I change Ks, the output values does not changes (see nutRoughWallFunction v1.6 - Values for Ks and Cs). I respected the requirement of Ks smaller than half of the first cell, but no way...
farbfilm, have you a simple working case that I may test on my pc to see if is a problem of my OF installation?
Thank for any help,

mad
maddalena is offline   Reply With Quote

Old   May 14, 2011, 12:57
Unhappy Boundary layer profile at inlet for cavity study in Fluent
  #24
uea
New Member
 
uea
Join Date: May 2011
Posts: 2
Rep Power: 0
uea is on a distinguished road
Hi there,
I m' working on cavity flow study.I need a boundary layer of 13.5 mm in front of the cavity.I tried to get a velocity profile in a 2D rectangular channel which. The freestream velocity is approximately 505 m/s (1657 ft/s).The Reynolds number was 3*107 /m (9.2* 106 /ft) Stagnation pressure is 0.26 Mpa (38 psia) and stagnation temperature is 292 K(525 R).(Mach number is 2) In experiments boundary layer thickness is found based on %99 of the freestream velocity is 13.5 mm (0.53 in). My channel area is 6.4 m length * 0.16 m wide (I tried very long channel for fully developed flow-40D long) My boundary conditions are;
İnlet&upper wall= pressure far field
Outlet=Pressure outlet
Bottom wall=wall
I tried several models; Laminar Model, k-w , k-e standart wall function model however ı can’t get 13.5 mm boundary layer thickness. a good solution can only be achieved when y+ < 1, my y+ value is nearly 0.4. (I used a hybrid mesh)
So my question is: Something is wrong in my analysis! İs this my model? Boundary conditions? Or my grid? What is appropriate conditions for this supersonic flow?
Thank you very much for reading!
uea is offline   Reply With Quote

Old   July 24, 2011, 05:45
Default
  #25
Senior Member
 
Andrea Pasquali
Join Date: Sep 2009
Location: Germany
Posts: 137
Rep Power: 6
andrea.pasquali is on a distinguished road
Hi All,
I found same problems with OF 2.0.x.
Here my post: ABL in OF2.0.x
(I attached there also my test case).
I'm using ABL BC.
Do you think I should use the groovyBC.
I read in this post: atmBoundaryLayerInletVelocity profiles
that this problem is fixed in 1.7.x.
Has the problem came back in 2.0.x?

Thanks for any help

Andrea
__________________
Andrea Pasquali
andrea.pasquali is online now   Reply With Quote

Old   July 27, 2011, 12:46
Default Problems simulating log-profile in OpenFOAM
  #26
New Member
 
Nijs Jan Duijm
Join Date: May 2011
Location: Copenhagen area
Posts: 2
Rep Power: 0
Nijs Jan Duijm is on a distinguished road
I try to simulate a 2D homogeneous atmospheric boundary layer (lower part: surface layer with logarithmic velocity profile) using the RAS (k-eps) OpenFOAM 1.7.1 tools (and realizing the discussion about peaks in k and eps). The domain is 50 m high and 500 m long.
I started with simpleFoam and using boundary conditions from the turbineSiting tutorial. This didn’t work out as expected so I started by using uniform inflow profiles for U, k, and eps, and zeroGradient BC-s at top and ground, and then introducing the ABL boundary conditions one at a time.
I discovered following:
1) Using fixedShearStress for U at the top leads to a decrease in velocity at the top. There is little (no) guidance to find on how to call fixedShearStress (e.g. whether one should initiate tau0), but results are the same. If the shear stress is based on dU/dn, then shearstress would be zero for a uniform profile, and no effect would be expected? In a log profile, dU/dn should produce an accelerating shear stress on the top (the shear stress should be the only driving force for the flow). Can anyone help?
2) Using atmBoundaryLayerInletEpsilon and ..Velocity produces profiles on the first gridline that are close, but not completely identical to theoretical values. (Note: I use identical values for z0 and zGround, thus reproducing a profile u*/kappa ln(z/z0), and my domain starts at z0)
3) I use fixedValue=0 for U at the ground (z=z0), kqRWallFunction for k, and nutRoughWallFunction for nut (with Ks=20 z0). If I use epsilonWallFunction for epsilon, I get an overflow error (probably in a value for k) after a few timesteps, so I use a fixed value for epsilon with the theoretical value (u*^3/kappa/z) at z=z0 (lower boundary). In any case, the values for k and nut at the end of the domain become much larger (order of 10) than they should be, both for z0=0.01 m and z0=0.1 m, and velocity becomes much too low in the lower part of the domain. These effects ar much larger than those reported by Hargreaves and Wright. Any explanations or suggestions how to solve these issues?
Nijs Jan Duijm is offline   Reply With Quote

Old   January 18, 2012, 09:35
Default Problems in getting fixedShearStress to work in parallel
  #27
New Member
 
Sam Fredriksson
Join Date: Dec 2010
Posts: 19
Rep Power: 5
safre is on a distinguished road
Have you run the fixedShearStress bc in parallel?

I'm not fully sure how to specify the bc but it seems to work well in /U as:

surface
{
type fixedShearStress;
tau (0.0001 0 0);
}

when I run it in single mode. When I decompose I have to alter /U to

surface
{
type fixedShearStress;
value (0.0001 0 0);
}

during decomposition and then I change back again with a sed command to tau before mpirun. It seems to work but is not very effecient way of working.

Do you know a solution to this?

Best regards, Sam
safre is offline   Reply With Quote

Old   January 19, 2012, 06:53
Default
  #28
New Member
 
Nijs Jan Duijm
Join Date: May 2011
Location: Copenhagen area
Posts: 2
Rep Power: 0
Nijs Jan Duijm is on a distinguished road
My problem on issue 1) was solved with the kind help of Jonathon Sumner. There was a small syntax error in the 0/U file specifying tau. (should not hav been tau0)
I have not tried to run in parallel mode.
Regards, Nijs Jan
Nijs Jan Duijm is offline   Reply With Quote

Old   January 23, 2012, 14:12
Default
  #29
Member
 
ubald's Avatar
 
Nicolas Lussier Clément
Join Date: Apr 2009
Location: Montréal, Qc, Canada
Posts: 43
Rep Power: 7
ubald is on a distinguished road
hello safre,

I did not try to use fixedShearStress in parallel but rather I did build my own BC the thing I can tel you is that.

fixedShearStress as a fixedValueFvPatchVectorField for mother class and the value variable is implemented in there where the tau variable is implemented in fixedShearStress.

Which means that if decompose par need the value variable you can give it.

The value variable is updated in the fixedShearStressFvPatchVectorField::updateCoeffs() member function. this means that you can chose a value of (0 0 0) and it should not matter unless the initial value is really important for some reason.

So I'd tel you to try:

surface
{
type fixedShearStress;
tau (0.0001 0 0);
value uniform (0 0 0);
}

And verify if if everything is ok.

Regards
NLC
ubald is offline   Reply With Quote

Old   January 24, 2012, 04:03
Smile Thank you!
  #30
New Member
 
Sam Fredriksson
Join Date: Dec 2010
Posts: 19
Rep Power: 5
safre is on a distinguished road
This works fine - thank you!

Best regards, Sam
safre is offline   Reply With Quote

Old   January 24, 2012, 14:47
Default
  #31
Member
 
ubald's Avatar
 
Nicolas Lussier Clément
Join Date: Apr 2009
Location: Montréal, Qc, Canada
Posts: 43
Rep Power: 7
ubald is on a distinguished road
God to know !

Doxygen is your friend in OpenFOAM



Regards
ubald is offline   Reply With Quote

Old   August 3, 2012, 07:15
Thumbs up fixedShearStress top BC problem
  #32
New Member
 
Aniko Rakai
Join Date: Oct 2009
Location: Budapest
Posts: 29
Rep Power: 6
ancsa is on a distinguished road
Hello,

I am also trying to use the fixedShearStress BC on the top but I either get a blown up simulation:
Code:
#0  Foam::error::printStack(Foam::Ostream&) in "/opt/openfoam200/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#1  Foam::sigFpe::sigHandler(int) in "/opt/openfoam200/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#2   in "/lib/libc.so.6"
#3  Foam::divide(Foam::Field<double>&, double const&, Foam::UList<double> const&) in "/opt/openfoam200/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#4  Foam::operator/(double const&, Foam::tmp<Foam::Field<double> > const&) in "/opt/openfoam200/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#5  Foam::incompressible::fixedShearStressFvPatchVectorField::updateCoeffs() in "/opt/openfoam200/platforms/linux64GccDPOpt/lib/libincompressibleRASModels.so"
#6  Foam::fvPatchField<Foam::Vector<double> >::evaluate(Foam::UPstream::commsTypes) in "/opt/openfoam200/platforms/linux64GccDPOpt/bin/simpleFoam"
#7  Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::GeometricBoundaryField::evaluate() in "/opt/openfoam200/platforms/linux64GccDPOpt/bin/simpleFoam"
#8
in "/opt/openfoam200/platforms/linux64GccDPOpt/bin/simpleFoam"
#9  __libc_start_main in "/lib/libc.so.6"
#10
in "/opt/openfoam200/platforms/linux64GccDPOpt/bin/simpleFoam"
or I get a profile forced to 0 velocity on top (see attaches figure), which is when I set no tau so the default:
Code:
tau0_(dict.lookupOrDefault<vector>("tau", vector::zero))
is taken. This I also do not understand as then it should be like zeroGradient in my opinion.

The simulation runs fine with prescribed top velocity and the Richards and Hoxey profiles, the problem occurs only when I prescribe these top BCs:
Code:
U
    TopSide
    {
        type            fixedShearStress;
        tau               (-0.00089 0 0);          
    }
k
    TopSide
    {
        type            zeroGradient;      
    }
epsilon
    TopSide
    {
        type            fixedGradient;
        gradient           uniform -0.000017;
}
Can someone point me where I am wrong or post a working set of BC-s for the fixedShear?

I was testing 1.7 and 2.0 versions with the same results.

Thank you
Aniko
Attached Images
File Type: jpg ABL_U.jpg (88.5 KB, 23 views)
ancsa is offline   Reply With Quote

Old   August 15, 2012, 17:18
Default fixedShearStress problem
  #33
New Member
 
David Chiba
Join Date: Aug 2012
Posts: 3
Rep Power: 4
cheeba is on a distinguished road
I have the exact same problem Aniko. Any resolution?

Thanks,
David
cheeba is offline   Reply With Quote

Old   August 16, 2012, 08:52
Default
  #34
Member
 
ubald's Avatar
 
Nicolas Lussier Clément
Join Date: Apr 2009
Location: Montréal, Qc, Canada
Posts: 43
Rep Power: 7
ubald is on a distinguished road
as I said fixedShearStress is a fixedValueFvPatchVectorField

so you have a Diriclet boundary condition on U
and Neumann boundary on epsilon and k

I personally dislike all the result I got with such mix
I use all Neumann or all Diriclet for those quantity.

You should look at the nut value epsilon and k.
One problem I got is that nut went hi with the k and U where smaller as nut=cmu*k^2/epsilon and u** = nut*dU/dz ...


If you want to use Neumann, Try with calculated gradient for U as you did for epsilon
or you can do I did and compile your new BC for shear using Gradient for epsilon and U ..


Foam::sigFpe::sigHandler(int) mean that some quantity went wrong !!
But there miss some information in your post !

The full log and the full set of boundary condition would help !
This is a 3D, 2D or uniform ?!
How hi is the top BC compare to the highest obstacle ??

In any case a good initialization should be use.
ubald is offline   Reply With Quote

Old   August 16, 2012, 11:11
Default
  #35
New Member
 
Aniko Rakai
Join Date: Oct 2009
Location: Budapest
Posts: 29
Rep Power: 6
ancsa is on a distinguished road
Hi,

I tried also fixedGradient for U with the same results but I do not agree that fixedShearStress is a Dirichlet condition, the description from .H file:
Code:
Description
    Set a constant shear stress as tau0 = -nuEff dU/dn
So it is just a gradient as well, all BCs are Neumann.

I cannot attach the case due to upload file limits, but the BC report is this:
Code:
Table of boundary conditions for t = 0
======================================


========== ==================== =========================== ======== ============ ========= =============
..         GroundWall           Inlet                       LeftSide Outlet       RightSide TopSide      
---------- -------------------- --------------------------- -------- ------------ --------- -------------
Patch Type wall                 patch                       empty    patch        empty     patch        
Length     400                  168                         67200    168          67200     400          
========== ==================== =========================== ======== ============ ========= =============
U          fixedValue           timeVaryingMappedFixedValue empty    zeroGradient empty     fixedGradient
epsilon    epsilonWallFunction  timeVaryingMappedFixedValue empty    zeroGradient empty     fixedGradient
k          kqRWallFunction      fixedValue                  empty    zeroGradient empty     zeroGradient 
nut        nutRoughWallFunction calculated                  empty    calculated   empty     calculated   
p          zeroGradient         zeroGradient                empty    fixedValue   empty     zeroGradient 
========== ==================== =========================== ======== ============ ========= =============
A simple 2D atmospheric boundary layer with Richards and Hoxey inlet conditions, no obstacle.

Aniko
ancsa is offline   Reply With Quote

Old   August 16, 2012, 19:29
Default
  #36
New Member
 
David Chiba
Join Date: Aug 2012
Posts: 3
Rep Power: 4
cheeba is on a distinguished road
Hi Aniko,

The fixedShearStress boundary condition works just fine in version 2.1.1
I just successfully did a run with the following in my boundary field for U:

movingWall
{
type fixedShearStress;
tau (0.001 0 0);
}


Still have no idea what's going on in 2.0.

Cheers,
David
cheeba is offline   Reply With Quote

Old   August 19, 2012, 15:55
Default
  #37
Member
 
ubald's Avatar
 
Nicolas Lussier Clément
Join Date: Apr 2009
Location: Montréal, Qc, Canada
Posts: 43
Rep Power: 7
ubald is on a distinguished road
Hi Aniko,

You are wright that the fixedShearStress is not strictly Dirichlet boundary condition.

That said by looking more in to the code you can see that fixedGradientFvPatchField and fixedValueFvPatchField are not treated the same way in OpenFOAM and that fixedShearStress is a fixedValueFvPatchField. But I'd be surprise if this is the source of your problem. And in OF 1.7 I did not find any problem with BC.

Your BC seam to be correct but I did not use timeVaryingMappedFixedValue. For the top I set p to zero fixed value if I use gradient for U, epsilon and k and zero gradient if I use fixed value for the other just to make thing easier to converge !

It seam to me that if U and epsilon vary in time at the inlet k should vary to ! If k is in fact stable it mean that nut will vary with the variation of epsilon and thus the shear at the top also making thing more unstable !!

Do you have the same problem with RH inlet BC that dont vary ?

You will have to look when in the process the shear is updated for the fixedShearStress BC compare to a shear made with a gradient BC.

One last point what is the size of the top cell and what is the z+ at the wall ?
If z+ is to big at the wall error of the wall BC will propagate in z direction and a "numerical error boundary layer" will become evident with top gradient condition this will be worst.

And on top with big cell and gradient or fixed value the shear evaluation for the cell will not be good.

What about initialization ? Do you set to RH at initial time on all the domain ?

Hope that what I'm saying help.
To do more I'd need the case.

Regards
ubald is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Turbulent Boundary Layer on a Flat Plate Hoshang Garda FLUENT 1 November 27, 2013 10:24
Wind turbine simulation Saturn CFX 32 October 8, 2013 07:53
RPM in Wind Turbine Pankaj CFX 9 November 23, 2009 04:05
Combining BCs: wall - outlet. Boundary layer disappears MartinaF OpenFOAM Running, Solving & CFD 1 July 20, 2009 18:14
Convective Heat Transfer - Heat Exchanger Mark CFX 6 November 15, 2004 15:55


All times are GMT -4. The time now is 17:00.