[ssa_cfd]

I found the problem. I had to give the boundary data for the whole height of the inlet patch, starting from zero to the maximum height.

Now it works.

[Linanik]

Hi everyone,

I am interested in using the turbulentDFSEMInlet condition as inlet velocity boundary condition for my LES simulation.

Since I have no experimental data at the inlet, I am generating the necessary boundaryData file from a RANS simulation.

My question is how can I generate the L data? I know I can do sth like:

inlet 
{
...
 L uniform 0; 
 nCellsPerEddy 3
...
}

but is there a way to generate this data from a RANS simulation as well? Did anyone do this?

I am using OF v.1812

Kind regards,
Lina

[mAlletto]

you have to provide a file with the name L in the same folder as you store U and R. The format is the same but of course L is a scalar. You can find an example in tutorials/incompressible/pimpleFoam/LES/channel395DFSEM

You can use the turbulent length scale computed from RANS. This quantity of course depends on the turbulent model you use.

For a k-epsilon model you find the formula here https://www.cfd-online.com/Wiki/Turbulence_length_scale

[Linanik]

Hi Michael,

Thanks for your response. Yes I am trying to generate R,U, and L files for my case, like these available in the tutorials/incompressible/pimpleFoam/LES/channel395DFSEM.

In my RANS simulation, I am storing UMean (for U file) and UPrime2Mean (for R file) data in a patch, to be used as inlet data in my LES simulation.

Do you know how I can generate in the same time the turbulent length scale data in the same patch? Is there a field for that? Or should I define the equation I want (in accordance with my turbulence model) somewhere?


Kind regards,
Lina

[mAlletto]

In the turbulence model I used (k-epsilon and k-omegaSST) there is no field stored for the turbulent length scale. What I did is to read k end epsilon from the text file stored by OF and convert it in a small python script manually to the files desired. It is not a lot of work.

There may be other more elegant solutions of course.


Best

Michael

[Linanik]

Hi Everyone,

Any update regarding the error in this boundary condition leading to very high velocities? Any suggestion on how to solve it? I encountered this error too and found similar problematic results as reported previously in this thread.

Kind regards,
Lina

[mAlletto]

Unfortunately not but there is a new synthetic turbulence boundary condition available in the newest OF version:

https://www.openfoam.com/releases/op...digital-filter

[zeinelserfy]

is there any updates about high velocity at the inlet compared to the mean velocity ??

Have anyone tried the new inlet boundary condition (digital filter)?

[Tibo99]

I everyone!

I came across this thread and and I relate to the same issue about the ''turbulentDFSEMInlet'' Inlet type.

First issue, I got higher velocity value at the Inlet compare of what my data are in the ''U'' file (see picture and text file in attachment for comparison). I notice that the value look fine at the left corner of the domain but don't spread correctly on the Inlet surface? Even though the data for the whole Inlet surface is provided in the ''U'' file.

Second issue, if I use the file I created in the directory /constant/boundaryData/Inlet/0, it doesn't work. Still try to figured out how many row (strings) the file need to match the Inlet cells. I looked the tutorial's files, tried several options, and it's still don't work if I use this way to map the Inlet field. How you figured this out ssa_cfd? Did you get the same issue about higher velocity afterward?

I did try the new ''turbulentDigitalFilter'' type, but I wasn't able to know if I would got the same issue about the velocity at the Inlet since I got the same issue using the file in the /constant directory.

Anyone can help?

Thank you very much!

Best Regards,

[Gang Wang]

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?

Hi Mahdi!

I'm also using this inlet Boundary conditions, and i just noticed that you have specified the Reynolds stress explicitly in every component. I'm wondering how did you get these values? Do you have an emplical formula? Or just use k as Reynolds stress, like we used in RANS.

Best regards,
Gang Wang

[mAlletto]

There is a postprocessing utility in OF which calculates R.

[HPE]

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

It was a bug in the eigendecomposition engine (the bug was not inside the DFSEM). If you can use the develop branch, the hanging will go away, since the bug-fix is in the develop-branch at the time of writing.

[Gang Wang]

Originally Posted by mAlletto

There is a postprocessing utility in OF which calculates R.

But how did you calculate R at the inlet boundary before you run your simulation?

Best,
Gang

[Gang Wang]

Originally Posted by mAlletto

There is a postprocessing utility in OF which calculates R.

Now I know, I have to prepare the boundaryData directory for turbulentDFSEMInlet. Sorry for that!

Best,
Gang

[mAlletto]

I run a channel sì.ulation with a k epsilon model and extracted the data from that

