[anishtain4]

Hi,

I've recently installed the OF 1606 in the hope to use the divergent free boundary condition and get a reasonable pressure field at the inlet.
When I set a boundary layer case to solve, it runs up to first pimple iteration and doesn't go any further. I've increased the allocated ram but that doesn't seem to be the issue. My case runs well with turbulentInlet with following options:

    inlet
    {
        type            turbulentInlet;
        fluctuationScale (0.14 0.05 0.05);
        alpha           0.05;
        referenceField  uniform (7.72 0 0);
        value           uniform (7.72 0 0);
    }

However doesn't produce useful pressure field. But this options fial:

    inlet
    {
        type        turbulentDFSEMInlet;
        delta       0.20;
        R           uniform (0.5 0.1 0.1 0.03 0.01 0.01);
        U           uniform (7.75 0 0);
        L           uniform 0.00;
        value       uniform (7.75 0 0);
        nCellsPerEddy 3;
        mapMethod   nearestCell;
    }

The boundary layer should be 0.0115m thick, the top wall (symmetric) is 0.4m away.

Also if anyone can give me a hint on how to export L from another simulation I would appreciate it. If I've understood well it's epsilon/k, and the first thing comes into mind is to use foamCalc and a k-epsilon solution, but foamCalc does not include division, should I go ahead and hard code it?

[Hillie]

Hi Mahdi,

Did you end of solving this problem properly? If you haven't could you try running the code in serial? My case seems to work in serial model, but not in parallel?

Cheers,
Hilbert

[Hillie]

Dear Foamers,

I just want to expand on my previous post to see if anybody has some idea's since I am running out.

I am trying to run a case with the turbulentDFSEMInlet as my velocity inlet.

Now I have asses to a cluster which is running V1606 and my workstation which is running V1612.
When I try to run the case in parallel on the cluster it hangs on the turbulentDFSEMInlet when it tried to seed eddies into the flow. I get the following output.

Reading field U

Turbulent DFSEM patch inlet: interpolating field R from "/short/fd8/hvp561/OpenFoam/LES/M20I7/V35/processor0/../constant/boundaryData/inlet/0"
Turbulent DFSEM patch inlet: interpolating field L from "/short/fd8/hvp561/OpenFoam/LES/M20I7/V35/processor0/../constant/boundaryData/inlet/0"
Turbulent DFSEM patch inlet: interpolating field U from "/short/fd8/hvp561/OpenFoam/LES/M20I7/V35/processor0/../constant/boundaryData/inlet/0"
Creating turbulence model

Selecting turbulence model type LES
Selecting LES turbulence model WALE
Selecting LES delta type cubeRootVol
WALECoeffs
{
Ce 1.048;
Ck 0.094;
Cw 0.325;
}

No finite volume options present

fluxScheme: Kurganov

Starting time loop

Mean and max Courant Numbers = 0.00927962091699481 0.0759951601114363
deltaT = 1.25e-09
Time = 0.0119072264273089

diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
diagonal: Solving for rhoUx, Initial residual = 0, Final residual = 0, No Iterations 0
diagonal: Solving for rhoUy, Initial residual = 0, Final residual = 0, No Iterations 0
diagonal: Solving for rhoUz, Initial residual = 0, Final residual = 0, No Iterations 0
Turbulent DFSEM patch: inlet seeded 193 eddies with total volume 3.13745594498e-08

When I run the case in serial model on the cluster it does run though.

When I run the case in parallel on my workstation it also hangs. The example for this inlet :

$FOAM_TUTORIALS/incompressible/pimpleFoam/channel395DFSEM, Does run in parallel though.


Because it runs in serial model it would suggest that I have set the case up correctly, but the fact that it hangs in parallel mode, while the example does run in parallel model would suggest that there is something case specific going on.

Does anybody have idea idea's / things I could test since I am running out of idea's?

[liquidspoon]

Hope this reply isn't too late...

I have been trying to use this boundary condition as well, and am running into the same issue (works in serial, hangs in parallel). The culprit is the following line in the BC:

 
scalar fCorr =
    gSum((UMean_ & patchNormal_)*patch().magSf())
    /gSum(U & -patch().Sf());

