Alt for funkySetFields-swak4Foam with easy setup for setting initial Scalar or Vector fields using a math expression.

https://github.com/Fluidentity/setExpS_V

C++ program to set initial fields of an OpenFOAM scalar or

vector using a math-expression, taking co-ordinates as

parameter. The expressions are based off of exprtk library

by Arash Partrow. Check the link beneath for more info.

readme.txt file describess expression syntax and involves

exhaustive mathematical manipulation.

https://github.com/ArashPartow/exprtk

This is an alternative to funkySetFields {swak4Foam) or

setFields, for those who couldn't get them to work on their

OpenFoam version.

I couldn't get it to work on OF-8, but I won't take credit

away from multiple versions & environments it's working on

already. Minimum effort on getting it to work .

Simple Scalar Vector Formulation.

Make good use of this quick fix.

-------------------------------------------------------------

An exemplary testCase folder for scalarTransportFoam can

be found in the repository, with custom ./Allclean & ./Allrun

scripts. ]]>

I am happy to announce the next occasion of the monthly meeting on the 15th of October 2021 at 16:00 German Time (UTC+2).

Login details can be found here.

Everybody is welcome.

See you there.

Patrick ]]>

Steps:

1. Generate whole sphere mesh using blockMesh See tutorials/mesh/blockMesh/sphere

2. Delete half sphere mesh using topoSet + subsetMesh.

3. Step 2 generates an "oldInternalFaces", checkMesh, fails. Then I use createPatch to set "oldInternalFaces" as wall. checkMesh OK.

4. Use topoSet to generate an inlet using a cylinderToCell

5. Create inlet using createPatch

To have these operations organized I created folders for the topoSet and patch operations. Then I took advantage of the argument -dict, which allows you to call the dictionaries from a folder.

Attached is the system folder, in case is useful or any suggestions are welcome.

blockMesh

topoSet -dict system/topo1/topoSetDict

subsetMesh topRegion -overwrite

createPatch -dict system/patch1/createPatchDict -overwrite

topoSet -dict system/topo2/topoSetDict

createPatch -dict system/patch2/createPatchDict -overwrite ]]>

Quote:

