
[Sponsors] 
Potentially redundant set of computations for G object within turbulence models 

LinkBack  Thread Tools  Search this Thread  Display Modes 
August 16, 2020, 08:53 
Potentially redundant set of computations for G object within turbulence models

#1 
Senior Member
Herpes Free Engineer
Join Date: Sep 2019
Location: The Home Under The Ground with the Lost Boys
Posts: 932
Rep Power: 12 
Hi,
Some of the turbulence models compute G (i.e. the turbulent kinetic energy production rate due to the anisotropic part of the stress tensor). For example, in kEpsilon: Code:
volScalarField::Internal G ( this>GName(), nut.v()*(dev(twoSymm(tgradU().v())) && tgradU().v()) ); tgradU.clear(); Any tensor can be divided into its symmetric and antisymmetric parts. And any doubleinner product of a symmetric tensor and an antisymmetric tensor is (as far as I know) always zero. Therefore, the above doubleinner product can be reduced between two symmetric tensors without losing any level of accuracy in the final outcome. Question: Is there any reason why such reduction is/should not performed to your knowledge? Such reduction will help to considerably reduce the computational costs.
__________________
The OpenFOAM community is the biggest contributor to OpenFOAM: User guide/Wiki1/Wiki2/Code guide/Code Wiki/Journal Nilsson/Guerrero/Holzinger/Holzmann/Nagy/Santos/Nozaki/Jasak/Primer Governance Bugs/Features: OpenFOAM (ESIOpenCFDTrademark) Bugs/Features: FOAMExtend (WikkiFSB) Bugs: OpenFOAM.org How to create a MWE New: Forkable OpenFOAM mirror 

August 16, 2020, 15:22 

#2  
New Member
Wenyuan Fan
Join Date: Mar 2017
Posts: 27
Rep Power: 9 
Hi,
Have you made tests to support the following statement? Quote:
Also, the native implementation is consistent with the definition. 

August 17, 2020, 04:02 

#3  
Senior Member
Herpes Free Engineer
Join Date: Sep 2019
Location: The Home Under The Ground with the Lost Boys
Posts: 932
Rep Power: 12 
Quote:
 The cost reduction comes from the fact that there would need a single symmetric tensor instead of a symmetric tensor and full tensor. If such reduction is possible (and I think it is without losing generality), there will not be two symmetric tensors to doubleproduct, but only a single one. Instead of storing and computing 18 floatingpoint numbers, there will be only 6. So, the save would be 12 floatingpoint numbers per cell to compute and to store (9 from the tensor, 3 from the symmetric tensor).  Also, please note that the gradient operation is the one of the most expensive standalone operations in OpenFOAM (though still not sure, the symmetrized gradient can be computed without computing the full gradient in OpenFOAM).  In fact, the same reduction is held in [Pope, Turbulent flows, p. 126]. That's what encouraged me to inspect the possibility. Quote:
I kindly don't think so. No contradiction I see. Many thanks for your answers.
__________________
The OpenFOAM community is the biggest contributor to OpenFOAM: User guide/Wiki1/Wiki2/Code guide/Code Wiki/Journal Nilsson/Guerrero/Holzinger/Holzmann/Nagy/Santos/Nozaki/Jasak/Primer Governance Bugs/Features: OpenFOAM (ESIOpenCFDTrademark) Bugs/Features: FOAMExtend (WikkiFSB) Bugs: OpenFOAM.org How to create a MWE New: Forkable OpenFOAM mirror 

August 17, 2020, 05:42 

#4  
New Member
Wenyuan Fan
Join Date: Mar 2017
Posts: 27
Rep Power: 9 
Hi,
Quote:
The doubleinnerproduct operator for a symmetric tensor and a full tensor is defined as Code:
// Doubleinnerproduct of a SymmTensor and a Tensor template<class Cmpt> inline Cmpt operator&&(const SymmTensor<Cmpt>& st1, const Tensor<Cmpt>& t2) { return ( st1.xx()*t2.xx() + st1.xy()*t2.xy() + st1.xz()*t2.xz() + st1.xy()*t2.yx() + st1.yy()*t2.yy() + st1.yz()*t2.yz() + st1.xz()*t2.zx() + st1.yz()*t2.zy() + st1.zz()*t2.zz() ); } The same operator for two symmetric tensors is defined as Code:
// Doubledotproduct between a symmetric tensor and a symmetric tensor template<class Cmpt> inline Cmpt operator&&(const SymmTensor<Cmpt>& st1, const SymmTensor<Cmpt>& st2) { return ( st1.xx()*st2.xx() + 2*st1.xy()*st2.xy() + 2*st1.xz()*st2.xz() + st1.yy()*st2.yy() + 2*st1.yz()*st2.yz() + st1.zz()*st2.zz() ); } Quote:
Also, please note that this piece of code is only a tiny part of the turbulence model, and only involves most basic operations, e.g. + and *. Usually, the pressure Poisson equation requires much more time to solve than the turbulence model does. So I would say the reduction would be negligible in terms of overall simulation time. Quote:


August 17, 2020, 06:44 

#5 
Senior Member
Herpes Free Engineer
Join Date: Sep 2019
Location: The Home Under The Ground with the Lost Boys
Posts: 932
Rep Power: 12 
Hi,
I am afraid that you have also misunderstood some of my remarks even though I made a summation mistake , i.e. I have never talked about the number of floatingpoint operations, but the floatingpoint numbers themselves.  Tensor<Cmpt> stores 9 elements, i.e. grad(U).  SymmTensor<Cmpt> stores 6 elements, i.e. symm(grad(U)).  These kept stored in memory no matter how many of them were used in the doubleinner product of a SymmTensor and a Tensor.  So, in total we have 15 elements per cell in memory.  The potential reduction will require to store a single SymmTensor<Cmpt>, i.e. symm(grad(U)), which has 6 elements.  The save for the memory storage, allocation and deallocation, will then be 9 elements per cell per iteration step. grad(U) might or not kept in the memory if not cached, but the allocation and deallocation have their own cost, not to mention the peak memory usage, and limiting the transfers to the CPU cache.  The doubleinner product of a SymmTensor and Tensor has 9 multiplications+8 summations.  The doubleinner product of a (different) SymmTensor and SymmTensor has 6 multiplications + 5 summations, since the compilationtime constant "2" will definitely be optimised away.  Further the doubleinner product of the same SymmTensor can be coded to reduce the above (magSqr?).  It seems that I forgot to add "whether" in the sentence: "(though still not sure whether the symmetrized gradient can be computed without computing the full gradient in OpenFOAM)." Therefore, there is no such symmetricgradient function (yet), but assuming if we would have, we would even further reduce the cost.  Poisson equation solution is held by a set of standalone operations, but gradient computation function is a standalone operation as I said, and I argue that it is one of the most expensive standalone functions. I did not compare the cost of both, since one is apple, another is orange.  I think it seems that the reduction is doable (I have found that that exact reduction had been carried out, and hardcoded in realizableKE), but not preferable in terms of the arguments you have provided. Fair enough. Many thanks for your remarks, and contribution. Highly appreciated.
__________________
The OpenFOAM community is the biggest contributor to OpenFOAM: User guide/Wiki1/Wiki2/Code guide/Code Wiki/Journal Nilsson/Guerrero/Holzinger/Holzmann/Nagy/Santos/Nozaki/Jasak/Primer Governance Bugs/Features: OpenFOAM (ESIOpenCFDTrademark) Bugs/Features: FOAMExtend (WikkiFSB) Bugs: OpenFOAM.org How to create a MWE New: Forkable OpenFOAM mirror 

August 17, 2020, 07:50 

#6  
New Member
Wenyuan Fan
Join Date: Mar 2017
Posts: 27
Rep Power: 9 
Hi,
Quote:
Quote:
Currently, most turbulence models are written in a manner that makes maintenance easier by avoiding code duplication. The side effect is that it might not be the most efficient form for some flows, especially singlephase strict incompressible flows. 

August 17, 2020, 12:17 

#7 
Senior Member
Herpes Free Engineer
Join Date: Sep 2019
Location: The Home Under The Ground with the Lost Boys
Posts: 932
Rep Power: 12 
Sure, thank you.
Just out of curiosity now (let's forget about the cost/code maintenance issue): I think, this reduction can be applied to compressible flows as well? Do you think I miss a point in this concluding remark?
__________________
The OpenFOAM community is the biggest contributor to OpenFOAM: User guide/Wiki1/Wiki2/Code guide/Code Wiki/Journal Nilsson/Guerrero/Holzinger/Holzmann/Nagy/Santos/Nozaki/Jasak/Primer Governance Bugs/Features: OpenFOAM (ESIOpenCFDTrademark) Bugs/Features: FOAMExtend (WikkiFSB) Bugs: OpenFOAM.org How to create a MWE New: Forkable OpenFOAM mirror 

August 17, 2020, 14:59 

#8 
New Member
Wenyuan Fan
Join Date: Mar 2017
Posts: 27
Rep Power: 9 
I agree with you. In the compressible flow case, one needs to play with the diagonal of the symmetric matrix to calculate the extra term.
Anyway, this topic is interesting. I would appreciate if you could share your findings in the future. 

Tags 
theory, turbulence models 
Thread Tools  Search this Thread 
Display Modes  


Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Table bounds warnings at: END OF TIME STEP  CFXer  CFX  4  July 16, 2020 23:44 
yPlus function object and transitional turbulence models  gflorent  OpenFOAM PostProcessing  0  March 26, 2020 11:33 
Multiphase Turbulence Models  im_lenny  OpenFOAM Running, Solving & CFD  8  January 31, 2019 10:37 
boundaryFoam, axisymmetry and turbulence models  thomas_toulorge  OpenFOAM Running, Solving & CFD  0  May 12, 2011 13:05 
OF 1.6  Ubuntu 9.10 (64bit)  GLIBCXX_3.4.11 not found  piprus  OpenFOAM Installation  22  February 25, 2010 13:43 