View Issue Details
ID  Project  Category  View Status  Date Submitted  Last Update 

0002043  OpenFOAM  Bug  public  20160404 17:08  20201121 20:13 
Reporter  okocha87  Assigned To  henry  
Priority  urgent  Severity  major  Reproducibility  always 
Status  closed  Resolution  suspended  
Summary  0002043: turbulentTemperatureCoupledBaffleMixed doesn't get heat fluxes balance in case of anisotropic conductivity  
Description  In my opinion recovering kappa through directionalSolidThermo model which returns the scalar n*K*n is not correct. And in fact I end up with an imbalance in the heat fluxes between the solid side and the fluid side. It gives correct results only if the boundary is orthogonal to the direction of the conductivity. Not sure how to fix this issue given the particular implementation of the boundary condition as a mixed patch. I'm using openfoam 2.3  
Tags  No tags attached.  

@okocha87: Took me a few minutes to wrap my head around your statements. I think I understand some of your concerns about the current implementation, but still, so far I can't see exactly what's the problem. Have you looked into any specific evidence to what the real fluidsolid interface should actually be, preferably based on data drawn from real experiments? Because the current implementation of this twosided boundary is essentially doing an average balance between the two sides. And if one of the sides is nonconductive, then the heat will stay only on the conductive side, at least across the interface. 

@wyldckat: Thanks for your note. I try to explain better: as far as I understand turbulentTemperatureCoupledBaffleMixed boundary condition ensures heat fluxed balance between the two sides imposing a mixed value boundary condition: Qa = Qb > Ka (Ta Tc)/delta_a = Kb (Tc  Tb)/delta_b (1) mixed b.c. : Tc = Tref + (1f) (Tb + grad_ref/delta_b) from (1): Tc = f*Ta + (1f)*Tb where f = Ka/delta_a * 1/(Kb/delta_b + Ka/delta_a) so comparing the two expression we get Tref = Ta and grad_ref = 0 In the case of anisotropic conductivity kappa is given by the directionalSolidThermo model as n*kappa*n (which is a scalar field). My feeling is that OpenFOAM doesn't give correct results if the direction of the anisotropic conductivity is not orthogonal to the boundary patch. This feeling is confirmed by the fact that I get different results by changing in the heat balance function object from (where kappa is a tensor): q_n = (n* kappa * n) snGrad(T) to q_n = n * q = n * (kappa * grad(T)) What do you think? Thanks again Marco 

Hi Marco, At a first glance, I suspect that using "grad(T)" could potentially negate part of the effect of the "kappa" tensor. My feeling here is that this could potentially lead to excess heat being carried over with using "grad(T)". On the other hand, "grad(T)" will likely be more aligned with the direction of the anisotropic conduction, given that it would be the path of least effort... Hold on, what if the solid is flooded with the same temperature? There would be no gradient inside the solid, therefore the resulting "kappa" on the surface would be zero as well!? I say this because the "grad(T)" calculation would be limited to the solid side... mmm... without testing, I'm not certain which is which, namely if "grad(T)" would give the correct gradient on the boundary surface. There are two ways I can think of for proving which implementation is correct: 1 We could have a simple conduction case with 3 consecutive solids. The one in the middle will be different in two cases: a) one case is isotropic; b) the other anisotropic, where the solid is also distorted in the same direction of the 'tropic. 2 Or have the analytical proof, which gives the calculations as to why this is so. I'm guessing that some book on heat conducting composite materials might have this expression? If you could help with either one of the solutions, it would make it a lot easier to diagnose and to fix this, if there is an issue with it. Best regards, Bruno 

I commented this bug in bugs.openfoam.org/view.php?id=2127 , which is partly related to this. I think that the observation by okocha87 is correct in the sense that q_n should be calculated as q_n = (kappa * grad(T)) & n. For instance if we look at the fvcLaplacian in gaussLaplacianScheme.C, it calculates (n* kappa * n) snGrad(T), but it also adds gammaSnGradCorr(SfGammaCorr, vf) term. If I understood the code correctly the whole expression is (n & kappa & n)*snGrad(T) + (n & kappa  n & kappa & n & n) & grad(T)). The last term (n & kappa & n & n) & grad(T) is roughly the same as (n & kappa & n)*(grad(T) & n) which is (n & kappa & n)*snGrad(T). So what is left is (n & kappa) & grad(T). However, I think that the overall problem here is that a lot of code assumes that q_n can be expressed as kappa*snGrad(T), such as the wallHeatFlux tool. I'm not familiar with anisotropy, so I don't know what the true physical boundary conditions should be. However, if kappa is anisotropic at the patch, the (n* kappa * n) snGrad(T) expression is not consistent with the laplacian and there can be balance issues. 

Any update on this? Best regards MN 

@okocha I quickly tried creating a test cases that proves your point. The attached case however looks similar to the sources provided in the Allrun script. Since i don't normally do calculations with anisotropic media I don't know a good source for such a comparison. You probably need to provide a test case that illustrates that the current implementation is wrong before a change is made. The attached case might help you with that. 

Pending funding 
Date Modified  Username  Field  Change 

20160404 17:08  okocha87  New Issue  
20160409 23:40  wyldckat  Note Added: 0006102  
20160411 13:07  okocha87  Note Added: 0006103  
20160414 22:52  wyldckat  Note Added: 0006115  
20160622 10:53  tniemi  Note Added: 0006459  
20160622 10:58  wyldckat  Relationship added  related to 0002127 
20160622 11:31  tniemi  Note Edited: 0006459  
20161021 10:16  wyldckat  Relationship added  related to 0002302 
20170927 17:23  okocha  Note Added: 0008802  
20171003 13:24  StephanG  File Added: anisotropic.tar.gz  
20171003 13:24  StephanG  Note Added: 0008818  
20201121 20:13  henry  Assigned To  => henry 
20201121 20:13  henry  Status  new => closed 
20201121 20:13  henry  Resolution  open => suspended 
20201121 20:13  henry  Note Added: 0011713 