If you followed my previous posts here, you know I developed a wall function formulation based on the Musker wall function which, thanks to a math trick, is integrable also for arbitrary Pr/Pr_t (Sc/Sc_t) numbers and also for some forms of non equilibrium terms.

One of the nice things about this formulation is that it uses the same form of turbulent viscosity approximation that holds for the Spalart-Allmaras model near a wall, as they both use:

where is the Von Karman constant and is the value where . The formulation implies for large and near the wall, with:

The classical Musker formulation uses , which is the correct near wall behavior, while the SA model uses instead , which was claimed to be ininfluent in the original paper, yet certainly uncorrect. Also, the constant implied by the SA model is given by:

which for gives, approximately, (but could be also expressed in closed form for arbitrary ).

Besides the near wall behavior, a striking difference between the SA near wall behavior and the Musker one is that latter is easily integrable to a nice closed form wall function and, as I have shown in previous posts, the same holds for the temperature and other scalars. While the same is formally true also for the SA model, as shown here:

https://www.iccfd.org/iccfd7/assets/...1902_paper.pdf

it is debatable that the "nice" and "closed" form description applies to that as well; also, it is unclear if the approach can be extended to temperature and scalars. Nonetheless, the above SA wall function has already found widespread use, at least in academic applications.

This note comes from the desire and attempt to modify the SA model in a well known CFD code that, indeed, allows the user to implement their own turbulent viscosity formulation. The idea was to force the SA model to behave at wall as the Musker wall function.

Indeed, the SA model is built in such a way that, in cases where wall functions conditions apply (i.e., ), the prescribed formula, independently from how is defined, allows the linear solution to hold in the whole viscous+buffer+log zone. That is, under the classical equilibrium assumptions, a proper should ensure that the SA solution is always of the following form, independently from :

This preliminary examination then suggests that the Musker behavior could be reached by simply using:

with , where:

However, this was not possible as the code was hardcoded to use:

in the production and destruction terms, instead of:

So, in order to apply the correct modification, an additional source term has to be supplied, that deletes the old production and destruction and uses the new ones. This, of course, is just as cumbersome as it sounds, and requires some insight into the SA model that a typical user wouldn't probably have (not even myself, considering that the first implementations of this approach didn't recognize the need to alter also the destruction term).

In conclusion, the present note is to suggest that implementations of the SA model should use the following definition of :

which makes it valid for whatever definition of the turbulent viscosity. The immediate gain is that now one can easily implement a SA version with the correct near wall behavior and simple, all-y+, analytical wall function.

In the end, the implementation used in the attached source code here worked much better than the one only affecting the turbulent viscosity.

Still, the match is not as perfect as when one compares the original SA with its underlying wall function. In particular, for some reason, the turbulent viscosity ratio fails to reach exactly 1 at the exact prescribed location (a=11.0409) and there is a slight bump in the otherwise linear behavior.

Note that for a closed source tool like the one used in this test, the exercise above is basically cherry-picking until you get all the terms right (as it is impossible to know which terms were implemented using the turbulent viscosity and which ones using ). So, this must be considered just as an exercise or, at best, a work in progress. The very point here is, a correct implementation is independent from .

OpenFOAM, for example, seems to be correctly implemented, so that one should really just modify the definition of in SpalartAllmaras.C and is ready to go.

1. Mesh is the most important aspect - I have spent countless hours fixing issues in other places while the real issue was with my mesh. As a thumb rule, make sure the mesh has: no non-orthogonality issues, low aspect ratio cells, no refinement zones in the region with high gradients

2. Always start with a coarse mesh - fix your problems fast!

3. OpenFOAM tutorial cases are not fine tuned, so don't use them blindly for your case. Check the boundary conditions used by tutorial in Doxygen (or the header file in src) and ensure that the right parameters are chosen for your model physics.

Eg: totalPressure BC uses rho=none for incompressible and rho=rho for compressible subsonic.

4. For internal flow, ensure that the mass flux is stable at the inlet and outlet. For statistically stationary flows, the average mass flux should be constant/ periodic.

<more to be added as I keep learning :)> ]]>

Simulation details: I am doing a 2D axisymmetric flow simulation using a wedge BC at front/ back planes. I am using a custom solver based on homogeneous relaxation model. This is similar to cavitatingFoam solver available in OpenFOAM which uses homogeneous equilibrium model.