For some reason, this gSum operation fails when only one processor contains the patch. If you set up the decomposeParDict to split the patch over at least two processors, it works.

[shang]

Hey Alex,

I am encountering the same problem. But this BC neither works on parallel nor serial case for me. Same with Mahdi, it runs up to first pimple iteration and doesn't go any further, even though I split the patch in 2.

Do you have any idea on how to solve it?

Kind regards,
Yeru

[Hillie]

Hey Yeru,


Just a question, how big is your domain? I was doing some more testing with this boundary condition(in serial) and I noticed something interesting.
If you take the standard tutorial for the BC (which is a channel flow with a dimension in the order of meters) and you change the dimension to mm it does not work.



It would suggest there is a critical size under which the BC struggles.


Cheers,
Hilbert

[mAlletto]

Hello everybody.

I did my first runs with the turbulentDFSEMInlet boundary conditions. What I found, is when applying realistic levels of turbulence for atmospheric boundary layers (a turbulence intencity TI of about 10%):

type turbulentDFSEMInlet;
delta 4;
nCellPerEddy 2;
mapMethod nearestCell;
value uniform ( 0 0 0 ); // restart value
L uniform 25;
R uniform (0.5 0.1 0.1 0.5 0.01 0.5);

is that the maximum velocities produced by this boundary conditions are ten times higher than the mean wind (is approximately 10m/s). I found this value quit high because it is totally unrealistic.

Did anybody experience the same?

[sylvester]

Hi Michael,

I am also experiencing too high maximum velocities.

I noticed that in $FOAM_INST_DIR/src/finiteVolume/fields/fvPatchFields/derived/turbulentDFSEMInlet/turbulentDFSEMInletFvPatchVectorField.C the code does not follow the reference, thereby allowing larger fluctuations:

        // Allow eddies to be smaller than the mesh scale as suggested by
        // the reference?
        // s = min(s, nCellPerEddy_*cellDx[faceI]);
        s = max(s, nCellPerEddy_*cellDx[faceI]);

This may be the cause of the high velocities, but I did not have the time to investigate further.

Kind regards,
Roland

[sylvester]

Hi,

I checked the difference in results between

s = min(s, nCellPerEddy_*cellDx[faceI]);

and

s = max(s, nCellPerEddy_*cellDx[faceI]);

Although the size of eddies changes, the maximum velocity remains about the same, see attached images.

Kind regards,
Roland

[shang]

Hey Hilbert,

My computational domain is quite small, it has a size of 0.2112*0.02*0.02(m). I have reported it as a bug to the developer, they are asking me to test it on the latest release. I will let you know if the latest version can solve the problem.

Regards,
Yeru

[mAlletto]

Originally Posted by sylvester

Hi,

I checked the difference in results between

s = min(s, nCellPerEddy_*cellDx[faceI]);

and

s = max(s, nCellPerEddy_*cellDx[faceI]);

Although the size of eddies changes, the maximum velocity remains about the same, see attached images.

Kind regards,
Roland

Hello I made a simulation of an atmospheric boundary layer with an log profile as input over a flat plat. Periodic condition in span wise direction and advecitve at top and outuflow. I put the following input condition:

inlet
{
type turbulentDFSEMInlet;
delta 4;
nCellPerEddy 2;
mapMethod nearestCell;
value uniform ( 0 0 0 ); // restart value
L uniform 25;
R uniform (0.05 0.01 0.01 0.05 0.01 0.05);
}

The magnitude of R is 0.42.

Analysing the time averaged Reynolds stress tensor I found that the values close to the inlet are an order of magnitude higher and the solution needs nearly 700m to go down to the value provided by the inflow condition. The figures show a slice normal to the wall (the first two) and a lice in streamwise direction. It can be seen clearly that the magnitude of R in the first 2 cells is an order of magnitude higher than the one specified in the boundary condition and it takes quite long until it goes down. I don't know if it a bug in the code or an inconsistency in the formulation of the boundary condition.

[mAlletto]

What I did now is to compare the results obtained in the tutorial channel395DFSEM provided by openfoam.com and my simulation.

For my simulation the domain is much bigger (2000m high) and in contrast to the channel flow I have a slip boundary condition at the top. It is basically a half channel with a logarithmic inflow profile. The magnitude of the Reynolds stress is constant and the values is around 1.8 m^2/s ^2. So it is in the same order of magnitude as the one for the channel simulation.