[zahraseif]

Hello,

I am trying to understand the input parameters of DFSEM in OpenFOAM, according to the original model development in the paper by Polleto et al. (2013). I am not quite sure about my understanding and I appreciate any comments about my concerns.

As much as I was able to comprehend, there are certain input parameters in OpenFOAM as R, L, U, delta, nCellsPerEddy and mapMethod. My questions are:

• Does delta value correspond to the value of Ω in the paper which is the user inlet surface selection? Or this is only to limit the eddy length scales?

• In the OpenFOAM implementation of the model, it seems that the method is limited by the number of mesh cells per eddy. Is this an issue in the original model as well? I mean the value of the N in the paper, should be defined based on the number of cells at the inlet surface?

• My next question is, if we provide one value for L, how the code understand swhich axis is that to calculate the length scales at other axes?

• I am not quite sure about how the model uses the Reynolds stress field to generate inlet fluctuations according to the equations in the paper. Can somebody more elaborate on that?

• By using the 3 and 5 values for nCellsPerEddy for the channel flow LES calculation at friction Reynolds number of 395, I got worse results for the downstream development of the <U> and <u’u’>. I attached my results. It seems to me that there should be an optimum value for this parameter for each mesh. I would appreciate comments about this issue.

Thank you very much,
Kind regards

Zahra

U.jpg

uu.jpg

[RaulCA]

Originally Posted by zahraseif

Hello,

I am trying to understand the input parameters of DFSEM in OpenFOAM, according to the original model development in the paper by Polleto et al. (2013). I am not quite sure about my understanding and I appreciate any comments about my concerns.

As much as I was able to comprehend, there are certain input parameters in OpenFOAM as R, L, U, delta, nCellsPerEddy and mapMethod. My questions are:

•Does delta value correspond to the value of Ω in the paper which is the user inlet surface selection? Or this is only to limit the eddy length scales?

•In the OpenFOAM implementation of the model, it seems that the method is limited by the number of mesh cells per eddy. Is this an issue in the original model as well? I mean the value of the N in the paper, should be defined based on the number of cells at the inlet surface?

•My next question is, if we provide one value for L, how the code understand swhich axis is that to calculate the length scales at other axes?

•I am not quite sure about how the model uses the Reynolds stress field to generate inlet fluctuations according to the equations in the paper. Can somebody more elaborate on that?

•By using the 3 and 5 values for nCellsPerEddy for the channel flow LES calculation at friction Reynolds number of 395, I got worse results for the downstream development of the <U> and <u’u’>. I attached my results. It seems to me that there should be an optimum value for this parameter for each mesh. I would appreciate comments about this issue.

Thank you very much,
Kind regards

Zahra

Attachment 75840

Attachment 75841

Hi zahra,
I'm also trying to understand better this BC.
From the paper you can see that the turbulent length scale is bounded by the channel height multiplied by the von karman constant. In the DFSEM BC delta is the value used to limit the length scale. It corresponds to the channel height in the paper, but you can adjust it depending on your case.
I understand that the nCellsPerEddy variable is just meant to impose a lower bound to the length scale to create only eddies that can be advected downwind. It will only change the eddies parameters when your mesh is too coarse to resolve the prescribed length scale, otherwise it shouldn't have an effect on the simulation.

Regards
Raul

[stardust23]

Are there updates about this BC? Is it reliable/usable or are there still issues related with too high velocity fluctuations?

[zahraseif]

Originally Posted by RaulCA

Hi zahra,
I'm also trying to understand better this BC.
From the paper you can see that the turbulent length scale is bounded by the channel height multiplied by the von karman constant. In the DFSEM BC delta is the value used to limit the length scale. It corresponds to the channel height in the paper, but you can adjust it depending on your case.
I understand that the nCellsPerEddy variable is just meant to impose a lower bound to the length scale to create only eddies that can be advected downwind. It will only change the eddies parameters when your mesh is too coarse to resolve the prescribed length scale, otherwise it shouldn't have an effect on the simulation.

Regards
Raul

Hi Raul,

Thank you for your feedback. To me, it seems that nCellsPerEddy should be a parameter to control the eddy density parameter mentioned in the paper (d), but it seems that in OpenFOAM implementation we only have this parameter to control the eddy density. It is not very straightforward to understand although. I hope we can get more into this BC through this forum.

Regards,

Zahra

[zahraseif]

Originally Posted by stardust23

Are there updates about this BC? Is it reliable/usable or are there still issues related with too high velocity fluctuations?

Hi,

I got almost validated and verified results with this BC.

Regards,

Zahra