PatchFunction1Types::ConstantField<Type>::getValue should not guard against zero length
Summary
I think the guard against zero-sized lists in Foam::PatchFunction1Types::ConstantField<Type>::getValue
is unnecessary and causes a subtle bug. This is the exact line in the repository: https://develop.openfoam.com/Development/openfoam/-/blob/master/src/meshTools/PatchFunction1/ConstantField/ConstantField.C#L94
Steps to reproduce
This surfaced when we did a decomposition and reconstruction with externalWallHeatFluxTemperature
BC. The decomposition is such that it gives a zero-sized patch on processor0
, and on reconstruction, the uniformValue_
is set to 0
and not set from the dictionary because the length is zero.
You should be able to reproduce this easily on the attached case with the following steps:
- Run
blockMesh
, - Observe that the
movingWall
BC for0/T
isexternalWallHeatFluxTemperature
withh constant 42;
for heat transfer coefficient, - Run
decomposePar
, - Observe that the
movingWall
BC forprocessor0/0/T
has the same definition as the reconstructed one, although there are zero faces on this patch. - Run
reconstructPar -withZero
, - Observe that the
movingWall
BC for0/T
changed fromh constant 42;
toh constant 0;
, which is a bug.
Example case
What is the current bug behaviour?
PatchFunction1Types::ConstantField<Type>::getValue
leaves uniformValue_
member initialized to Zero
if the list (patch) has zero-size.
What is the expected correct behavior?
PatchFunction1Types::ConstantField<Type>::getValue
should initialize uniformValue_
member correctly from the dictionary, even for zero-sized lists.
Relevant logs and/or images
Environment information
- OpenFOAM version : v2012
- Operating system : ubuntu 20.04
- Hardware info : x86_64
- Compiler : gcc 9.3.0
Possible fixes
Removing the if (len)
check fixes the issue. I think that this is completely safe since it's ok to perform operations on zero-sized lists (namely List<Type>::setSize(0)
and List<Type>::operator=(...)
).