2017-12-15 23:46 GMT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002043OpenFOAM[All Projects] Bugpublic2017-10-03 13:24
Reporterokocha87 
Assigned To 
PriorityurgentSeveritymajorReproducibilityalways
StatusnewResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0002043: turbulentTemperatureCoupledBaffleMixed doesn't get heat fluxes balance in case of anisotropic conductivity
DescriptionIn 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
TagsNo tags attached.
Attached Files

-Relationships
related to 0002127new Volumetric heat source in solid with anisotropic conductivity 
related to 0002302new wallHeatFlux utility: wrong calculation of heatfluxes using anisotropic kappa 
+Relationships

-Notes

~0006102

wyldckat (updater)

@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 fluid-solid interface should actually be, preferably based on data drawn from real experiments?

Because the current implementation of this two-sided boundary is essentially doing an average balance between the two sides. And if one of the sides is non-conductive, then the heat will stay only on the conductive side, at least across the interface.

~0006103

okocha87 (reporter)

@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 + (1-f) (Tb + grad_ref/delta_b)

from (1): Tc = f*Ta + (1-f)*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

~0006115

wyldckat (updater)

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

~0006459

tniemi (reporter)

Last edited: 2016-06-22 11:31

View 2 revisions

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.

~0008802

okocha (reporter)

Any update on this?

Best regards

MN

~0008818

StephanG (reporter)

@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.
+Notes

-Issue History
Date Modified Username Field Change
2016-04-04 17:08 okocha87 New Issue
2016-04-09 23:40 wyldckat Note Added: 0006102
2016-04-11 13:07 okocha87 Note Added: 0006103
2016-04-14 22:52 wyldckat Note Added: 0006115
2016-06-22 10:53 tniemi Note Added: 0006459
2016-06-22 10:58 wyldckat Relationship added related to 0002127
2016-06-22 11:31 tniemi Note Edited: 0006459 View Revisions
2016-10-21 10:16 wyldckat Relationship added related to 0002302
2017-09-27 17:23 okocha Note Added: 0008802
2017-10-03 13:24 StephanG File Added: anisotropic.tar.gz
2017-10-03 13:24 StephanG Note Added: 0008818
+Issue History