[openfoammaofnepo]

Thank you very much, I found the Lund transformation in JCP paper. Besides, in the source file (decayingTurbulenceFvPatchVectorField.C), what is the difference between R_ and RField_? Thank you.

[openfoammaofnepo]

Dear Matthias,

Can I ask you another question about the inflowGenerator? In the source file decayingTurbulenceFvPatchVectorField.C, there are following several lines:

    List<scalar> L  = ListListOps::combine<List<scalar> >(l, accessOp<List<scalar> >());
    List<vector> CF = ListListOps::combine<List<vector> >(cf, accessOp<List<vector> >());
    List<vector> RF = ListListOps::combine<List<vector> >(rf, accessOp<List<vector> >());

Before these lines, we have:

    Pstream::gatherList(l);
    Pstream::gatherList(cf);
    Pstream::gatherList(rf);

I also checked the source files in the following:

OpenFOAM/OpenFOAM-2.1.1/src/OpenFOAM/containers/Lists/ListListOps

Actually combine and gatherList are a pair.

For my previous appreciation, the "gatherList", similar to MPI_gather, should collect the data from all the processors and then store the data in the root. About the how to store in the root (the order or numbering), it should be automatic or at least can be set by the programmer. So the question is: what is the usage for the combine operations here?

Thank you so much

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ $$$$$$$$$$$$$$$$$$$

Not sure the red sentence is correct or not, because in the same source files

    Pstream::scatterList(v);

    List<decayingVorton> V = ListListOps::combine<List<decayingVorton> >(v, accessOp<List<decayingVorton> >());

Here after scatterList, the ListListOps::combine is used.

Any comments?

[flames]

Hello there,

in the LEMOS InflowGenerator, if the integral length scale is less than the nominal cell size, then is this method still valid? Should I always specify the integral length scale large than the mesh size?

Thank you all if any comments can be provided!

[flames]

    vector velocityAt(const vector& v) const
    {
        vector dv = v - location_;
        scalar nrm2 = magSqr(dv);
        vector t = dv ^ omega_;

        return (1/length_)*exp(-(M_PI/2)*nrm2/(length_*length_))*t;
    }

Hello there, is there any explanation about the above distribution? It looks like a gaussina distribution but is not exactly the same. The vector t is constructed from omega, which is from the random vector.

[hannes]

The derivation of the velocity distribution is explained in the following article by Kornev et al. (2007):
http://dx.doi.org/10.1063/1.2738607

It is obtained, if the spectrum for decaying turbulence is demanded from the generated fluctuations.

Regards, Hannes

[hannes]

and regarding the selection of the length scale:

If the length scale becomes less than the cell size, the grid can no longer resolve the inner structure of the turbulence as well as that of the generated vortons.

It is questionable, if you are still doing LES in such a case. But in addition to that, you will probably get the same results with the inflow generator as with simple white noise (the vanilla "turbulentInlet" BC in OpenFOAM) but for a higher computational cost.

Regards, Hannes

[aka]

Dear Mathias,
Thanks for the contribution with the LEMOS. I successfully compiled all of them without problems and run the turbulence libraries for Large Eddy Simulation. I am interested to extend for scalar transport and I see that both the LDMMS and dynamicMixedModel have extensions with "f.name()". Can you please provide me an idea how to call "divFeff" and "Feff" in my solvers?


Thank you

[IvanaS]

Hi,

In the LEMOS InflowGenerator does it matter how inlet is oriented? Or what should be axial velocity? Is that hard coded?

Thank you

Regards

[tung.nguyen]

Hi,

In LEMOS, would it be possible to generate the homogeneous and isotropic turbulence by inputting proper values of Reynolds shear stresses?

Sincerely,

Tung.

[hannes]

Dear Tung,

yes it is possible.
Just prescribe an appropriate uniform distribution of the Reynolds Stresses and the length scales. The generated length scales are isotropic anyway.

Regards, Hannes

[tung.nguyen]

