View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002043 | OpenFOAM | Bug | public | 2016-04-04 17:08 | 2020-11-21 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 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. |
|
|
@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 |
|
|
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 |
|---|---|---|---|
| 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 | |
| 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 | |
| 2020-11-21 20:13 | henry | Assigned To | => henry |
| 2020-11-21 20:13 | henry | Status | new => closed |
| 2020-11-21 20:13 | henry | Resolution | open => suspended |
| 2020-11-21 20:13 | henry | Note Added: 0011713 |
