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 383
    • Issues 383
    • 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
  • #2295

Closed
Open
Created Dec 10, 2021 by Mattijs Janssens@MattijsMaintainer

swirl bc does not handle cyclic being decomposed

Functionality to add/problem to solve

swirl bc 'sits' on a cyclic patch. However the patch might get decomposed into a processorCyclic (if the owner and neighbour are not on the same processor). This looses the extra physics from the swirl/jump bc (since it has zero faces on the original patch). In addition the particular swirlVelocity bc expects at least one local face on the patch to be able to calculate the swirl axis.

Proposal

Avoid by e.g. having decomposition constraints:

constraints
{
    patches
    {
        //- Keep owner and neighbour on same processor for faces in patches
        //  (only makes sense for cyclic patches and cyclicAMI)
        type    preservePatches;
        patches (cyclic);
    }
}

Or maybe add constraint override to decomposePar so the bc type is now again swirl instead of processorCyclic. However now this patch might not be present on all processors or at a different index in the patch list.

@Prashant @mark

Edited Dec 10, 2021 by Mattijs Janssens
Assignee
Assign to
Time tracking