Dear Hannes,

Thank you very much for your response.

I have been followed your paper of 'Synthesis of homogeneous anisotropic turbulent fields with prescribed second-order statistics by the random spots method'. Please correct me if I am wrong. From this paper, I think that by prescribing a auto-correlation function like the one I found in the your published code, the turbulent field will be homogeneous. The isotropic property is then controlled by the Reynolds stresses.

Also, could you tell me a bit more about the isotropic turbulent length scale please?

Thank you very much your time and support.

Sincerely,

Tung Nguyen.

[amanbearpig]

Originally Posted by matthias

Dear Rob,

we will provide a little test case or tutorial where you can see the settings and some explanations of the inflow generator. Furthermore the OF reader of paraview is not designed to read the vortons which are used to create the fluctuations. So that's not a bug in the code but a missing feature in OF paraview plugin.

We will have a look at it and publish a workaround as fast as possible.


Best regards

Matthias

I realize that this is an old topic I'm bringing back, but I've been looking at using the inflow generator from the LEMOS extensions and I can't seem to find the mentioned tutorial cases or examples. Does anyone know where I can find them?

There is a one page .pdf in the LEMOS extensions download, but it doesn't seem to provide any more information on how to setup the inflow generator correctly.

Thank you!

[amanbearpig]

Just bumping this back up - not sure how many people use the LEMOS Inflow Generator, or if anyone knows where I could find the mentioned test case/tutorial for its use? Thanks!

[wyldckat]

Originally Posted by amanbearpig

Just bumping this back up - not sure how many people use the LEMOS Inflow Generator, or if anyone knows where I could find the mentioned test case/tutorial for its use? Thanks!

Quick answer:

• One of the official pages, with instructions on how to download: http://www.lemos.uni-rostock.de/en/d.../cfd-software/
• The location of the online repositories: https://github.com/LEMOS-Rostock
• Inside each repository is a "tutorials" folder.

If you're looking for something more, please be a bit more specific

[amanbearpig]

Hi Bruno,

Thanks for the message. Sorry if the message seemed unclear, I was referring to the post I had made just above the "bumping" post in the last message. I have the Inflow Generator downloaded and installed, I'm just looking for some help/clarification on properly setting it up and configuring the boundary condition.

When I look in the repository for LEMOS, I only see tutorials for "PODSolver" and "movingBlockRBF", nothing for the Inflow Generator.

I was referring to the message above from Matthias where he mentions putting together a tutorial or test case for the Inflow Generator:

Originally Posted by matthias

Dear Rob,
we will provide a little test case or tutorial where you can see the settings and some explanations of the inflow generator. Furthermore the OF reader of paraview is not designed to read the vortons which are used to create the fluctuations. So that's not a bug in the code but a missing feature in OF paraview plugin.

We will have a look at it and publish a workaround as fast as possible.


Best regards

Matthias

[openfoammaofnepo]

Dear Hannes,

When I use this boundary condition to run my simulation, I tried to use paraview to plot the data. However, for the file U, I always go the error messege from paraview as follows:

