View Issue Details

IDProjectCategoryView StatusLast Update
0002947OpenFOAMBugpublic2018-05-27 11:30
ReporterStephanG Assigned Tohenry  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionsuspended 
PlatformGNU/LinuxOSUbuntuOS Version15.04
Product Versiondev 
Fixed in Versiondev 
Summary0002947: anisotropic conductivity and wall heat flux function object
DescriptionThere 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 ReproduceRun 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.
TagsNo tags attached.

Activities

StephanG

2018-05-21 18:28

reporter  

anisotropic.zip (364,874 bytes)

henry

2018-05-21 19:04

manager   ~0009611

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?

StephanG

2018-05-21 21:09

reporter   ~0009612

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

henry

2018-05-21 21:35

manager   ~0009613

OK that's fine, send the patch for testing.

tniemi

2018-05-22 06:55

reporter   ~0009614

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.

StephanG

2018-05-22 07:47

reporter   ~0009617

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?

tniemi

2018-05-22 10:04

reporter   ~0009618

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.

tniemi

2018-05-22 16:02

reporter   ~0009621

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.
anisotropicA_mod.zip (11,752 bytes)

StephanG

2018-05-23 16:38

reporter   ~0009635

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.

henry

2018-05-27 11:29

manager   ~0009660

Thanks for looking into this, please open a new report when you are ready to contribute the code.

henry

2018-05-27 11:30

manager   ~0009661

Awaiting contribution.

Issue History

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