The error shown by checkMesh only means that you forgot to define the boundary faces in your blockMeshDict file. By the way, two questions.
First one, you forgot to define one of the arcs, well actually you have defined it in a wrong way. This is the arc going from point 15 to point 8 that you have defined it from 15 to 0. Second question, why are you using such an amount of blocks to create a cylinder? You can do it with less blocks. Look at your blockMeshDict modified to create your cylinder with the half of the blocks you used: Code:
/*--------------------------------*- C++ -*----------------------------------*\ | ========= | | | \\ / F ield | OpenFOAM: The Open Source CFD Toolbox | | \\ / O peration | Version: 2.3.0 | | \\ / A nd | Web: www.OpenFOAM.org | | \\/ M anipulation | | \*---------------------------------------------------------------------------*/ FoamFile { version 2.0; format ascii; class dictionary; object blockMeshDict; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // convertToMeters 0.1; vertices ( (-5.000000 -0.000000 0.000000) // v0 (-2.500000 -4.330127 0.000000) // v1 (0.000000 -5.000000 0.000000) // v2 (2.500000 -4.330127 0.000000) // v3 (5.000000 -0.000000 0.000000) // v4 (2.500000 4.330127 0.000000) // v5 (0.000000 5.000000 0.000000) // v6 (-2.500000 4.330127 0.000000) // v7 (-0.500000 -0.000000 0.000000) // v8 (-0.250000 -0.433013 0.000000) // v9 (0.000000 -0.500000 0.000000) // v10 (0.250000 -0.433013 0.000000) // v11 (0.500000 -0.000000 0.000000) // v12 (0.250000 0.433013 0.000000) // v13 (0.000000 0.500000 0.000000) // v14 (-0.250000 0.433013 0.000000) // v15 (-5.000000 -0.000000 1.000000) // v16 (-2.500000 -4.330127 1.000000) // v17 (0.000000 -5.000000 1.000000) // v18 (2.500000 -4.330127 1.000000) // v19 (5.000000 -0.000000 1.000000) // v20 (2.500000 4.330127 1.000000) // v21 (0.000000 5.000000 1.000000) // v22 (-2.500000 4.330127 1.000000) // v23 (-0.500000 -0.000000 1.000000) // v24 (-0.250000 -0.433013 1.000000) // v25 (0.000000 -0.500000 1.000000) // v26 (0.250000 -0.433013 1.000000) // v27 (0.500000 -0.000000 1.000000) // v28 (0.250000 0.433013 1.000000) // v29 (0.000000 0.500000 1.000000) // v30 (-0.250000 0.433013 1.000000) // v31 ); blocks ( hex (2 10 8 0 18 26 24 16) (10 10 1) simpleGrading (1 1 1) //hex (1 2 10 9 17 18 26 25) (10 10 1) simpleGrading (1 1 1) hex (2 4 12 10 18 20 28 26) (10 10 1) simpleGrading (1 1 1) //hex (11 3 4 12 27 19 20 28) (10 10 1) simpleGrading (1 1 1) hex (12 4 6 14 28 20 22 30) (10 10 1) simpleGrading (1 1 1) //hex (14 13 5 6 30 29 21 22) (10 10 1) simpleGrading (1 1 1) //hex (15 14 6 7 31 30 22 23) (10 10 1) simpleGrading (1 1 1) hex (0 8 14 6 16 24 30 22) (10 10 1) simpleGrading (1 1 1) ); edges ( arc 0 2 (-3.750000 -3.307189 0.000000) // c0 //arc 1 2 (-1.250000 -4.841229 0.000000) // c1 arc 2 4 (1.250000 -4.841229 0.000000) // c2 //arc 3 4 (3.750000 -3.307189 0.000000) // c3 arc 4 6 (3.750000 3.307189 0.000000) // c4 //arc 5 6 (1.250000 4.841229 0.000000) // c5 arc 6 0 (-1.250000 4.841229 0.000000) // c6 //arc 7 0 (-3.750000 3.307189 0.000000) // c7 arc 8 10 (-0.375000 -0.330719 0.000000) // c8 //arc 9 10 (-0.125000 -0.484123 0.000000) // c9 arc 10 12 (0.125000 -0.484123 0.000000) // c10 //arc 11 12 (0.375000 -0.330719 0.000000) // c11 arc 12 14 (0.375000 0.330719 0.000000) // c12 //arc 13 14 (0.125000 0.484123 0.000000) // c13 arc 14 8 (-0.125000 0.484123 0.000000) // c14 //arc 15 8 (-0.375000 0.330719 0.000000) // c15 0->8 arc 16 18 (-3.750000 -3.307189 1.000000) // c16 //arc 17 18 (-1.250000 -4.841229 1.000000) // c17 arc 18 20 (1.250000 -4.841229 1.000000) // c18 //arc 19 20 (3.750000 -3.307189 1.000000) // c19 arc 20 22 (3.750000 3.307189 1.000000) // c20 //arc 21 22 (1.250000 4.841229 1.000000) // c21 arc 22 16 (-1.250000 4.841229 1.000000) // c22 //arc 23 16 (-3.750000 3.307189 1.000000) // c23 arc 24 26 (-0.375000 -0.330719 1.000000) // c24 //arc 25 26 (-0.125000 -0.484123 1.000000) // c25 arc 26 28 (0.125000 -0.484123 1.000000) // c26 //arc 27 28 (0.375000 -0.330719 1.000000) // c27 arc 28 30 (0.375000 0.330719 1.000000) // c28 //arc 29 30 (0.125000 0.484123 1.000000) // c29 arc 30 24 (-0.125000 0.484123 1.000000) // c30 //arc 31 24 (-0.375000 0.330719 1.000000) // c31 ); boundary // patches ( out { type wall; faces ( (0 2 18 16) (2 4 20 18) (4 6 22 20) (6 0 16 22) ); } in { type wall; faces ( (10 8 24 26) (12 10 26 28) (14 12 28 30) (8 14 30 24) ); } ); mergePatchPairs ( //( masterpatch slavepatch ) // define connecting faces ); // ************************************************************************* // Regards, Alex |

Quote:

FEM lacks a fundamental statement of conservation. FVM (and DG) are axiomatically conservative based on face flux integrals. FEM is defined as a minimization problem--find the solution that best reduces the Galerkin (or Least-Squares) residual of this system. For solid mechanics, that minimization statement makes a lot of sense--configuration of solid mechanical systems map nicely to variational formulations. Conservation equations, however, do not.
For simple flow physics, the difference is not really that important. FEM with linear shape functions *may* be a little more accurate than 2nd order FVM on a per-DOF basis. The FVM code will probably run a bit faster. But, the FVM code will *precisely* (to round-off error) conserve the mass entering and exiting a system. FEM will not be absolutely conservative, without some additional tweaking--using dark arts that I know not. This really becomes an issue with reacting flows, say, where trace concentrations of species can make significant differences. A one-part-in-ten-thousand mass imbalance is inconsequential in external aero or a lid driven cavity, but it could create a dramatic difference in flame shape or attachment points. Another reason is that FVM solvers are highly optimized for solving flow problems, by basically cutting every corner possible. Segregated solution methods, projection methods, frozen field preconditioning for Newton Krylov...the list is very long. FEM doesn't have these and they do not automatically transfer. FEM tends to do a great job of handling inter-field coupling because it creates a large stiffness matrix using all of the d.o.f.s, solving the system in a coupled manner. And while that is perfect for enforcing solid mechanics constitutive laws, that coupled approach *tends* to be suboptimal from a pure convergence/performance standpoint. The details of these differences are difficult to cover without really getting into the weeds. Suffice to say, FEM methods have grown one way to serve primarily solid mechanics. FVM methods have grown another way (really TWO other ways, as density-based and pressure-based solvers are hugely different in their own right). These decades of accumulated differences has resulted in tool specialization that is hard to overcome. |

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 |