View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001879||OpenFOAM||Bug||public||2015-10-27 11:52||2016-01-17 12:19|
|Summary||0001879: Possible bug in wallHeatFlux|
|Description||The same computation of the wall heat flux gives different results if done inside a solver or using the utility wallHeatFlux. The latter are probably wrong; the problem is probably related to the effective thermal diffusivity.|
|Steps To Reproduce||In this utility the wall heat flux is computed using the effective thermal diffusivity alphaEff and the enthalpy/internal energy gradient.|
I added exactly the same computation for the wall heat flux directly in a solver (chtMultiregionFoam, unsteady RANS simulation with frozen flow field and using alphatJayatillekeWallFunction) in order to compute the overall energy balance for the fluid domain: the energy balance is satisfied and so the computed wall heat flux is correct. The problem is that if I compute the wall heat flux using the utility "wallHeatFlux" I get sensibly different values (1.83 times).
Analysing the problem I found out that the error is directly related to the effective thermal diffusivity (and maybe it is more in general connected to how the turbulence model is loaded/created in the utility).
The value for the effective diffusivity used in the two situations is different: the area-weighted thermal diffusivity used in the utility is 1.83 times higher than the one used in the solver but in both cases it is defined as turbulence.alphaEff()!
I modified the utility computing the effective diffusivity by adding up the turbulent thermal diffusivity alphat (BUT read using IOobject) and the molecular thermal diffusivity thermo.alpha(). In this case I get the correct diffusivity (that is in practice only the molecular one since alphat on the wall patch is zero) and therefore obtain the correct wall heat flux.
|Additional Information||I can provide a fast test case (with frozen flow field). However, since I need to include the multiregion mesh (built using Salome), 2 Mb will not be enough.|
|Tags||No tags attached.|
Could you test the same case in OpenFOAM-dev?
I have rewritten the turbulence model library and handling of thermal diffusivity for OpenFOAM-dev which may resolve the problem and if not any further development to fix the problem will be done in this version.
||I don't have OpenFOAM-dev installed and unfortunately I cannot do that rapidly since our computers are managed by the IT service and I have to ask them about it to avoid possible conflicts. I can try to do that in the next days. Thank you.|
||@emacchi: If installing OpenFOAM-dev isn't possible, then please provide a simple test case for reproducing this issue, preferably one based on the tutorials available in OpenFOAM.|
For now I installed OpenFOAM-dev on a virtual machine to check this issue.
First of all I fixed the chtMultiRegion solver (only the createFluidFields.H file) to add the support for hRef (if you want I can upload the file). This was done for other p_rgh based solvers but not for this one, is there a reason?
It seems that my problem is connected to the alphat boundary values on the walls. During a simulation with "frozenFlow false" there are no problems: the alphat boundary values (!= 0 at the initial time) are != 0 also at the next times. This does not happens when "frozenFlow" is set to true; in this case, despite the alphat boundary values are != 0 at the initial time, at the next times the boundary values are set to 0. However something strange happened in the last test I did yesterday.
Please find hereinafter how I proceeded:
-computed nut and fixed the boundary conditions (OF-2.3 uses mut);
-run a transient (but isothermal) simulation (frozenFlow false) for a few seconds (3 s) starting from the flow solution obtained from OF-2.3 (to take into account possible changes in the model from the two OF versions). Please note that the wall alphat boundary values are != 0 at both t=0 and t=3 s;
-run a transient non-isothermal simulation with frozenFlow true starting from 3 s up to 663 s. Please note for all the times the alphat boundary values are strangely set to 0;
-restarted the previous simulation (w/ frozenFlow true) starting from 663 s (note that at this time alphat on wall boundaries is 0) and run it until t=1440 s. Very strangely now at each time the alphat boundary values are != 0.
This behaviour is very strange. When I get home I will try to check the results again and later I will try to install OpenFOAM-dev on my workstation so that I can work with it more easily.
OpenFOAM-dev: commit fe3916e09a6ea9d95dd0615773bd451a0556e584
OpenFOAM-3.0.x: commit 9cf015605d4cb58ff02808d457d06f7a0ce11838
chtMultiRegionFoam, chtMultiRegionSimpleFoam, buoyantPimpleFoam, buoyantSimpleFoam: Added support for hRef
Is this issue now resolved?
Thank you for adding the support for hRef to the other solvers.
Unfortunately something more urgent came up and I could not check the issue again. I will check by the end of the week if the problem persist.
Resolved in OpenFOAM-dev: commit fe3916e09a6ea9d95dd0615773bd451a0556e584
Resolved in OpenFOAM-3.0.x: commit 9cf015605d4cb58ff02808d457d06f7a0ce11838
|2015-10-27 11:52||emacchi||New Issue|
|2015-10-27 12:03||henry||Note Added: 0005500|
|2015-10-27 12:23||emacchi||Note Added: 0005501|
|2015-10-27 15:37||wyldckat||Note Added: 0005505|
|2015-10-30 12:32||emacchi||Note Added: 0005530|
|2015-11-30 16:33||henry||Note Added: 0005692|
|2015-12-01 09:53||emacchi||Note Added: 0005700|
|2016-01-17 12:18||henry||Note Added: 0005840|
|2016-01-17 12:18||henry||Status||new => resolved|
|2016-01-17 12:18||henry||Resolution||open => fixed|
|2016-01-17 12:18||henry||Assigned To||=> henry|