[farbfilm]

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

[Daniele111]

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

[maddalena]

Originally Posted by farbfilm

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 http://www.cfd-online.com/Forums/ope...ues-ks-cs.html). 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

[uea]

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!

[andrea.pasquali]

Hi All,
I found same problems with OF 2.0.x.
Here my post: http://www.cfd-online.com/Forums/ope...l-of2-0-x.html
(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: http://www.cfd-online.com/Forums/ope...-profiles.html
that this problem is fixed in 1.7.x.
Has the problem came back in 2.0.x?

Thanks for any help

Andrea

[Nijs Jan Duijm]

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?

[safre]

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

[Nijs Jan Duijm]

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

[nlc]

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

[safre]

This works fine - thank you!

Best regards, Sam

[nlc]

God to know !

Doxygen is your friend in OpenFOAM



Regards

[ancsa]

Hello,

I am also trying to use the fixedShearStress BC on the top but I either get a blown up simulation:

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

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:

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

[cheeba]

I have the exact same problem Aniko. Any resolution?

Thanks,
David

[nlc]

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.

[ancsa]

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:

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:

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

[cheeba]

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

[nlc]

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

[Tibo99]

Hi everyone!

I read your post and I think I got similar issue with the simulation that I try to perform.

I used the ABL inlet condition for U,k and e. Use nutkAtm......, epsilonWallFunction and kqRWallFunction for the bottom wall boundary condition.

The U profile at the Inlet match the U profile at the Outlet, but I got this spike on the k profile at the Outlet near the wall(see image). The mesh is equally spaced(dy=1mm) and the spike seem to appear before the mesh grid (see image).

Do you have any ideas what could cause this issue?

Don't hesitate if you need more information and clarification.

Thank!


P.S.: Just keep in mind that if the shape of the k profile doesn't seem to look right at mid height, it's because this come from a solution that wasn't converge. But, I assure you, this spike is still there even though the solution is converge.

k.jpg

Zoom-k.jpg

[nlc]

If you are doing ABL a spike in k on the second and third cell is expected beacose of a big y+ this as been reported in the literature. One PhD student was working on that while I was doing my masters degree.

You can look at my masters degree at university type in Google (ETS Nicolas Lussier-Clement) you will find it. Look at it I discusse it and make a reference to a log approach this Doctor develop.

Regards
NLC

[Tibo99]

Hi Nic!

Thank you very much for your quick reply! From what I've seen on this thread and how you were handle the subject....I was hoping that you would answer my post.....

Thank for confirming about the spike. Since dy=0.001m, the first cell is at Y+=52, but the first little spike that I refer to seem to happen at the 1st cell.

But, one of the main thing that I'm concern regarding this result is......the shape/curve for k is the opposite of what I think I should have.

Usually, the value increase for ''k'' (as I saw in the literature and like you mention) and then decrease in order to coming back around the value calculated at the Inlet.

If you look again at the image I provided, my result decrease instead. The curve seem to be inverted...?

I have no clue what going wrong.....

From the best of my knowledge, the BC seems fine (2D simulation).

The text file in attachment give the complete description of the BC used and the general information about the mesh and the ABL profile.

For epsilon at the wall, I modify the the formula "epsilon" and the "G" term in the "epsilonWallFunction" function in order to take in account the term "z0" and recompile openFoam (see equation 11 & 13: https://www.sciencedirect.com/scienc...6761050600136X).


Thanks for the reference about the thesis, I'll take a look for sure! I read a paper from the ETS about the subject : https://onlinelibrary.wiley.com/doi/....1002/fld.2709.

Best Regards ami du Québec!

RT