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
  • #2265
Closed
Open
Issue created Nov 09, 2021 by Saeed@salehi

surfaceAlignedSBRStress mesh motion solver not working

Summary

The surfaceAlignedSBRStressFvMotionSolver mesh motion solver seems quite interesting to me and fits my research area. However, it appears that it does not work. The simulation crashes at the very first iteration with following error:

--> FOAM FATAL ERROR: (openfoam-2106)
[cellDisplacement[0 1 -1 0 0 0 0] ] + [div(sigmaD)[0 -1 0 0 0 0 0] ]

Steps to reproduce

Replace the mesh motion solver in the SnakeRiverCanyon tutorial with surfaceAlignedSBRStress. Extra entities need to be added to the dynamicMeshDict. For instance one might add the following lines:

surfaces ("AcrossRiver.stl");
nNonOrthogonalCorr 4;

Also, a scheme needs to be provided for the "div(sigmaD)" in the fvSchemes. Then, run the case with the moveDynamicMesh utility and you will see the error.

Example case

The above-described reproduction test case is also attached. surfaceAlignedSBRStress.tar.gz

What is the current bug behaviour?

The surfaceAlignedSBRStress mesh motion solver is similar to the displacementSBRStress with an extra source term to make the close cells to an STL surface aligned to the surface. I am not sure what is wrong here. The implementation of the source term seems rather complex. But since there is a dimensionality check error, it could be that the formulation is somehow not correct. The error is thrown when the DEqn is to be constructed.

What is the expected correct behavior?

The expected correct behavior is to run without error!!!

Environment information

I checked this on v1912, v2006, v2012, and v2106. They all throw the same error.

Assignee
Assign to
Time tracking