[tiam]

Dear all,


For some years now, me and my colleagues have been working on implementing a library of wall models for LES, expanding the native capabilities of OpenFOAM. In the latest release, v0.4.0, we have added support for the latest versions of OpenFOAM, both Foundation and OpenCFD releases. It is thus a good time-point to (re-)introduce the code to the community.


The library can be found here

https://bitbucket.org/lesituu/libwallmodelledles

The README file provides quite a bit of information about what the library does, I copy the Key features section below

• Provides a number of wall models, based on both non-linear algebraic and ordinary differential equations, see the class-headers in the wallModels folder.
• Makes it possible to specify the distance to the wall model's sampling point, h, on a per-face basis.
• Allows the user to control all the other parameters of wall modelling, e.g. model constants, iterative solver settings etc.
• Serves a as a convenient framework for implementing new models without a lot of code duplication.

An in-depth discussion along with simulation results for turbulent channel flow and flow over a BFS can be found here.
https://arxiv.org/abs/1807.11786
More works using the library can be found in the end of the README.


For obvious reasons, it has not be possible to thoroughly validate the code using all the supported OF versions. Therefore any issues with compilations and running are very welcome to be reported. Please also feel free to contact me regarding any possible collaborations, WMLES is becoming a hot topic, and joining forces is usually of benefit.

[amanbearpig]

Hi Timofey,

Really great work with this! I've been playing around with it and have been pleased with my early testing. Thanks so much for making this publically available to the community. Is there a foam-extend version available or in the works?

[tiam]

Originally Posted by amanbearpig

Hi Timofey,

Really great work with this! I've been playing around with it and have been pleased with my early testing. Thanks so much for making this publically available to the community. Is there a foam-extend version available or in the works?

Hi!
Great to hear that it's working out for you. foam-extend support is not really in the making at the moment. Unfortunately, I have no experience with that fork, but I can imagine that for someone who does it would be pretty easy to make the adjustments! In any case, the fact that you request it is a push towards me considering to spend time on it . It won't be quick though, since I have other developments in the pipeline, which have higher priority.

[tiam]

The published version of the article describing the library can be downloaded for free until may the 30th by following this link


https://authors.elsevier.com/a/1Ysl32OInZsxl

[tiam]

I've just tagged v0.5.0 on Bitbucket. Some highlights


- Unit and integration tests.
- Stability improvements
- Code refactoring for better testebility and extensibility.
- Multicell sampling is included as a "beta version", currently not used by any wall models.

[Tj_m3]

Hi Timofey,

Many thanks for making this available. I am running into an issue with the parallel decomposition of the h value on the wall. The case is an airfoil in freestream flow. After the mesh decomposition, the processor0 folder shows an h value of "0" on the airfoil boundary, although it is set to the 2nd off the wall cell distance in the 0 folder. This seems to be triggering this warning in the log file:

"SingleCellSampler: max(h) is -1e+300 but no cell centres within distance 2*max(h) were found. Will sample from wall-adjacent cells"

h is being correctly set in the other processor folders - the ones which the airfoil wall resides on. But I am not sure those values are being used in the calculation.

Thanks!
Tommy

[tiam]

Originally Posted by Tj_m3

Hi Timofey,

Many thanks for making this available. I am running into an issue with the parallel decomposition of the h value on the wall. The case is an airfoil in freestream flow. After the mesh decomposition, the processor0 folder shows an h value of "0" on the airfoil boundary, although it is set to the 2nd off the wall cell distance in the 0 folder. This seems to be triggering this warning in the log file:

"SingleCellSampler: max(h) is -1e+300 but no cell centres within distance 2*max(h) were found. Will sample from wall-adjacent cells"

h is being correctly set in the other processor folders - the ones which the airfoil wall resides on. But I am not sure those values are being used in the calculation.

Thanks!
Tommy

Hi Tommy,


Glad to see you pick up the library. I think you might be the first to use it for external flows, so I'm excited to see how it goes. Do I understand correctly that the wall boundary has no faces on processor0? In that case you don't have to worry about it. In any case, I would do the following. Open the case in Paraview, and under Case Type, select Decomposed Case. This way you actually open the parallelized data. If you load in the data for your wall patch you can directly inspect your h values.
To be 100% sure what cells are used for sampling, you can run the simulation for 1 time-step and save the data. There will be a samplingCells field, which marks the cells that are used for sampling. The value that they get should be equal to the index of the patch, whereas for the rest of the cells the value is set to -1.



It is highly possible that you can just ignore the warning about the h values, I am pretty sure it sometimes prints that for no reason, but I hadn't had the time to fix that---to busy with other projects.


Best,
Timofey

[Tj_m3]

Hi Timofey

Yes, there are no wall boundary faces on processor0, but when inspecting the decomposed "h" files and the samplingCells as you said I can see that the sampling cells are correct.

Thanks for clearing that up! I just wanted to be extra sure before starting the grid study with a fixed h value.

-Tommy

[Tj_m3]

Hi Timofey,

I am having an issue with the sampling cells now falling on a different processor than the wall faces. It seems to happen when I use h >2 (the attached image is h=4). I read in your paper that it will default to sample from the wall adjacent cell in these cases, and at these cells I am seeing spikes in the wall shear stress. It is a relatively large number of points, as I am needing the mesh decomposed into ~120-160 processors due to the large grid count.

I was wondering if you had advice on a decomposition method that could avoid this, I am using scotch currently, or if there might be another work around to this?

Thank you!
Tommy

[Ali Amarloo]

Hi Timofey,
I wanted to compile the library on OF8.
Just to let you know, apparently they have changed the "turbulenceModels" to "momentumTransport" and they moved some files in src folders.
So latest version of your library (0.5.1) cannot be compiled and I have errors like this:

wmakeLnInclude error: base directory
/OpenFOAM-8/src/transportModels/incompressible/ does not exist

that folder is moved to src/momentumTransport.
or:

sgsModels/makeSGSModel.C:20:43: fatal error: IncompressibleTurbulenceModel.H: No such file or directory
#include "IncompressibleTurbulenceModel.H"

There is not such a file in of8 and it is changed to IncompressibleMomentumTransportModel.H

[tiam]

Originally Posted by Ali Amarloo

Hi Timofey,
I wanted to compile the library on OF8.
Just to let you know, apparently they have changed the "turbulenceModels" to "momentumTransport" and they moved some files in src folders.
So latest version of your library (0.5.1) cannot be compiled and I have errors like this:

wmakeLnInclude error: base directory
/OpenFOAM-8/src/transportModels/incompressible/ does not exist

that folder is moved to src/momentumTransport.
or:

sgsModels/makeSGSModel.C:20:43: fatal error: IncompressibleTurbulenceModel.H: No such file or directory
#include "IncompressibleTurbulenceModel.H"

There is not such a file in of8 and it is changed to IncompressibleMomentumTransportModel.H

Oh, bugger. Thanks for the info, I guess something like this would be bound to happen sooner or later. I'll update the readme. I think we still should be able to handle this smoothly though. Can't promise a date on the fix just now, but hopefully in the nearest 2 months.