=============
ERROR: In /home/utkarsh/Dashboards/MyTests/NightlyMaster/ParaViewSuperbuild-Release/paraview/src/paraview/VTK/IO/Geometry/vtkOpenFOAMReader.cxx, line 6478
vtkOpenFOAMReaderPrivate (0xa3a0d0): Error reading line 9161360 of /media/usb2T/ColdFlow_LES/LES_VortonInlet/0.16/U: Expected a number, found (
=============

So I cannot see the velocity fields. I check the U file and actually the line 9161360 corresponds to the the following:

==================
ind 2;

100
(
0.00125
(....)
(....)
(....)
0.00375
)
==================

I am not sure if you have the same problem when you visualize the data using paraview. Thank you.

[openfoammaofnepo]

I found that this problem is there because we output the list of vortons in the file of velocity U. When I comment the following lines in the decayingTurbulenceFvPatchVectorField.C:

=============
// if (Pstream::master())
// os.writeKeyword("vortons")<<vortons_<<token::END_S TATEMENT<<nl;
=============

I found I can open the file U using paraview now. However, it seems that the vorton number is reset to the initial values. So that means the time averaging operation is stopped after I did that and each time I resume the simulations, the vorton is fresh.

Any good solutions to maintain the time averaging/accummulation effect and at the same time open the U file using paraview? Thank you.

Originally Posted by openfoammaofnepo

Dear Hannes,

When I use this boundary condition to run my simulation, I tried to use paraview to plot the data. However, for the file U, I always go the error messege from paraview as follows:

=============
ERROR: In /home/utkarsh/Dashboards/MyTests/NightlyMaster/ParaViewSuperbuild-Release/paraview/src/paraview/VTK/IO/Geometry/vtkOpenFOAMReader.cxx, line 6478
vtkOpenFOAMReaderPrivate (0xa3a0d0): Error reading line 9161360 of /media/usb2T/ColdFlow_LES/LES_VortonInlet/0.16/U: Expected a number, found (
=============

So I cannot see the velocity fields. I check the U file and actually the line 9161360 corresponds to the the following:

==================
ind 2;

100
(
0.00125
(....)
(....)
(....)
0.00375
)
==================

I am not sure if you have the same problem when you visualize the data using paraview. Thank you.

[openfoammaofnepo]

Hello,

In my case, the turbulent inlet is concentric ring with inner radius 25 mm and out radius 30 mm. The air inlet is just between the inner and outer radii. I set the LField uniform to be 0.00175m. The bulk velocity going through the inlet about 20 m/s. The RField is very close to the fields from a pipe flow. Then in my simulation, the number of vorton is about 5000.

Is this vorton number reasonable for a good LES? Thank you very much.

Another problem is:

When I use this boundary condition, I will always have numerical stability problem, i.e. the simulation will sometimes blow up at the inlet due to the fluctuations. Do you have similar experience?

Originally Posted by openfoammaofnepo

I found that this problem is there because we output the list of vortons in the file of velocity U. When I comment the following lines in the decayingTurbulenceFvPatchVectorField.C:

=============
// if (Pstream::master())
// os.writeKeyword("vortons")<<vortons_<<token::END_S TATEMENT<<nl;
=============

I found I can open the file U using paraview now. However, it seems that the vorton number is reset to the initial values. So that means the time averaging operation is stopped after I did that and each time I resume the simulations, the vorton is fresh.

Any good solutions to maintain the time averaging/accummulation effect and at the same time open the U file using paraview? Thank you.

[openfoammaofnepo]

Dear Hannes,

I am interested in knowing about the vorton number which can be used for the LES inlet boundary conditions. I found if I use a uniform LField, changing the LField will lead to the large variation of the length scale. So now a question arises:

For a jet exit (from a fully developed pipe flow) with diameter 3.6 mm, axial bulk velocity with 60 m/s. If I used LField=0.0009 m, the vorton number will be around 270. Then I use d LField=0.00045 m, the vorton number will be 720 or so. How will the vorton number affect the results?

Of course I can do two tests in the LES, but for my simulation this is a little expensive. So could you please give some comments about this issue?

Thank you.

[openfoammaofnepo]

Dear All,

I found a problem about the quantity "ind_" when I resume the simulation but with different processor number.

For example, in the first simulation, if the decayingTurbulenceInflowGenerator boundary only treated in processor0, then when I use reconstructPar to get the complete data set, the quantity "ind_" should be correct, i.e. real iteration step so far. However, if this boundary condition is not processor0, then the reconstructed data set will only have ind_ =2, what the real ind_ is.

This is always fine if I resume the second simulation with the same processors. However, if we would like to use the reconstructed data to start another simulation, then the quantity "ind_" will be set to "2", which means the time averaging effects will be erased and the vorton accummulation will start from scratch.

But I do not know how to fix this. Anybody has some suggestions??

Thank you.