Mesh: For multiphase flow, it is very very important to ensure a good quality mesh, which includes the following:

1. Avoid refinement zones - At the refinement zones boundaries, I saw spurious pressure fluctuations. Therefore, avoid them at all costs.

2. Low aspect ratio cells - Ensure that the aspect ratio of cells remains low.

3. Smooth grading in cells

Boundary conditions:

I tried several combinations for pressure boundary condition but ended up getting pressure oscillations within the domain due to the two phase flow at the outlet patch. The solution I found is to use totalPressure BC for pressure at Inlet, outlet patch.

BCs combination I finally settled on:

Pressure: totalPressure at Inlet, Outlet

Velocity: pressureInletVelocity at Inlet, pressureInletOutletVelocity at Outlet

density: zeroGradient works (I use a custom BC which is similar to ZG)

Refer to the following link for useful BC combinations for internal flow:

https://www.openfoam.com/documentati...binations.html ]]>

This forum has been a big source of information for me since I started doing CFD. Now, I want to share my work to thank your altruistic knowledge sharing. Regarding the main topic of this blog, I am going to talk about my first turbomachinery simulations with rhoSimpleFoam, the problems I found with this solver and my solution, which I called turboSimpleFoam. Feel free to ask me whatever you want or tell me if something is wrong.

Turbomachinery is a very interesting topic in my opinion, so I started the design of a turbocharger a year ago just for fun. After modelling some of the geometry, I thought that doing some CFD simulations would be of interest to understand the behaviour of the air when it passes through the device. Therefore, a computational domain was defined by the following properties:

• RANShttps://www.cfd-online.com/Forums/bl...1&d=1610557096

• MRF

• Compressible

• K-Omega SST

• Subsonic

• Inlet T = 300 K

• Inlet p = 1 atm

• Mass flow = 0.1 Kg/s

• Rotation Speed = 50 000 rpm

Until here the problem seemed challenging, but nothing I hadn’t done before. Taking into account the conditions of the problem to be solved, I chose rhoSimpleFoam as my solver, snappyHexMesh as my mesher and then I performed some simulations. Surprisingly for me, the temperature decreased to 280 K at the exit of the rotor so, obviously, something was terribly wrong.

https://www.cfd-online.com/Forums/bl...1&d=1610557130

Firstly, I tried several things like changing its thermodynamic properties or its boundary conditions, without significant changes. The problem was driving me crazy for a few days, but then I introduced an energy source in the rotating zone, and it worked. However, I hadn't solved it yet, because I picked an energy source of a random number of watts, but it was a good starting point.

Once I noticed that the energy along the rotating zone wasn’t being solved properly, I studied turbomachinery theory to calculate the energy source, and this was my conclusion:

𝑊𝑢 = 𝑚̇ · ( 𝑢1 · 𝑐𝑢1 − 𝑢2 · 𝑐𝑢2 )

𝑢 = 𝑟 · 𝜔

𝑑𝑊𝑢 = 𝑑𝑖𝑣𝑒𝑟𝑔𝑒𝑛𝑐𝑒( 𝑚̇ · 𝑢 · 𝑐𝑢 )

𝑢 = 𝑟 · 𝜔

𝑑𝑊𝑢 = 𝑑𝑖𝑣𝑒𝑟𝑔𝑒𝑛𝑐𝑒( 𝑚̇ · 𝑢 · 𝑐𝑢 )

Where 𝑊𝑢 is the energy source, 𝑚̇ is the mass flow, 𝑢 is the rotation velocity, 𝑐𝑢 is the tangential velocity of the flow, 𝑟 is the radius and 𝜔 is the rotation speed.

After that, I introduced the energy source in the code and some extra variables like the rotation velocity, the tangential velocity, the radial velocity and something I called the zone term, Z. The last term is necessary due to the energy source value being zero at the static zone and one at the rotating zone. Taking all of this into account, the energy equation in the code is:

fvScalarMatrix EEqn

(

fvm::div(phi, he)

+ (

he.name() == "e"

? fvc::div(phi, volScalarField("Ekp", 0.5*magSqr(U) + p/rho))

: fvc::div(phi, volScalarField("K", 0.5*magSqr(U)))

)

+ thermophysicalTransport->divq(he)

==

fvOptions(rho, he)+Z*fvc::div(phi,u*Ut)

);

