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:

1. Run blockMesh,
2. Observe that the movingWall BC for 0/T is externalWallHeatFluxTemperature with h constant 42; for heat transfer coefficient,
3. Run decomposePar,
4. Observe that the movingWall BC for processor0/0/T has the same definition as the reconstructed one, although there are zero faces on this patch.
5. Run reconstructPar -withZero,
6. Observe that the movingWall BC for 0/T changed from h constant 42; to h constant 0;, which is a bug.

Example case

reproduce.tar.gz

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=(...)).