[marc.immer]

Ali,
Just compile the BC separately without the script. There are no inter dependencies between the codes included in the package.

References are:
Klein, M., Sadiki, a., & Janicka, J. (2003). A digital filter based generation of inflow data for spatially developing direct numerical or large eddy simulations. Journal of Computational Physics, 186(2), 652–665. doi:10.1016/S0021-9991(03)00090-1

Xie, Z.-T., & Castro, I. P. (2008). Efficient Generation of Inflow Conditions for Large Eddy Simulation of Street-Scale Flows. Flow, Turbulence and Combustion, 81(3), 449–470. doi:10.1007/s10494-008-9151-5

[gentela]

Originally Posted by marc.immer

Ali,
Just compile the BC separately without the script. There are no inter dependencies between the codes included in the package.

References are:
Klein, M., Sadiki, a., & Janicka, J. (2003). A digital filter based generation of inflow data for spatially developing direct numerical or large eddy simulations. Journal of Computational Physics, 186(2), 652–665. doi:10.1016/S0021-9991(03)00090-1

Xie, Z.-T., & Castro, I. P. (2008). Efficient Generation of Inflow Conditions for Large Eddy Simulation of Street-Scale Flows. Flow, Turbulence and Combustion, 81(3), 449–470. doi:10.1007/s10494-008-9151-5

Great! I will give it a try after this weekend and let you know about the results i get. Thanks a lot for references too

[Uyan]

I think replacing

#!/bin/sh by #!/bin/bash

in Allwmake script, the unexpected '(' error can be avoided.

[AlexanderMath]

Hello guys. I have been struggling with this for three days now and I thought I should give you the end product so that nobody else has to end up in my shoes. I am using OpenFoam2.3.1 (I also tried it with OpenFoam 2.3.0). It's 1.1 MB so it's too big to attach, you can get the inflowgenerator here from my dropbox.

[gentela]

Hey Alex!
Could you please elaborate more on this? Have you made any development to this boundary condition? I just don't know what your problem was?
Thanks;
Ali

Originally Posted by AlexanderMath

Hello guys. I have been struggling with this for three days now and I thought I should give you the end product so that nobody else has to end up in my shoes. I am using OpenFoam2.3.1 (I also tried it with OpenFoam 2.3.0). It's 1.1 MB so it's too big to attach, you can get the inflowgenerator here from my dropbox.

[gentela]

Hey Marc,
I have finally decided to use your inflow generator as my BC. So, is this the only publication that needs to be cited? Also, one last question about it. How do you define the L file for your velocity profiles? Can you explain more about it?

Thanks!

Originally Posted by marc.immer

Ali,
Just compile the BC separately without the script. There are no inter dependencies between the codes included in the package.

References are:
Klein, M., Sadiki, a., & Janicka, J. (2003). A digital filter based generation of inflow data for spatially developing direct numerical or large eddy simulations. Journal of Computational Physics, 186(2), 652–665. doi:10.1016/S0021-9991(03)00090-1

Xie, Z.-T., & Castro, I. P. (2008). Efficient Generation of Inflow Conditions for Large Eddy Simulation of Street-Scale Flows. Flow, Turbulence and Combustion, 81(3), 449–470. doi:10.1007/s10494-008-9151-5

[openfoammaofnepo]

Dear Matthias,

For the boundary condition of "inflowGenerator", is there the corresponding version for OpenFOAM 3.0.0? Thank you.

Originally Posted by matthias

Dear Syavash,

as long as you don't need the turbulence models in the library you can ignore these errors. The library seems to be correctly build.

There are some missing dependencies in the original turbulence models class of OpenFOAM. I have to modify the applyPatches to add these dependencies but this needs some time. I will do it till end of the week.


Best

Matthias

[Alish1984]

Originally Posted by Dan1788

Hello,

I had a question. Since RField is the reynolds stress field and the turbulent intensity is sqrt(normal reynolds stress), should the value of RField (0.01 0 0 0.01 0 0.01) be reasonable ? That ways the intensity is 10% in all directions.

Is my thinking correct ?

if your U=1, then this is correct.
I have not checked the code but in principal RField for HIT must be a matrix with diagonals equal to <(u*intensity)^2>

[Alish1984]

Originally Posted by hannes

Dear amanbearpig,

