Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • openfoam openfoam
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 426
    • Issues 426
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 9
    • Merge requests 9
  • Deployments
    • Deployments
    • Releases
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • Development
  • openfoamopenfoam
  • Issues
  • #2211
Closed
Open
Issue created Sep 16, 2021 by Vuko Vukcevic@vuko

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

Edited Sep 16, 2021 by Vuko Vukcevic
Assignee
Assign to
Time tracking