Finally, the results obtained are logical and the temperature rises to 350 K. Also, I have solved the problem in EXCEL using velocity triangles and thermodynamics, so the results of the CFD simulation can be compared with the theory of turbomachinery. As it can be seen at the end of this blog, the results obtained by both ways are quite similar.

https://www.cfd-online.com/Forums/bl...1&d=1610557130

In conclusion, the new solver turboSimpleFoam gives excellent results in comparison with the theory of turbomachinery. Also, the temperature, the pressure and the density at the outlet are in line with the reality using both ways.

https://www.cfd-online.com/Forums/bl...1&d=1610557130

Solver (Rotation axis must be in the Z direction):https://mega.nz/folder/NxZ2QRzJ#u3DE_1RVBJT8DbhAUsCkHQ

PostProcess Paraview:https://mega.nz/file/p4ZnwC6B#KmIzSS...fLq0aYTiJZZtyI

Simulation:https://mega.nz/file/gsYWmJIB#izgg1_...K2XYll5K55lMq0

PDF:https://mega.nz/file/90gwEIoC#JMq9Uf...ssbfEMcSm910z0

https://www.mdpi.com/journal/energie...ale_microscale

Contributions from the CFD community are welcome! ]]>

The scope of these notes is to discuss the simulation of stationary compressible turbulent flow in OpenFoam using the rhoSimpleFoam solver. We assume the reader to be familiar with the concept of stationary incompressible turbulent flows and the simulation of these flows in OpenFoam. This allows us to focus here on the transition from incompressible to compressible. We target internal flow with Mach number between 0.4 and 2. The application to external flows and/or higher mach Numbers is out of scope and described elsewhere. We thus consider the case of e.g. the mixing of various gasses injected into a vessel. In target scenarios the gas enters the vessel through a nozzle with small diameter at high mass flow rate. The assumption that the Mach number is bounded by 0.4 is violated in proximity of the nozzle outlet. An incompressible formulation no longer applies. We limit ourselves to case in which the various gasses mix without chemically reacting. We do have the modeling of the reacting case as final scope however.

what is rhoSimpleFoam: Stationary compressible turbulent flow in OpenFoam can be modeled using the rhoSimpleFoam solver.

why this notes: A lot of information on rhoSimpleFoam can be found elsewhere (cite wiki, cite Moukalled). Our aim here is to provide timely and updated description of the solver that includes

* a description of the thermodynamics (rhoThermo vs. psiThermo); rhoSimpleFoam is a pressure based solver. We thus need to recover density (rho) from pressure (p) using either rhoThermo or psiThermo;

* a description of transonic option (when to use it, change in energy equation, what are its advantages in terms of computational cost, what its limitations);

* numerical stability, sign of source terms, the presence of pressure waves (or the absence thereof and techniques to avoid them, see e.g. \cite{pressure-waves-sprayFoam});

* the comparison of convergence criteria (residuals vs. outlet quantities);

* a description of possible limitations of the solver (what happens e.g. at sufficiently high Mach numbers, break-down of multigrid for pressure solve due to transport term, advice on when to switch to alternative density base and/or coupled solvers), comparison between segregated and coupled solvers (HISA project);

what concept are assumed to be known to the reader (and thus not discussed here):

rhoSimpleFoam is a pressure-based segregated solver that iterates between the pressure, velocity and energy fields using the SIMPLE (or SIMPLE-C) algorithm (and possibly turbulent quantities) (cite wikipedia, Malaseekara, Moukalled). rhoSimpleFoam thus builds on components developed elsewhere in OpenFoam. In particular

* from basic solvers in OpenFoam: cell-centered finite volume discretization for scalar fields, non-linear iteration for scalar fields, linear solvers, parallel set-up and solver run;

* from incompressible solvers in OpenFoam: Reynolds averaging, cell-centered finite volume discretization for pressure-velocity coupling, Rhie-Chow interpolation, SIMPLE iteration for pressure-velocity coupling, consistent SIMPLE (SIMPLEC);

* from incompressible solvers in OpenFoam: solving for turbulent quantities;