when you look at velocity magnitude after the first few timesteps it looks indeed like there are no fluctuations generated (first image). Although when you take a look at U_Z, you see that they are there but very small.
At a later timestep, the fluctuations reach their full magnitude (third image, haven't checked, if the values are reasonably prescribed here).

The generated raw fluctuations have an amplitude that depends on the length scale and the spot internal velocity distribution. For reproduction of precribed Reynolds stresses, the raw fluctuation need to be normalized by this a priori unknown factor. In the current implementation, the scaling factor is determined by some online adaption of the statistics. Thus it takes a number of timesteps until the fluctuations are right.

Currently, we have a heavily improved version of the inflow generator, which is not only capable of generating divergence-free fluctuations with almost arbitrary anisotropy but also determined the scaling factor in an analytical way in advance, so this nasty adaption time has been removed.
But before releasing it, we want to check it and publish results first...

Regards, Hannes

Dear Hannes and Matthias,

The last released code is for OF2.4.x,
A question:
Does it still needs time to be correlated in time? I mean the generated raw fluctuations.
And what about space? Does it need an extended input length to be correlated in space? I guess this feature is already satisfied.

Best

[tiam]

Hello everyone!

I am wondering how does the new divergence-free SEM ,method in the newest +release of OF correlate to the latest work in LEMOS.
What Hannes presented in the OF-workshop this week looked very similar to what is described in the release statement, at least to a non-expert .

Best,
Timofey

[hannes]

Dear Timofey,

the DFSEM is a parallel development to our inflow generator. Although the basic idea is in principle the same, the differences are in the velocity distribution inside the spots (or synthetic eddies).

From the latest paper that I'm aware of, I remember that there were some severe restrictions in the realizable ansiotropy of the DFSEM-generated turbulence.

But I just got the code and I will take a deeper look now.

Regards, Hannes

[pappo1890]

Hi Guys,

I am trying to understand the meaning of few things about the turbulent inflow generator. in the source file:

for (label k = 0; k < nVortexes_; k++)
{
vector v
(
(direction_ > 0) ? x - ls : x + ls,
ymin + rndGen_.scalar01()*2*L[I],
zmin + rndGen_.scalar01()*2*L[I]
);

bool allowed = true;

nVortexes represent the number of spots allocated in the patch where the turbulence is applied?


Thanks in advance

[moh-farmani]

Dear Foamers,
I want to install LEMOS-Rostock-2.4.x in OF 2.4.0:
https://github.com/LEMOS-Rostock/LEMOS-2.4.x
I took the following steps as in the README.md file:

1. move the Folder "LEMOS-2.4.x" into $FOAM_SRC
2. add the following line to your ~/.bashrc after ". ~/OpenFOAM/OpenFOAM-2.4.x/etc/bashrc": . $FOAM_SRC/LEMOS-2.4.x/bashrc
3. parse your ~/.bashrc or open a new terminal
4. Execute applyPatches to install patches in $FOAM_SRC folder
5. Execute $LEMOSEXT/Allwmake to build the library and executables

But in the 5th step, I have encountered the following error messages:

apadana@apadana-To-be-filled-by-O-E-M:/opt/openfoam240/src/LEMOS-2.4.x$ ./Allwmake 
+ wmake libso libLEMOS-2.4.x
'/opt/openfoam240/platforms/linux64GccDPOpt/lib/libLEMOS-2.4.x.so' is up to date.
+ cd applications
+ wmake all solvers
make[1]: Entering directory `/opt/openfoam240/src/LEMOS-2.4.x/applications/solvers/basic'
make[2]: Entering directory `/opt/openfoam240/src/LEMOS-2.4.x/applications/solvers/basic/PODSolver'
SOURCE=PODSolver.C ;  g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3  -DNoRepository -ftemplate-depth-100 -I/libLEMOS-2.4.x/lnInclude -I/opt/openfoam240/src/finiteVolume/lnInclude -I/opt/openfoam240/src/meshTools/lnInclude  -IlnInclude -I. -I/opt/openfoam240/src/OpenFOAM/lnInclude -I/opt/openfoam240/src/OSspecific/POSIX/lnInclude   -fPIC -c $SOURCE -o Make/linux64GccDPOpt/PODSolver.o
PODSolver.C:35:20: fatal error: PODODE.H: No such file or directory
 #include "PODODE.H"
                    ^
compilation terminated.
make[2]: *** [Make/linux64GccDPOpt/PODSolver.o] Error 1
make[2]: Target `/opt/openfoam240/platforms/linux64GccDPOpt/bin/PODSolver' not remade because of errors.
make[2]: Leaving directory `/opt/openfoam240/src/LEMOS-2.4.x/applications/solvers/basic/PODSolver'
make[1]: *** [PODSolver] Error 2
make[1]: Target `application' not remade because of errors.
make[1]: Leaving directory `/opt/openfoam240/src/LEMOS-2.4.x/applications/solvers/basic'
make: *** [basic] Error 2
make[1]: Entering directory `/opt/openfoam240/src/LEMOS-2.4.x/applications/solvers/scalarPimpleFoam'
g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3  -DNoRepository -ftemplate-depth-100 -I/opt/openfoam240/src/turbulenceModels/incompressible/turbulenceModel -I/opt/openfoam240/src/transportModels -I/opt/openfoam240/src/transportModels/incompressible/singlePhaseTransportModel -I/opt/openfoam240/src/turbulenceModels/LES/LESfilters/lnInclude -I/opt/openfoam240/src/finiteVolume/lnInclude -I/opt/openfoam240/src/meshTools/lnInclude -I/opt/openfoam240/src/fvOptions/lnInclude -I/opt/openfoam240/src/sampling/lnInclude -IlnInclude -I. -I/opt/openfoam240/src/OpenFOAM/lnInclude -I/opt/openfoam240/src/OSspecific/POSIX/lnInclude   -fPIC -Xlinker --add-needed -Xlinker --no-as-needed Make/linux64GccDPOpt/scalarPimpleFoam.o -L/opt/openfoam240/platforms/linux64GccDPOpt/lib \
         -lincompressibleTransportModels -lincompressibleTurbulenceModel -lincompressibleRASModels -lincompressibleLESModels -lfiniteVolume -lmeshTools -lLESfilters -lfvOptions -lsampling -lOpenFOAM -ldl   -lm -o /opt/openfoam240/platforms/linux64GccDPOpt/bin/scalarPimpleFoam
/usr/bin/ld: cannot open output file /opt/openfoam240/platforms/linux64GccDPOpt/bin/scalarPimpleFoam: Permission denied
collect2: error: ld returned 1 exit status
make[1]: *** [/opt/openfoam240/platforms/linux64GccDPOpt/bin/scalarPimpleFoam] Error 1
make[1]: Leaving directory `/opt/openfoam240/src/LEMOS-2.4.x/applications/solvers/scalarPimpleFoam'
make: *** [scalarPimpleFoam] Error 2
make: Target `application' not remade because of errors.
+ cd applications
+ wmake all utilities
make[1]: Entering directory `/opt/openfoam240/src/LEMOS-2.4.x/applications/utilities/postProcessing'
make[2]: Entering directory `/opt/openfoam240/src/LEMOS-2.4.x/applications/utilities/postProcessing/POD'
make[3]: Entering directory `/opt/openfoam240/src/LEMOS-2.4.x/applications/utilities/postProcessing/POD/scalarSnapshots'
SOURCE=scalarSnapshots.C ;  g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3  -DNoRepository -ftemplate-depth-100 -I/libLEMOS-2.4.x/lnInclude -I/opt/openfoam240/src/finiteVolume/lnInclude -I/opt/openfoam240/src/meshTools/lnInclude -IlnInclude -I. -I/opt/openfoam240/src/OpenFOAM/lnInclude -I/opt/openfoam240/src/OSspecific/POSIX/lnInclude   -fPIC -c $SOURCE -o Make/linux64GccDPOpt/scalarSnapshots.o
scalarSnapshots.C:37:33: fatal error: PODOrthoNormalBases.H: No such file or directory
 #include "PODOrthoNormalBases.H"
                                 ^
compilation terminated.
make[3]: *** [Make/linux64GccDPOpt/scalarSnapshots.o] Error 1
make[3]: Target `/opt/openfoam240/platforms/linux64GccDPOpt/bin/scalarSnapshots' not remade because of errors.
make[3]: Leaving directory `/opt/openfoam240/src/LEMOS-2.4.x/applications/utilities/postProcessing/POD/scalarSnapshots'
make[2]: *** [scalarSnapshots] Error 2
make[3]: Entering directory `/opt/openfoam240/src/LEMOS-2.4.x/applications/utilities/postProcessing/POD/vectorSnapshots'
SOURCE=vectorSnapshots.C ;  g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3  -DNoRepository -ftemplate-depth-100 -I/libLEMOS-2.4.x/lnInclude -I/opt/openfoam240/src/finiteVolume/lnInclude -I/opt/openfoam240/src/meshTools/lnInclude -IlnInclude -I. -I/opt/openfoam240/src/OpenFOAM/lnInclude -I/opt/openfoam240/src/OSspecific/POSIX/lnInclude   -fPIC -c $SOURCE -o Make/linux64GccDPOpt/vectorSnapshots.o
vectorSnapshots.C:37:33: fatal error: PODOrthoNormalBases.H: No such file or directory
 #include "PODOrthoNormalBases.H"
                                 ^
compilation terminated.
make[3]: *** [Make/linux64GccDPOpt/vectorSnapshots.o] Error 1
make[3]: Target `/opt/openfoam240/platforms/linux64GccDPOpt/bin/vectorSnapshots' not remade because of errors.
make[3]: Leaving directory `/opt/openfoam240/src/LEMOS-2.4.x/applications/utilities/postProcessing/POD/vectorSnapshots'
make[2]: *** [vectorSnapshots] Error 2
make[2]: Target `application' not remade because of errors.
make[2]: Leaving directory `/opt/openfoam240/src/LEMOS-2.4.x/applications/utilities/postProcessing/POD'
make[1]: *** [POD] Error 2
make[2]: Entering directory `/opt/openfoam240/src/LEMOS-2.4.x/applications/utilities/postProcessing/miscellaneous'
make[3]: Entering directory `/opt/openfoam240/src/LEMOS-2.4.x/applications/utilities/postProcessing/miscellaneous/postChannelExt'
SOURCE=postChannelExt.C ;  g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3  -DNoRepository -ftemplate-depth-100 -I/opt/openfoam240/src/meshTools/lnInclude -I/opt/openfoam240/src/finiteVolume/lnInclude -I/opt/openfoam240/src/sampling/lnInclude -I/OpenFOAM/primitives/Triple -IlnInclude -I. -I/opt/openfoam240/src/OpenFOAM/lnInclude -I/opt/openfoam240/src/OSspecific/POSIX/lnInclude   -fPIC -c $SOURCE -o Make/linux64GccDPOpt/postChannelExt.o
postChannelExt.C:38:20: fatal error: Triple.H: No such file or directory
 #include "Triple.H"
                    ^
compilation terminated.
make[3]: *** [Make/linux64GccDPOpt/postChannelExt.o] Error 1
make[3]: Target `/opt/openfoam240/platforms/linux64GccDPOpt/bin/postChannelExt' not remade because of errors.
make[3]: Leaving directory `/opt/openfoam240/src/LEMOS-2.4.x/applications/utilities/postProcessing/miscellaneous/postChannelExt'
make[2]: *** [postChannelExt] Error 2
make[2]: Target `application' not remade because of errors.
make[2]: Leaving directory `/opt/openfoam240/src/LEMOS-2.4.x/applications/utilities/postProcessing/miscellaneous'
make[1]: *** [miscellaneous] Error 2
make[2]: Entering directory `/opt/openfoam240/src/LEMOS-2.4.x/applications/utilities/postProcessing/velocityField'
make[3]: Entering directory `/opt/openfoam240/src/LEMOS-2.4.x/applications/utilities/postProcessing/velocityField/LambdaCI'
g++ -m64 -Dlinux64 -DWM_DP -Wall -Wextra -Wno-unused-parameter -Wold-style-cast -Wnon-virtual-dtor -O3  -DNoRepository -ftemplate-depth-100 -I/opt/openfoam240/src/postProcessing/postCalc -I/opt/openfoam240/src/finiteVolume/lnInclude -I/opt/openfoam240/src/meshTools/lnInclude -IlnInclude -I. -I/opt/openfoam240/src/OpenFOAM/lnInclude -I/opt/openfoam240/src/OSspecific/POSIX/lnInclude   -fPIC -Xlinker --add-needed -Xlinker --no-as-needed Make/linux64GccDPOpt/LambdaCI.o -L/opt/openfoam240/platforms/linux64GccDPOpt/lib \
         /opt/openfoam240/platforms/linux64GccDPOpt/lib/postCalc.o -lfiniteVolume -lmeshTools -lgenericPatchFields -lOpenFOAM -ldl   -lm -o /opt/openfoam240/platforms/linux64GccDPOpt/bin/LambdaCI
/usr/bin/ld: cannot open output file /opt/openfoam240/platforms/linux64GccDPOpt/bin/LambdaCI: Permission denied
collect2: error: ld returned 1 exit status
make[3]: *** [/opt/openfoam240/platforms/linux64GccDPOpt/bin/LambdaCI] Error 1
make[3]: Leaving directory `/opt/openfoam240/src/LEMOS-2.4.x/applications/utilities/postProcessing/velocityField/LambdaCI'
make[2]: *** [LambdaCI] Error 2
make[2]: Target `application' not remade because of errors.
make[2]: Leaving directory `/opt/openfoam240/src/LEMOS-2.4.x/applications/utilities/postProcessing/velocityField'
make[1]: *** [velocityField] Error 2
make[1]: Target `application' not remade because of errors.
make[1]: Leaving directory `/opt/openfoam240/src/LEMOS-2.4.x/applications/utilities/postProcessing'
make: *** [postProcessing] Error 2
make: Target `application' not remade because of errors.

How can i fix the errors?
Any help will be appreciated.

[xuhuang]

Originally Posted by marc.immer

I wrote a small bash script to remove the vortons from the U file. It also creates a backup copy of U:

cp $1 $1.bak
rm $1
sed '/vortons/,/;/d' $1.bak > $1

start like this:
./removeVortons "pathToUFile", e.g. "10/U"

Regards
Marc

Hi Marc,

I am also working with LEMOS inflow generator. Your script works fine. But I have another problem. When I run my case in parallel, the velocity data written is not correct, for example, refField becomes a scalar list. It seems this happens when running decomposePar. Do you have any idea about this? I am using version OF-2.3.x.

Thank you.

Cheers,

Xu

[xuhuang]

Originally Posted by hannes

Dear Timofey,

the DFSEM is a parallel development to our inflow generator. Although the basic idea is in principle the same, the differences are in the velocity distribution inside the spots (or synthetic eddies).

From the latest paper that I'm aware of, I remember that there were some severe restrictions in the realizable ansiotropy of the DFSEM-generated turbulence.

But I just got the code and I will take a deeper look now.

Regards, Hannes

Hi Hannes,

I also your post, do you know how to solve this? I am using version OF-2.3.x.

Thank you.

Regards,

Xu

[xuhuang]

I am sorry for this repeating replies. It seems I made a mess between threads. I cannot delete this post.
Sorry.

Cheers,
Xu

[cryabroad]

I've read all the above threads and the corresponding papers. I complied this BC in OF-4.x without any problem (cheers), and I'm testing it using a simple pipe flow(with 7.2mm diameter and 50mm length) with the Smagorinsky model.

The fluctuations at the velocity-inlet are fine at all instances (random and quite visible), but they die out pretty quickly downstream. At about 20mm (40% length), the axial velocity becomes flat in the middle section of the pipe. Any ideas how this can be fixed? Right now I'm using ~120,000 cells and my intention is to limit this number under ~300,000. I heard that the cell size in the axial direction matters the most and they should be relatively small, is this correct?

[abhi22]

Hi Ruiyan,

Based on the dimensions you've provided for the pipe and the total number of cells, it looks like the grid may not be the issue. However, do check your grid, since LES is very sensitive to the cell aspect ratio. High aspect ratio cells near the wall will definitely cause perturbations to die out.

I believe it's to do with the SGS model you are using. The Smagorinsky model is dissipative. Try using a dynamic model, for instance, the Dynamic kEquation Model in OF4x.

This is what I have found in literature about the limitations of Smagorinsky model:

The Smagorinsky model is based on the assumption that the small scales are in equilibrium and dissipate entirely and instantaneously the energy they receive from the large scales (see Turbulent Energy Cascade). However, due to its overly dissipative limitation, i.e. the excessive extraction of energy from the large scales, the perturbations/disturbances tend to die out. Likewise, in the case of laminar-turbulent transition, the Smagorinsky model fails to differentiate between laminar and turbulent flows, and therefore the turbulent eddy viscosity remains active throughout the whole domain. This causes the linear disturbances to decay prior
to transition and the transition location is not predicted accurately.

[cryabroad]

Hi Abhi,

Thank you for reading my post. You may be right, I tried the same grid with Smagorinsky model in ANSYS Fluent and the perturbation also die out quickly downstream. I will further improve my mesh and test it using different SGS model as you suggested.

About the cell aspect ratio, is there an optimal value (or just a rule of a thumb) you recommend? I think most meshing softwares use a value around 1.20.

[cryabroad]

Hi Abhi,

I have improved my grid and it seems everything is working fine. The grid is not the crucial part (at least in my case), what I found is that Smagorinsky + vanDriest/Prandtl delta function provides much better results (good perturbations downstream). I think the reasons are as following:

In Smagorinsky model, the SGS viscosity is calculated by nu_sgs = Ck*sqrt(K_sgs)*delta, with Ck being the Smagorinsky constant, K_sgs being the SGS kinetic energy, and delta being some kind of length. According to the vanDriest/Prandtl delta in OF, this delta is chosen as the minimum of two lengths: a length that is associated with the distance to the wall, and the geometric length (filter size, normally cellVolume^1/3). Therefore, close to the wall the delta approaches the distance to the wall but far from the wall the delta approaches the geometric length. Note that, without using vanDriest/Prandtl delta, the delta will be just the geometric length, which is overrated in the near-wall region. I think this causes the small-scale turbulence to die out very quickly and eventually causes the large-scale turbulence to die out downstream as well.

What do you guys think about the above arguments? Am I on the right track?