View Issue Details

IDProjectCategoryView StatusLast Update
0001879OpenFOAMBugpublic2016-01-17 12:19
Reporteremacchi Assigned Tohenry  
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
PlatformGNU/LinuxOSUbuntuOS Version12.04
Summary0001879: Possible bug in wallHeatFlux
DescriptionThe 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 ReproduceIn 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 InformationI 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.
TagsNo tags attached.

Activities

henry

2015-10-27 12:03

manager   ~0005500

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.

emacchi

2015-10-27 12:23

reporter   ~0005501

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.

wyldckat

2015-10-27 15:37

updater   ~0005505

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

emacchi

2015-10-30 12:32

reporter   ~0005530

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.

henry

2015-11-30 16:33

manager   ~0005692

OpenFOAM-dev: commit fe3916e09a6ea9d95dd0615773bd451a0556e584
OpenFOAM-3.0.x: commit 9cf015605d4cb58ff02808d457d06f7a0ce11838

    chtMultiRegionFoam, chtMultiRegionSimpleFoam, buoyantPimpleFoam, buoyantSimpleFoam: Added support for hRef

Is this issue now resolved?

emacchi

2015-12-01 09:53

reporter   ~0005700

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.

henry

2016-01-17 12:18

manager   ~0005840

Resolved in OpenFOAM-dev: commit fe3916e09a6ea9d95dd0615773bd451a0556e584
Resolved in OpenFOAM-3.0.x: commit 9cf015605d4cb58ff02808d457d06f7a0ce11838

Issue History

Date Modified Username Field Change
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