View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002947 | OpenFOAM | Bug | public | 2018-05-21 18:28 | 2018-05-27 11:30 |
Reporter | StephanG | Assigned To | henry | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | suspended | ||
Platform | GNU/Linux | OS | Ubuntu | OS Version | 15.04 |
Product Version | dev | ||||
Fixed in Version | dev | ||||
Summary | 0002947: anisotropic conductivity and wall heat flux function object | ||||
Description | There are four open issues (0001991, 0002302, 0002127 and 0002043) regarding anisotropic conductivity, the wallHeatFlux function object / calculation of the heat fluxes. From my perspective these can be closed. I have tested the mentioned issues (5 cases attached) and found that chtMultiRegion functions properly with anisotropic conductivity (and added heat sources as well). References are given in the Allrun files. A gnuplot diagram is created with the correct analytic solution. The wallHeatFlux function object however reports wrong heat fluxes for them. The error here is the line calcHeatFlux(thermo.alpha(), thermo.he(), wallHeatFlux); in wallHeatFlux.C. The issue is simply that thermo.alpha() is not the anisotropic conductivity. It should hence be replaced by something like: if (!thermo.isotropic()) { // Ouput either error message or calculate the correct values: // const volSymmTensorField& aniAlpha = lookupObject<volSymmTensorField>("aniAlpha"); // calcHeatFlux(aniAlpha, thermo.he(), wallHeatFlux); // This would require a small change in the calcHeatFlux part as well. } else { calcHeatFlux(thermo.alpha(), thermo.he(), wallHeatFlux); } | ||||
Steps To Reproduce | Run the attached cases and check the heat fluxes chtMultiRegionFoam -postProcess -func wallHeatFlux -region solidA chtMultiRegionFoam -postProcess -func wallHeatFlux -region solidB The correct value here is always reported in region solidB, since this one has an isotropic value. | ||||
Tags | No tags attached. | ||||
|
|
|
It is not quite clear how your proposal fixes the problem as the functionality to calculate the anisotropic flux is commented-out: // Ouput either error message or calculate the correct values: // const volSymmTensorField& aniAlpha = lookupObject<volSymmTensorField>("aniAlpha"); // calcHeatFlux(aniAlpha, thermo.he(), wallHeatFlux); // This would require a small change in the calcHeatFlux part as well. does the zip file contain the complete functionality? |
|
No the zip file only contains test cases to showcase that there is no solver error with anisotropic media. Which was one concern in the mentioned issues. The test cases match the analytic solution. The function object call however outputs a wrong heat flux. I have not provided a patch, just isolated the issue and added test cases to test an eventual fix. Any fix that shows the same output for chtMultiRegionFoam -postProcess -func wallHeatFlux -region solidA chtMultiRegionFoam -postProcess -func wallHeatFlux -region solidB for all test cases will work. My suggestion would be to add an calcHeatFluxAnIso function which is called like mentioned above: if (!thermo.isotropic()) { const volSymmTensorField& aniAlpha = lookupObject<volSymmTensorField>("aniAlpha"); calcHeatFluxAnIso(aniAlpha, thermo.he(), wallHeatFlux); } else { calcHeatFlux(thermo.alpha(), thermo.he(), wallHeatFlux); } and in it simply calculate the boundary value as n & aniAlpha & n |
|
OK that's fine, send the patch for testing. |
|
Just to comment, using the (n & aniAlpha & n)*snGrad-form will still cause conservation issues if the boundary is not properly aligned with the aniAlpha (I think n has to be an eigenvector of aniAlpha for this formulation to work). Of course, this same limitation exists with eg. turbulentTemperatureCoupledBaffleMixed boundary condition and making this change would make the BC and wallHeatFlux consistent. However, from the solver point of view, the flux to the boundary won't be the (n & aniAlpha & n)*snGrad what the BC and wallHeatFlux assume it is. |
|
This is why I attached the test cases. Can you give an example using these, that shows the conservation issues you mentioned. Because I have tested arbitrary directions and couldn't spot a deviation. The test cases have 2 regions connected with turbulentTemperatureCoupledBaffleMixed. Hence this deviation between directions should be visible. I'd like to ask you to take a look If I am missing something. How would you calculate the flux instead of (n & aniAlpha & n)*snGrad? |
|
I can take a look if I can demonstrate the problem. In principle, the issue should occur due to the fact that (n & aniAlpha & n)*snGrad(T) != (aniAlpha * grad(T)) & n in all cases. |
|
Ok, I think I found a reasonably straightforward example. (It was a bit difficult, as the code often works correctly as you have observed). I have uploaded a modified anisotropicA-case with the following changes: - Added 1 W/m3 source to region A, total source is 0.032 W - Changed the boundary conditions to fixed value 273.15 for region B to make the problem symmetric - Changed the coordinateSystem of region A to (1 0 0) and (0 1 0) so that the faces are not aligned with kappa Assumed behaviour: region A heats up and the heat flows to region B and out of the domain, energy is conserved. If kappa is (0.56 0.56 0) we get the expected result: 0.016 W out from left and right, total 0.032 W. However, if kappa is eg. (0.56 10 0) we get a total flux of 0.0615 W, ie. almost the double. In opposite direction, eg. (0.56 0.1 0) gives a total flux of 0.0285 W. I wish to emphasize, that the issues here are not in the solver itself, but in the coupling BC, which incorrectly estimates the anisotropic flux in a general case. |
|
Thank you. I can now see why my test cases did not show the issue. The test case needs a 2D resulting temperature distribution. Otherwise the results will be correct even for an arbitrary direction of kappa in regards to the boundary. This clearly shows, that the current implementation will undoubtedly produce wrong results for arbitrary meshes (if more than one domain is considered of course). Hence 3 changes are necessary: temperatureCoupledBase needs to be changed from the current n & aniAlpha & n method turbulentTemperatureCoupledBaffleMixed and turbulentTemperatureRadCoupledMixed need to be reformulated. Which is no minor change. and the wallHeatFlux function object needs a small change as well. I'll look into this, but this might take a while. |
|
Thanks for looking into this, please open a new report when you are ready to contribute the code. |
|
Awaiting contribution. |
Date Modified | Username | Field | Change |
---|---|---|---|
2018-05-21 18:28 | StephanG | New Issue | |
2018-05-21 18:28 | StephanG | File Added: anisotropic.zip | |
2018-05-21 19:04 | henry | Note Added: 0009611 | |
2018-05-21 21:09 | StephanG | Note Added: 0009612 | |
2018-05-21 21:35 | henry | Note Added: 0009613 | |
2018-05-22 06:55 | tniemi | Note Added: 0009614 | |
2018-05-22 07:47 | StephanG | Note Added: 0009617 | |
2018-05-22 10:04 | tniemi | Note Added: 0009618 | |
2018-05-22 16:02 | tniemi | File Added: anisotropicA_mod.zip | |
2018-05-22 16:02 | tniemi | Note Added: 0009621 | |
2018-05-23 16:38 | StephanG | Note Added: 0009635 | |
2018-05-27 11:29 | henry | Note Added: 0009660 | |
2018-05-27 11:30 | henry | Assigned To | => henry |
2018-05-27 11:30 | henry | Status | new => closed |
2018-05-27 11:30 | henry | Resolution | open => suspended |
2018-05-27 11:30 | henry | Fixed in Version | => dev |
2018-05-27 11:30 | henry | Note Added: 0009661 |