2017-11-24 09:09 GMT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002127OpenFOAM[All Projects] Bugpublic2017-10-03 12:56
ReporterJoris.C 
Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
StatusnewResolutionopen 
PlatformGNU/LinuxOSUbuntuOS Version15.04
Product Version3.0.1 
Target VersionFixed in Version 
Summary0002127: Volumetric heat source in solid with anisotropic conductivity
DescriptionWhen 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 Reproducesh buildmesh.sh
chtMultiRegionFoam
TagsNo tags attached.
Attached Files

-Relationships
related to 0002043new turbulentTemperatureCoupledBaffleMixed doesn't get heat fluxes balance in case of anisotropic conductivity 
related to 0002302new wallHeatFlux utility: wrong calculation of heatfluxes using anisotropic kappa 
+Relationships

-Notes

~0006453

Joris.C (reporter)

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.

~0006455

tniemi (reporter)

Last edited: 2016-06-21 14:38

View 2 revisions

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.

~0006456

Joris.C (reporter)

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?

~0006457

tniemi (reporter)

Last edited: 2016-06-22 10:31

View 2 revisions

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.

~0006458

Joris.C (reporter)

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..

~0008803

okocha (reporter)

Any update on this?

Best Regards

MN

~0008817

StephanG (reporter)

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.
+Notes

-Issue History
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 View Revisions
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 View Revisions
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
+Issue History