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 |
| Reporter | emacchi | Assigned To | henry | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | GNU/Linux | OS | Ubuntu | OS Version | 12.04 |
| 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 |
| 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 |