what is outside scope of this page: transient formulation (using local time stepping), turbulence modeling beyond RANS with two-equation turbulence models (thus no Reynolds stress model, no LES), no thermodynamics beyond the ideal gas law; no adaptive mesh refinement;

References:

* wikipedia, RANS: https://en.wikipedia.org/wiki/Reynol...okes_equations

* CFD-Online, pressure-waves-sprayFoam: https://www.cfd-online.com/Forums/op...ombustion.html

* CFD-Online, e-vs-h-in-energy-equation-1: https://www.cfd-online.com/Forums/op...implefoam.html

* CFD-Online, e-vs-h-in-energy-equation-2: https://www.cfd-online.com/Forums/op...roperties.html

* CFD-Online, e-vs-h-in-energy-equation-3: https://github.com/OpenFOAM/OpenFOAM...25ab9817b3ec62 (It is generally more convergent and stable to solve for internal energy if the fluid is incompressible or weakly compressible.)

2/ Representation of the Thermodynamics

The representation of the thermodynamics or the equation of state in a finite volume computation requires a separate data structure. In OpenFoam, the thermodynamics of the fluid in represented by the fluidThermo class (collection of data and operations of this data). The fluidThermo class is a parent class for rhoThermo and psiThermo. Both classes store the density (rho), compressibility (psi) and dynamic viscosity (mu). Both of the latter classes allow to update the density once a new pressure field has been computed. This update is performed through the correct() member function.

Questions

* how exactly is thermophysicalTransport->correct() in rhoSimpleFoam.C and thermo.correct in EEqn.H complementary to each other?

* what is rhoDelta as argument of correct() in rhoThermo?

* what is the body of correct() in psiThermo left body?

3/ Pressure in Compressible Flow Computations

In an incompressible flow simulation, density is constant, the flow equations (conservation of mass and momentum) can be divided by density and the kinematic pressure (p/rho [m^2/s^2]) is solved for. In a compressible flow simulation instead, the static pressure (p [Pa]) is solved for. This will have an impact on the boundary conditions being imposed, and thus the case set-up in OpenFoam. More … .

References:

* OpenFoam v2006 Users manual: various forms of the pressure: https://www.openfoam.com/documentati...-pressure.html

4/ Internal Energy vs. Enthalpy in Compressible Flow Computations

1.4/ Analytical Considerations

Heat capacity at constant volume ([units]): cv

Heat capacity at constant volume ([units]): cp

Thermal conductivity ([units]): k (heat flux = k (temperature flux) )

Thermal diffusivity when solving for enthalpy (h [units]): \alpha_{h} = \kappa / (\rho cv)

Thermal diffusivity when solving for internal energy (e [units]): \alpha_{e} = \kappa / (\rho cp)

Prandtl number is ratio of momentum diffusivity (kinematic viscosity nu) and thermal diffusivity \alpha

Prandtl number when solving for enthalpy = \nu/\alpha = (cv \mu)/ k

Prandtl number when solving for internal energy = \nu/\alpha = (cp \mu)/ k

This difference are taken care of in the implementation. Details are here: https://www.cfd-online.com/Forums/op...implefoam.html

2.4/ Numerical Considerations

It is generally more convergent and stable to solve for internal energy (instead of enthalpy) if the fluid is incompressible or weakly compressible. See https://github.com/OpenFOAM/OpenFOAM...25ab9817b3ec62 and https://www.cfd-online.com/Forums/op...roperties.html . Keep energy positive by keeping source term positive. See book Patankar.

References:

5/ Problem formulation

1.5/ Conservation Equations (conversation of mass, momentum and energy closed by an equation of state to which turbulent quantities are added)

Density no longer constant. Pressure is dynamic pressure. Various expressions for the energy (internal energy, enthalpy and temperate exists);

1.1.5/ Conversation of mass

2.1.5/ Conservation of momentum

3.1.5/ Conservation of energy

4.1.5/ Solving for turbulent quantities

5.1.5/ Update of density through thermo-physical quantities (psi = R T)

2.5/ Boundary conditions (inlet, outlet and walls)

6/ Segregated Solution via SIMPLE Algorithm

After finite volume discretization, flow equations need to solve. Given SIMPLE for incompressible flow (and implemented in e.g. simpleFoam), add two steps. First step is update of the density (using the equation of state). Second step is the solve for the energy (enthalpy or temperature);

