View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002127 | OpenFOAM | Bug | public | 2016-06-21 09:33 | 2020-11-21 20:14 |
| Reporter | Joris.C | Assigned To | henry | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | suspended | ||
| Platform | GNU/Linux | OS | Ubuntu | OS Version | 15.04 |
| Summary | 0002127: Volumetric heat source in solid with anisotropic conductivity | ||||
| Description | When using a volumetric heat source in a solid with anisotropic conductivity, more heat is generated than physically possible. In order to test this, I have set up a case with a fluid region coupled to a solid region, in which the heat generation occurs. The fluid is frozen and has a constant temperature at one boundary. The reason for the coupling is because someone encountered an issue with the wallHeatFlux utility in combination with anisotropic conductivity (http://www.cfd-online.com/Forums/openfoam-post-processing/150921-wallheatflux-constaniso-anisotropic-material.html), which I use to verify the heat fluxes. The test case in the attachment works for isotropic conductivity, but what doesn't work is the following: 1) Volumetric heat source and anisotropic properties (even kappa (7 7 7) instead of kappa 7) : the heat balance is not okay. While 0.09*0.02*0.005*200000 = 1.8 W should be generated inside the solid, almost double goes into the fluid. 2) The diffusion number changes when using kappa (7 7 7) instead of kappa 7. 3) When using frozen flow, the number controlling time steps should be the diffusion number as well, not the Courant number (which is zero). *) I did not encounter the bug described on the cfd online forum. However, I think this case is ideal to further test it if needed. | ||||
| Steps To Reproduce | sh buildmesh.sh chtMultiRegionFoam | ||||
| Tags | No tags attached. | ||||
|
|
|
|
|
This case is certainly connected to http://bugs.openfoam.org/view.php?id=2043. However, the case here is a basic issue, while the other case is more concerned about non-directional alignment of the boundary and kappa. |
|
|
I checked your test case, but it contains references to "Poseidon" and it does not run with standalone OpenFoam. However, I managed to get the case running and noticed your issue. I haven't worked with anisotropic conduction, but I tried to change the kappa type from solidThermo to directionalSolidThermo in solid T file and it seemed to solve the problem. Edit: I looked at the code and I think that if kappa is set to solidThermo, BC uses mag(kappa), which gives too large a value and messes up the boundary temperature calculation. Chancing kappa to directionalSolidThermo calculates conduction as n & kappa & n. |
|
|
|
|
|
Thank you! I made the edit in solid/T and it managed to give correct results at the fluid side. But: 1) Why doesn't the BC update itself according to the properties of the thermophysicalProperties file? 2) Diffusion number still changes 3) The request for the diffusion number when using frozen flow does not make sense *) Making the change above makes the issue posted on cfdonline show up: wallHeatFlux doesn't return the proper result for the solid region. How can I delete the first file I uploaded? |
|
|
1) I don't know the historical reason for this, but at the moment the BC works in such a way that the kappa type has to match with the thermophysicalProperties. There is also a lookup option available and in that case the BC (actually temperatureCoupledBase.C) checks the type of the kappa field to see if it is a scalar or tensor. So with lookup the BC should work in either case. 2) Diffusion number changes, because the solver calculates it using mag(kappa), which is larger than the individual components. I guess it could calculate it in some other way, but mag(kappa) is simple and probably always a safe choice. 3) You probably meant the Courant number? You are correct that it doesn't make any sense. However, it is not necessary to give it in the controlDict (I think it defaults to 1). In any case the value given for maxCo should not affect the time step calculation with frozenFlow. *) As stated in the forum, the wallHeatFlux utility does not understand anisotropy and it simply asks for scalar kappa, which is calculated as mag(kappa). However generally, when I looked at the bug http://bugs.openfoam.org/view.php?id=2043 I think that turbulentTemperatureCoupledBaffleMixed might not work very well with anisotropy in general case, if the temperature gradient is not aligned with the surface normal vector. As explained in that bug, the BC calculates q=(n & kappa & n)*SnGrad(T), while the diffusion term is in reality q=(kappa & grad(T)) & n. (laplacian also uses (n & kappa & n)*SnGrad(T), but it also has an additional correction term.) The two expressions may be the same in simple situations, but not generally. I also made an interesting observation when I decoupled the fluid and solid regions and just played around with the solid domain. If I rotated the mesh and used truly anisotropic kappa, the zeroGradient boundary condition did not guarantee that the wall was insulated. Even though the temperature has zeroGradient towards the wall, the heat flux may not be due to anisotropy. I made these checks by adding const fvPatchList& patches = mesh.boundary(); forAll(patches, patchi) { const fvPatch& currPatch = patches[patchi]; scalar patchM1 = gSum( hEqn().flux()().boundaryField()[patchi]); Info << " " << mesh.boundary()[patchi].name() << " " << patchM1 << endl; } to solveSolid.h. As I stated previously, I have no experience of anisotropic cases, but to me they seem quite tricky. |
|
|
1) It has to match in order to give the correct results. From a robust programming perspective, I expect OF to raise an error. 2) It is simple, but you can easily overestimate the diffusion number in case the kappa's differ by one or two orders of magnitude (my case) 3) no further comments *) Again, here at least a warning should be issued by OF You made interesting observations, this helps a lot for any patches, here and in the other thread.. |
|
|
Any update on this? Best Regards MN |
|
|
I have added three similar but simplified test cases to help resolve this issue. 1D conduction in x direction. A plot and comparison to the analytical solution is included. Source given in the Allrun script. For kappa 75 and kappa (75 0 0) the results are identical for isotropic and anisotopic conductivity. For kappa (75 10 0) the results differ if kappaMethod is set to solidThermo instead of directionalSolidThermo in the T boundary file of region solidA. The issue is hence not with the addition of heat generation but with the region coupling. Correct results can be obtained if directionalSolidThermo is used. A warning or error message should be added. |
|
|
Pending funding |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-06-21 09:33 | Joris.C | New Issue | |
| 2016-06-21 09:33 | Joris.C | File Added: heatGenerationTest.zip | |
| 2016-06-21 09:42 | Joris.C | Note Added: 0006453 | |
| 2016-06-21 14:25 | tniemi | Note Added: 0006455 | |
| 2016-06-21 14:38 | tniemi | Note Edited: 0006455 | |
| 2016-06-21 16:10 | Joris.C | File Added: heatGenerationTest_correct.zip | |
| 2016-06-21 16:12 | Joris.C | Note Added: 0006456 | |
| 2016-06-22 10:29 | tniemi | Note Added: 0006457 | |
| 2016-06-22 10:31 | tniemi | Note Edited: 0006457 | |
| 2016-06-22 10:45 | Joris.C | Note Added: 0006458 | |
| 2016-06-22 10:58 | wyldckat | Relationship added | related to 0002043 |
| 2016-10-21 10:16 | wyldckat | Relationship added | related to 0002302 |
| 2017-09-27 17:28 | okocha | Note Added: 0008803 | |
| 2017-10-03 12:56 | StephanG | File Added: TestKappa.tar.gz | |
| 2017-10-03 12:56 | StephanG | Note Added: 0008817 | |
| 2020-11-21 20:14 | henry | Assigned To | => henry |
| 2020-11-21 20:14 | henry | Status | new => closed |
| 2020-11-21 20:14 | henry | Resolution | open => suspended |
| 2020-11-21 20:14 | henry | Note Added: 0011714 |
