Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
openfoam
openfoam
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 351
    • Issues 351
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 8
    • Merge Requests 8
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
  • Development
  • openfoamopenfoam
  • Issues
  • #1966

Closed
Open
Opened Dec 21, 2020 by Richard Love@Richard97

Attempt to cast type zeroGradient to type nutWallFunction

Summary

When trying to simulate turbulent flow over open terrain using a k-epsilon model and RAS turbulence with inlet and outlet as type patch, the solver begins to solve for ux, uy, uz it then fails with the warning 'FOAM FATAL ERROR: Attempt to cast type zeroGradient to type nutWallFunction

However when the patch types are changed to wall, the solution begins to run. As I am trying to simulate turbulent flow over terrain, these patch types are not suitable

Steps to reproduce

The boundary file setup is seen at this link https://www.cfd-online.com/Forums/openfoam-solving/232526-attempt-cast-type-zerogradient-type-nutwallfunction.html.

It is being simulated through a simple cuboid blockMesh with an STL file connected via snappyHexMesh, however it does not run, even without the STL turbulenceProperties

transportProperties

RASProperties

blockMeshDict

fvSchemes

fvSolution

controlDict

Example case

What is the current bug behaviour?

It creates an error when I try and have any of the patch types as 'zeroGradient' inside the nut file when inlet, outlet or top type is type patch boundary

What is the expected correct behavior?

It should run without cancelling as type patch, and making the type be wall in order to run

Relevant logs and/or images

dimensions [0 2 -1 0 0 0 0];

internalField uniform 0;

boundaryField { #include "include/ABLConditions"

inlet
{
    type            zeroGradient;			
    //value           uniform 0.0;
}

outlet
{
    type            zeroGradient;
    //value           uniform 0;
}

top
{
    type            zeroGradient;
    //value           uniform 0;
}

DuneField
{
    type            nutkAtmRoughWallFunction;
    z0              $z0;
    value           uniform 0;
}

}

Environment information

  • OpenFOAM version :7
  • Operating system :ubuntu
  • Hardware info :
  • Compiler :

Possible fixes

FOAM FATAL ERROR:

Attempt to cast type zeroGradient to type nutWallFunction

From function To& Foam::refCast(From&) [with To = const Foam::nutWallFunctionFvPatchScalarField; From = const Foam::fvPatchField] in file /home/ubuntu/OpenFOAM/OpenFOAM-7/src/OpenFOAM/lnInclude/typeInfo.H at line 114'

The "/label bug" text is a gitlab flag that will add the "bug" label to this issue -->

Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: Development/openfoam#1966