7/ Implementation in rhoSimpleFoam in OpenFoam

Show here UEqn.H, pEqn.H and EEqn.H and turbulent quantities;

8/ Guidelines on using the Solver

1.8/ Starting from Initial Guess Provided by simpleFoam (see notes)

2.8/ Handle on converge

limitT and limitU (first print values, then limit)

9/ Tutorials

1.9/ sBend

2.9/ elbow

3.9/ Sandia Flame D

4.9/ reverseBurner

References

* https://github.com/OpenFOAM/OpenFOAM...b71e7cf0172c34

User guide/Wiki-1/Wiki-2/Code guide/Code Wiki

Nilsson/Guerrero/Holzinger/Holzmann/Nagy/Santos/Nozaki/Jasak-FSB

OpenFOAM Governance and Technical Committees

Report bugs/Request features: OpenFOAM (ESI-OpenCFD-Trademark)

Report bugs/Request features: FOAM-Extend (Wikki-FSB)

Report bugs: OpenFOAM (Foundation)

How to create a MWE.

10/ References

* Greenshield

* Moukalled

* Malalaseekara and Versteeg

* wiki on compressible Navier-Stokes Equations: https://en.wikipedia.org/wiki/Navier...wtonian_fluids

* SIMPLE algorithms: https://en.wikipedia.org/wiki/SIMPLE_algorithm

11/ Open End

* is similar description above available elsewhere?

* when does rhoSimpleFoam break?

* how to add source terms for radiation and chemistry?

* how do implementation in various flavor of OpenFoam differ ]]>

However, i don't like the new file system solution since you could simply run a virtual box or a docker which are basically the same but much more elegant and portable. I want to have some approach that can install openfoam locally, and be used as a library instead of working in a separate environment.

Quote:

Hi Alexey,
I have a problem (again) when i am following the instructions as given in https://github.com/mrklein/openfoam-...ase-&-Homebrew In particular, I have followed the steps without any problem until when I had to apply the patch with git: git apply OpenFOAM-v1912.patch When I opened the patch file, I show the flag: 404: Not Found. Where can I find the patch? When I visited your site, I show that you have patches for different versions of OpenFoam, but not for v1912. If I download the most recent one, "OpenFOAM-7-0ebbff061.patch" and execute "git apply OpenFOAM-7-0ebbff061.patch" instead, do you think it will be OK? |

https://www.researchgate.net/post/Ho...aracterisation

Quote:

Filippo Maria Denaro added an answer December 7, 2017 Lalit the Nyquist theorem says that for a step sampling dt you can describe the smallest wavelenght 2*dt (three samples describe a sine). For a given period lenght T, the ratio T/(2*dt) gives the maximum wavenunber you can represent |

Quote:

Well, I suggest to do the FFT of the three velocity
components at the chosed position. However, you need a correct windowing technique as your signal is not necessarily periodic in time. Then, consider that depending on the position far from the cylinder along the wake, you can or not recover the theoretical inertial slope. Furthermore, the theoretical slope should be the same, interchanging in space and time, requiring further assumption about ergodicity. Finally, I would suggest to do the spectral analysis also in space, you can do the FFT along z and for several positions along the streamwise direction |

Quote:

Indeed, if y+ =4 is relative to the finest grid, it is confirmed to be a wall function problem. I can't double check now, but I'm pretty sure that the k-omega sst model in CFX uses an all y+ wall function, which means that a wall function is always active. While, in theory, such wall functions should be insensitive to the specific y+ value, they are not perfect and your case is very far from the typical wall function scenario (equilibrium boundary layer), so what you obtain is actually expected.
The only viable solution here, and I suggest you to investigate it also for your other models, is to redistribute cells in your grid to be always within y+ = 1-2, but no more. In any case, the important thing is that you can't have y+ changing between the grids when doing a grid refinement. EDIT: I know, it sucks... |

Quote:

