View Issue Details

IDProjectCategoryView StatusLast Update
0003917OpenFOAMBugpublic2022-10-21 10:31
ReporterSamMallinson Assigned Towill  
Status resolvedResolutionfixed 
PlatformLinuxOSUbuntuOS Version18.04
Product Version10 
Fixed in Version9 
Summary0003917: chtMultiRegionFoam case successfully runs in single core mode but gives erroneous result in parallel
DescriptionI 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 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 Reproduce1. 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 InformationI'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.
TagsNo tags attached.



2022-10-21 00:58


cht_of10.tar (122,880 bytes)
cht_of8.tar (225,280 bytes)


2022-10-21 08:15

reporter   ~0012815

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.


2022-10-21 08:33

reporter   ~0012816

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.


2022-10-21 09:10

reporter   ~0012817

The change in behavior happens in this commit

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_); ?


2022-10-21 10:31

manager   ~0012819

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:

Issue History

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