innerSqr() function in SSG model

ckpark · December 8, 2024, 17:23

Dear all,

While going through the transport equation of Reynolds stress tensor in SSG model of OpenFOAM foundation distribution, I came across a couple of differences compared to the definition in the original paper by Speziale in 1991.

The first difference is from the 4th term: $b_{ik}b_{kj}-1/3b_{mn}b_{mn}\delta_{ij}$ is defined in the source code. Instead of a simple inner product of two tensor (e.g. A&B), it is in the code: dev(innerSqr(b)).
When I went to look up the definition of innerSqr(), it did not look anything like $b_{ik}b_{kj}$ .

The second difference is from the 1st term: simply the $\bar{S}_{ij}$ being defined as dev(S) instead of simply S.

Does anyone know where these differences arise from or why are they implemented as such?

Thank you!
ckpark

Tobermory · December 9, 2024, 04:27

I am not sure which bit you are worried about ... b is a symmetric tensor

Code:

 inline Foam::SymmTensor<Cmpt>::SymmTensor
 (
     const Cmpt txx, const Cmpt txy, const Cmpt txz,
                     const Cmpt tyy, const Cmpt tyz,
                                     const Cmpt tzz
 )
 {
     this->v_[XX] = txx; this->v_[XY] = txy; this->v_[XZ] = txz;
                         this->v_[YY] = tyy; this->v_[YZ] = tyz;
                                             this->v_[ZZ] = tzz;
 }

so $b_{ik}b_{kj}$ is correctly calculated by the innerSqr function:

Code:

 //- Inner-sqr of a symmetric tensor
 template<class Cmpt>
 inline SymmTensor<Cmpt>
 innerSqr(const SymmTensor<Cmpt>& st)
 {
     return SymmTensor<Cmpt>
     (
         st.xx()*st.xx() + st.xy()*st.xy() + st.xz()*st.xz(),
         st.xx()*st.xy() + st.xy()*st.yy() + st.xz()*st.yz(),
         st.xx()*st.xz() + st.xy()*st.yz() + st.xz()*st.zz(),
  
         st.xy()*st.xy() + st.yy()*st.yy() + st.yz()*st.yz(),
         st.xy()*st.xz() + st.yy()*st.yz() + st.yz()*st.zz(),
  
         st.xz()*st.xz() + st.yz()*st.yz() + st.zz()*st.zz()
     );
 }

(write out the terms if you want to check this, noting the storage convention for symmetric tensors in OF).

And then in OF, dev(F) returns $F - 1/3 \delta_{ij} F_{ij}$ , which matches the expression you quoted $b_{ik}b_{kj}-1/3b_{mn}b_{mn}\delta_{ij}$ .

Am I missing something? Perhaps I misunderstood your initial question?

ckpark · December 9, 2024, 07:33

Thank you for your answer, Tobermory.

You're absolutely right, I mixed up the index notation. Is it then correct to say that innerSqr(b) represents $b_{ik}b_{jk}$ while b&b represents $b_{ik}b_{kj}$ ?

Do you perhaps have an idea on the second question in my original post where $\bar{S}_{ij}$ is computed as dev(S) instead of just S?

Tobermory · December 10, 2024, 07:26

For a symmetric tensor, like

, $b_{jk}=b_{kj}$ , and so innerSqr(b) represents both $b_{ik}b_{jk}$ and $b_{ik}b_{kj}$ . As does [LaTeX Error: Syntax error].

Why not just use &? I guess because innerSqr uses the symmetric tensor storage form, and is more compact? Dunno.

As for the second question, if the flow is incompressible (as was Speziale et al's assumption in their paper), then $znabla \cdot U = 0$ and $S \equiv dev(S)$ . Maybe OF made it deviatoric to force the term to have zero trace, i.e. to cater for non-incompressible flows or to improve convergence? Not sure.

December 8, 2024, 17:23	innerSqr() function in SSG model	#1
ckpark New Member CPark Join Date: Apr 2021 Location: Germany Posts: 13 Rep Power: 6	Dear all, While going through the transport equation of Reynolds stress tensor in SSG model of OpenFOAM foundation distribution, I came across a couple of differences compared to the definition in the original paper by Speziale in 1991. The first difference is from the 4th term: $b_{ik}b_{kj}-1/3b_{mn}b_{mn}\delta_{ij}$ is defined in the source code. Instead of a simple inner product of two tensor (e.g. A&B), it is in the code: dev(innerSqr(b)). When I went to look up the definition of innerSqr(), it did not look anything like $b_{ik}b_{kj}$ . The second difference is from the 1st term: simply the $\bar{S}_{ij}$ being defined as dev(S) instead of simply S. Does anyone know where these differences arise from or why are they implemented as such? Thank you! ckpark Last edited by ckpark; December 9, 2024 at 03:27.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
whats the cause of error?	immortality	OpenFOAM Running, Solving & CFD	13	March 24, 2021 07:15
[swak4Foam] swakExpression not writing to log	alexfells	OpenFOAM Community Contributions	3	March 16, 2020 18:19
[mesh manipulation] RefineMesh Error and Foam warning	jiahui_93	OpenFOAM Meshing & Mesh Conversion	4	March 3, 2018 11:32
[mesh manipulation] refineMesh Error	mohsen.boojari	OpenFOAM Meshing & Mesh Conversion	3	March 1, 2018 22:07
is internalField(U) equivalent to zeroGradient?	immortality	OpenFOAM Running, Solving & CFD	7	March 29, 2013 01:27

December 9, 2024, 07:33		#3
ckpark New Member CPark Join Date: Apr 2021 Location: Germany Posts: 13 Rep Power: 6	Thank you for your answer, Tobermory. You're absolutely right, I mixed up the index notation. Is it then correct to say that innerSqr(b) represents $b_{ik}b_{jk}$ while b&b represents $b_{ik}b_{kj}$ ? Do you perhaps have an idea on the second question in my original post where $\bar{S}_{ij}$ is computed as dev(S) instead of just S?

December 10, 2024, 07:26		#4
Tobermory Senior Member Join Date: Apr 2020 Location: UK Posts: 841 Rep Power: 16	For a symmetric tensor, like , $b_{jk}=b_{kj}$ , and so innerSqr(b) represents both $b_{ik}b_{jk}$ and $b_{ik}b_{kj}$ . As does [LaTeX Error: Syntax error]. Why not just use &? I guess because innerSqr uses the symmetric tensor storage form, and is more compact? Dunno. As for the second question, if the flow is incompressible (as was Speziale et al's assumption in their paper), then $znabla \cdot U = 0$ and $S \equiv dev(S)$ . Maybe OF made it deviatoric to force the term to have zero trace, i.e. to cater for non-incompressible flows or to improve convergence? Not sure.