View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003518 | OpenFOAM | Bug | public | 2020-07-07 19:24 | 2020-11-21 19:43 |
Reporter | jnonnema | Assigned To | henry | ||
Priority | high | Severity | major | Reproducibility | always |
Status | closed | Resolution | suspended | ||
Platform | Linux | OS | Scientific Linux | OS Version | 6.3 |
Summary | 0003518: Heat balance not closed in quarter of hollow cylinder with anisotropic thermal conductivity in cylindrical coordinate system. | ||||
Description | When calculating the steady state temperature distribution in a quarter of a hollow cylinder (end part) with an anisotropic thermal conductivity defined in a cylindrical coordinate system, connected to a cuboid (straight part) with anisotropic thermal conductivity defined in a Cartesian coordinate system, both with uniform volumetric heat generation, more heat is generated within the end part than physically possible (or given at the input). The cause is within the end part because, when changing the conductivity in the end part to isotropic or anisotropic with the same conductivity in the three directions (r, θ, z), the heat balance is closed. When using an anisotropic conductivity eg (1, 100, 1), probably the wrong kappa value is used when calculating the heat flux within the turbulentTemperatureCoupledBaffleMixed boundary condition. The same issue was encountered before for the straight part, but changing the kappaMethod from solidThermo to directionalSolidThermo solved that issue for the straight part. For the end part however, this does not solve the issue. | ||||
Steps To Reproduce | A test geometry was set up to reproduce the issue with three cases: - Test-case with anisotropic thermal conductivity → with the issue (Issue_Aniso_ani) - Test-case with isotropic thermal conductivity → no issue (Issue_Aniso_iso1) - Test-case with isotropic thermal conductivity, but defined as anisotropic with the same conductivity in the three directions → no issue (Issue_Aniso_iso3) Open test case (Issue_Aniso_ani) and run the ‘Allrun’ file. Afterwards, run the ‘Allpostprocess’ file to check the heat balance: - Within ‘Issue_Aniso_ani\postProcessing\end\wallHeatFlux\0\wallHeatFlux.dat’ or ‘Issue_Aniso_ani\postProcessing\straight\wallHeatFlux\0\ wallHeatFlux.dat’, it can be seen that the heat flux from ‘end’ to ‘straight’ is respectively 15.56157W or 15.53741W, which is 5.9284W higher than the input value 9.609W - Within ‘Issue_Aniso_ani\postProcessing\straight\patchAverage(name=s1Conv,T)\0\ surfaceFieldValue.dat’, the area and average surface temperature of the cooled surfaces can be found. Calculating the heat flux with q=hA(T_avg-T_inf)=2000*0.001*( 317.9635-300)=35.927, which is 5.927W higher than the input value of 30W. This value is very close to the excess losses coming from the end part, which shows that the issue is in the end part. A repetition of the previous steps for both other test-cases with isotropic thermal conductivity in the end part (Issue_Aniso_iso1 and Issue_Aniso_iso3), shows correct results (heat balance closed). | ||||
Additional Information | This issue is related to issues: - 0002127: Volumetric heat source in solid with anisotropic conductivity - 0002043: turbulentTemperatureCoupledBaffleMixed doesn't get heat fluxes balance in case of anisotropic conductivity - 0002302: wallHeatFlux utility: wrong calculation of heatfluxes using anisotropic kappa Some details of the test geometry: the geometry consists of a quarter of a hollow cylinder (end part) with: - an anisotropic thermal conductivity (1,100,1) defined in a cylindrical coordinate system (r, θ, z) - inner radius 10mm, outer radius 20mm and height 10mm - heat generation of 9.6090W connected to a cuboid (straight part) with: - anisotropic thermal conductivity (1,1,100) defined in a Cartesian coordinate system (x,y,z) - height and width of 10mm, length of 50mm - heat generation of 20.3910W - top and inner side cooled with convective boundary condition (h=2000W/m²K, T=300K) All other surfaces are adiabatic. Additional information: - solver chtMultiRegionFoam | ||||
Tags | No tags attached. | ||||
|
|
|
do we have any updates on this issue? I ran into this problem, too, using chtMultiRegionFoam from OF version 7 (I may check version 8 as well). For some solid region, in case of anisotropic thermal conductivity, the output of wallHeatFlux functionObject is quite strange, evidently wrong -- even though the simulation runs fine and overall enthalpy balance is correct. In the same case, setting an isotropic kappa, also the output of wallHeatFlux functionObject is correct. |
|
@michael.mueller-wrd This should resolve the consistency problem with the wallHeatFlux functionObject which previously had NO support for anisotropic thermal conductivity: commit f15d150ca8daf75906b4952608868399e0ea6dae (HEAD -> master, origin/master, origin/HEAD) Author: Henry Weller <http://cfd.direct> Date: Fri Sep 25 16:09:18 2020 +0100 chtMultiRegionFoam, heSolidThermo: Moved the solid heat flux model into heSolidThermo and changed to be an energy implicit correction to a temperature gradient based heat-flux. This formulation is both energy conservative and temperature consistent. The wallHeatFlux functionObject has been updated to use a consistent heat-flux from the heSolidThermo. However this does not correct the issue reported here which relates to the incomplete handling of anisotropy in the turbulentTemperatureCoupledBaffleMixed BC. We need funding to work on this issue which requires a rewrite of the handling of anisotropic thermal conductivity. |
|
Pending funding. |
Date Modified | Username | Field | Change |
---|---|---|---|
2020-07-07 19:24 | jnonnema | New Issue | |
2020-07-07 19:24 | jnonnema | File Added: Aniso_issue.zip | |
2020-09-18 11:55 | michael.mueller-wrd | Note Added: 0011513 | |
2020-09-25 16:16 | henry | Note Added: 0011526 | |
2020-11-21 19:43 | henry | Assigned To | => henry |
2020-11-21 19:43 | henry | Status | new => closed |
2020-11-21 19:43 | henry | Resolution | open => suspended |
2020-11-21 19:43 | henry | Note Added: 0011699 |