Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • openfoam openfoam
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 379
    • Issues 379
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 13
    • Merge requests 13
  • Deployments
    • Deployments
    • Releases
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • Development
  • openfoamopenfoam
  • Issues
  • #1900

Closed
Open
Created Oct 23, 2020 by Mark Van C@archimark

v2006 atmWallConditions produce double value entries

Summary

When running a case utilizing some of the new atmBoundaryLayer wall functions (I verified this for atmOmegaWallFunction and atmNutkWallFunction but others might present the same issue), the patches defined by these functions contain double value field entries causing an error upon opening in ParaView (5.8.1 on Windows 10).

Steps to reproduce

Run any case using either the atmNutkWallFunction or atmOmegaWallFunction boundary definitions.

Example case

What is the current bug behaviour?

The boundary fields defined with either of these wall functions contain duplicate entries, causing errors when opening the case in ParaView. In case of the atmNutkWallFunction for example:

boundaryField
{
    bottom
    {
        type      atmNutkWallFunction;
        value     nonuniform List<scalar>
19200
(
...
)
;
         boundNut false;
         z0       0.003;
         value    nonuniform List<scalar>
19200
(
...
)
;
    };

What is the expected correct behavior?

The value entry should be written only once per boundary patch.

Relevant logs and/or images

Environment information

  • OpenFOAM version : v2006
  • Operating system : WSL 20.04 (Ubuntu 20.04 shell on Windows 10 1909)
  • Hardware info : N/A
  • Compiler : gcc 6.3.0

Possible fixes

atmNutkWallFunctionFvPatchScalarField.C L201

atmOmegaWallFunctionFvPatchScalarField.C L199

A possible workaround might be to change nutkWallFunctionFvPatchScalarField::write(os); and omegaWallFunctionFvPatchScalarField::write(os); to fvPatchField<scalar>::write(os);.

I extracted this potential fix from atmAlphatkWallFunctionFvPatchScalarField.C.

Assignee
Assign to
Time tracking