Proposal: alphatWallBoilingWallFunctionFvPatchScalarField.C wall temperature iteration

Hello everyone,

I have noticed that in the release OF-v1906 in the file OpenFOAM-v1906/src/phaseSystemModels/reactingEulerFoam/derivedFvPatchFields/alphatWallBoilingWallFunction/alphatWallBoilingWallFunctionFvPatchScalarField.C there was a for loop to evaluate wall temperature Tw. The for loop was, however, not executed because of lagging (line 1124 // NOTE: lagging Tw update.). Thus, the wall temperature was not evaluated after the calculation of the thermal turbulent diffusivity. This led to zero error between TsupPrev and TsupNew and so the for loop was not executed. The fix to that would be the evaluation of the maximum error from all CPUs. Thus scalar maxErr(gMax(mag(TsupPrev - TsupNew))); instead of scalar maxErr(max(mag(TsupPrev - TsupNew)));

When the original version is used then each processor might evaluate the error if condition on the line 1260 if (maxErr < 1e-1) differently, which means that some processor exits the for loop and some processor loops again. In this manner, the processors enter different parts of the code. Once they encounter a mpi function which requests information also from the other processor, it waits (forever, deadlock). This exactly happens when alphatWallBoilingWallFunctionFvPatchScalarField.C is used together with the turbulentTemperatureCoupledBaffleMixedFvPatchScalarField.C

I propose that the for loop to find wall temperature is implemented (as it was removed from OF-v1912) and the lagging to be fixed in the manner I showed above. It is generally recommended by literature to do this looping. Its absence might not be a big issue for heat transfer which uses correlations (film boiling and transitional boiling) but might be an issue for more complicated nucleate boiling.

Thank you, Kind regards, Robin