The maximum velocities however produced by my simulation are 10 times higher compared to the channel flow simulation.

Find attached the inflow profiles of the channel, a snapshot of the velocity at the inflow of the channel and the same quantities of my simulation.

So since the basic difference between my simulation and the channel is the length scale, maybe I'll investigate further in this direction. Maybe someone has a hint how to lower the maximum velocity fluctuations at the inflow.

[mAlletto]

The next analysis I performed is to compare the velocity field generated at the entrance of the half channel for two different domain sizes. The first domain had an extension of 20000m x 2000m x 2000m in streamwise, spanwise and wall normal direction. The second domain was 20m x 2m x 2m in order to match the dimension provided by the tutorial. The mean velocity profile and the mean R required by the boundary condition were the same for both cases. L I scaled it by a factor of 0.001 in the second case.

Another difference is that I used delta 4; for the bigger domain and
delta 0.2; for the smaller domain in order to have a comparable number of eddies seeded into the domain.

The strange think is that the magnitudes of the maximum velocities differ substantially by almost an order of magnitude.

Find attached the figures. The first figure is the bigger domain and the second the smaller. I have the feeling that something is wrong with the boundary condition.

[mAlletto]

Ok I think I found the error: In Poletto et al they provide in eq. (11) the formula for


I checked the implementation in the source code. This is correct.
The problem is that C1 should be unitles. In eq (11) of poletto et at it is not. the correct formulation should be

In this way the constant is unitless.
The wrong formulation is in line with the observation that by increasing the domain size by a factor of 1000 the maximum velocity increases by 10.

see the documentation of the boundary condition:

https://www.openfoam.com/documentati...8C_source.html

https://www.openfoam.com/documentati...8C_source.html


I'm I wrong?

[DJF]

Any news on the correction of the C1 coefficient? Just did a quick test on OF v1812 and got very high velocities as well.

[mAlletto]

The guys from openfoam.com are in contact with the authors of the paper to clarify the issue.

[DJF]

Thank's for the reply. Any recomendations on similar methods in OF or how to overcome this issue? I'm trying to model the atm BL in OF. In the past I used for this purpose the Vortex Method in Fluent with satisfactory results.

[mAlletto]

you can use the recycling method using the mapped bc of openfoam.

otherwise there is the a syntetic eddy method of lemos available

https://github.com/LEMOS-Rostock/LEMOS-2.4.x

I did not test it so I have no idea how it performs. but there is a thread here were it is discussed.

[ssa_cfd]

Hi,, I have the same problem. It stops at PIMPLE Iteration 1. There is no error nothing.

Is there a solution to this problem.

Thanks. ssa

Originally Posted by anishtain4

Hi,

I've recently installed the OF 1606 in the hope to use the divergent free boundary condition and get a reasonable pressure field at the inlet.
When I set a boundary layer case to solve, it runs up to first pimple iteration and doesn't go any further. I've increased the allocated ram but that doesn't seem to be the issue. My case runs well with turbulentInlet with following options:

    inlet
    {
        type            turbulentInlet;
        fluctuationScale (0.14 0.05 0.05);
        alpha           0.05;
        referenceField  uniform (7.72 0 0);
        value           uniform (7.72 0 0);
    }

However doesn't produce useful pressure field. But this options fial:

    inlet
    {
        type        turbulentDFSEMInlet;
        delta       0.20;
        R           uniform (0.5 0.1 0.1 0.03 0.01 0.01);
        U           uniform (7.75 0 0);
        L           uniform 0.00;
        value       uniform (7.75 0 0);
        nCellsPerEddy 3;
        mapMethod   nearestCell;
    }

The boundary layer should be 0.0115m thick, the top wall (symmetric) is 0.4m away.

Also if anyone can give me a hint on how to export L from another simulation I would appreciate it. If I've understood well it's epsilon/k, and the first thing comes into mind is to use foamCalc and a k-epsilon solution, but foamCalc does not include division, should I go ahead and hard code it?

[mAlletto]

You have to ensure that you have more than one processor at your inlet patch. Then it works.