View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003917||OpenFOAM||Bug||public||2022-10-21 00:58||2022-10-21 10:31|
|Fixed in Version||9|
|Summary||0003917: chtMultiRegionFoam case successfully runs in single core mode but gives erroneous result in parallel|
|Description||I have been simulating the simple case of a parallel wall channel in 2D, with one wall attached to a solid block, at the bottom of which a heat flux is applied. The results compare very well with an analytical solution, see https://www.researchgate.net/publication/334028691_Conjugate_Heat_Transfer_in_Thermal_Inkjet_Printheads and in particular Figure 1|
The case in question has been run under OpenFOAM-5, 6, 7 and 8, all giving good agreement between theory and simulation.
I had neglected to update it to 9 last year, and when I came to update to 10, I noticed some unusual behaviour.
In particular, when I run the case in single-core mode, I again obtain good agreement with the theory, but when I run in parallel, I get a large overprediction of the temperature profile.
I have attached .tar-balls for the OpenFOAM-8 and OpenFOAM-10 cases (NB: for the latter, a number of changes were required, eg updating of thermophysical model for solid from constIso to constIsoSolid).
|Steps To Reproduce||1. download and un-tar files in separate folders|
1.1 prior to running each case, issue source /path/to/etc/bashrc for given code version
2. for OpenFOAM-8 case, ./Allrun - then inspect plots/T.png
3. for OpenFOAM-10 case single core, ./Allrun - then inspect plots/T.png
4. for OpenFOAM-10 case parallel case, ./AllrunPar - then inspect plots/T.png
|Additional Information||I've been running other cases from earlier version of OpenFOAM for some number of years; when I came to update them to version 10, I did not see this issue, instead the results were consistent with the earlier versions whether run single-core or parallel.|
|Tags||No tags attached.|
cht_of10.tar (122,880 bytes)
cht_of8.tar (225,280 bytes)
I debugged this a little and one clear difference is that the gradient values for heater T BCs have very different values in parallel and in serial. The values are given through macro expansions and somehow they evaluate to different values in serial vs in parallel. eg. T heater outlet is gradient uniform 0.210084; in serial vs gradient uniform 300.0010504; in parallel.
The case setups in OF8 are different. In OF8 the value is calculated before decomposition by using changeDictionary -enableFunctionEntries, in OF10 the fields already contain macros and they are decomposed resulting to different evaluation.
||I was able to simplify the problem, for some reason in OF10 if there is a fixedGradient BC with a given gradient, when the field is decomposed the gradient is recalculated and overwritten. This does not happen in OF8.|
The change in behavior happens in this commit https://github.com/OpenFOAM/OpenFOAM-dev/commit/261d5ccd6d69ef1bf2e7f347dafa51fe123425d8.
I think there is a bug in line 92 in fixedGradientFvPatchField.C, the gradient is mapped using mapper(gradient_, ptf), shouldn't it be mapper(gradient_, ptf.gradient_); ?
Thanks for the report, and thanks for finding and fixing the issue, Timo. I guess this has hung around so long because we don't use fixedGradient all that much, and when we do it's usually derived into something which overwrites the gradient, thereby masking the problem. Fixed in 9, 10 and dev:
|2022-10-21 00:58||SamMallinson||New Issue|
|2022-10-21 00:58||SamMallinson||File Added: cht_of10.tar|
|2022-10-21 00:58||SamMallinson||File Added: cht_of8.tar|
|2022-10-21 08:15||tniemi||Note Added: 0012815|
|2022-10-21 08:33||tniemi||Note Added: 0012816|
|2022-10-21 09:10||tniemi||Note Added: 0012817|
|2022-10-21 10:31||will||Assigned To||=> will|
|2022-10-21 10:31||will||Status||new => resolved|
|2022-10-21 10:31||will||Resolution||open => fixed|
|2022-10-21 10:31||will||Fixed in Version||=> 9|
|2022-10-21 10:31||will||Note Added: 0012819|