Indeed, if y+ =4 is relative to the finest grid, it is confirmed to be a wall function problem. I can't double check now, but I'm pretty sure that the k-omega sst model in CFX uses an all y+ wall function, which means that a wall function is always active. While, in theory, such wall functions should be insensitive to the specific y+ value, they are not perfect and your case is very far from the typical wall function scenario (equilibrium boundary layer), so what you obtain is actually expected.
The only viable solution here, and I suggest you to investigate it also for your other models, is to redistribute cells in your grid to be always within y+ = 1-2, but no more. In any case, the important thing is that you can't have y+ changing between the grids when doing a grid refinement. EDIT: I know, it sucks... |

Quote:

yes, at least in the viscous sublayer. The size of your grid cell (or the number of points per unit length) determine the smallest scale you can catch on a given grid. From information theory, the Nyquist theorem tells us that we need at least 2 points per wavelength to represent a frequency (we need to be able to detect the sign change). However, 2 points per wavelength is just for Fourier-type approximations. For other schemes like O1 FV you need a lot more, maybe 6 to 10 to accurately capture a wavelength. Let's assume that you have the same grid in all of the flow (i.e. high resolution everywhere, no grid stretching or such). Then the smallest scale you can capture is determined by your grid and scheme, the better/finer, the smaller the scale.
OF course, most grids will coarsen away from the wall, so the smallest scale will "grow bigger" away from the wall as well Ha, that's the crux of LES :) of course, the bigger y+, the fewer the small scales you will catch, but does that change the result of the bigger scales? The answer is not straight forward, but I'll try to make it short: Let's talk about NS-equations (or any non-linear conservation eqns). The scales represented in the equations are coupled by the non-linearity of the equations, i.e. what happens on one scale will (eventually) reach all other scales (also known as the butterfly effect). So the NS eqns represent the full "nature" with all its scales and interactions. We now truncate our "nature" by resolving only the larger scales, since our grid is too coarse.... what will happen? Will the large scales be influenced by the lack of small scales? Hell, yeah, they will. We are lacking the balancing interaction of the small scales, since we don't have these scales. We are also lacking the physical effects that take place at small scales (dissipation).... so we have production of turbulence at large scales, the energy is handed down through the medium scales but is NOT dissipated at the small scales, since they are simply not present in our computation. Will that influence the large scales? Definitely! That's why LES people add some type of viscosity (effect of small scales) to their computations, otherwise, their simulations would very likely just blow up! hope this help! cheers |

Quote:

This blog post could potentially be edited as time goes on and I remember about things I've done in the past and which should be picked up by someone else:

- Generating version template pages and logos for said versions at openfoamwiki.net - this is explained here: https://openfoamwiki.net/index.php/F...n_templates.3F and here https://openfoamwiki.net/index.php/F...AM_versions.3F
- Writing and testing installation instructions at https://openfoamwiki.net/index.php/Installation/Linux - The objective was to ensure that the less knowledgeable user would still be able to compile+install OpenFOAM from source code with a much higher success rate, than following the succinct instructions available at the official websites.
- Updating the release version links at the top right-most corner of openfoamwiki.net
- Uh... several other things listed at openfoamwiki.net, mostly listed here: http://openfoamwiki.net/index.php?ti...arget=Wyldckat
- Contributing to bug reports and fixes at openfoam.com
- Moderator work here at the forum, including:
- Hunting down spam, which nowadays is mostly automated, but not fully automated.
- Moving threads to the correct sub-forums.
- Re-arranging forums to make it easier for people to ask and answer questions, as well as finding existing answers.
- Warning forum members when they've not followed the rules...
- I wanted to have pruned all of the threads on the main OpenFOAM forum and place them in their correct sub-forums, but never got around to it. There is a thread on the moderator forum that explains how to streamline the process.
- I wanted to have finished moving posts into independent threads out of this still large thread: https://www.cfd-online.com/Forums/op...ed-topics.html
- Also out of this one: https://www.cfd-online.com/Forums/op...am-extend.html

- Had a list of posts/threads I wanted to look into... which is now written on this wiki page on my central repository for these kinds of notes: What I wanted to still have done for the OpenFOAM community, but never managed to find the time for it
- And had a list of bugs I wanted to solve: Bugs on OpenFOAM's bug tracker I wanted to tackle, but never managed to find the time for it
- I have over 50 repositories at https://github.com/wyldckat - most of them related to OpenFOAM and which will be left as-is for the years to come. If you want to continue working on them and even take over maintenance, open an issue on the respective repository.