Skip to content

MOVING_WALL not working if another marker has a DEFORMING SURFACE_MOVEMENT option #2166

Open
@tbellosta

Description

@tbellosta

I am running an unsteady simulation where I have a marker with an imposed velocity and an object in the domain that moves according to some law. Think of a translating (or plunging) sphere in a cavity flow. The related options in my config file are:

SURFACE_MOVEMENT= (MOVING_WALL, DEFORMING)
MARKER_MOVING= (TOP_WALL, SPHERE)
SURFACE_TRANSLATION_RATE= (100 0 0, 0 1 0)

With those options the MOVING_WALL conditions at the top wall is completely disregarded. Instead, it gets imposed correctly if I omit the deforming marker.
The reason can be traced back to the way the velocity is imposed in the heatflux (or isothermal) boundary condition, where the grid velocity is used to strongly impose that BC. Nothing wrong with that if either only one between MOVING_WALL or DEFORMING markers is used. In the first case the grid velocity is set in CGeometry::SetWallVelocity(), in the second case is computed via finite differencing in CGeometry::SetGridVelocity(). If both markers are present, the call to CGeometry::SetGridVelocity() overwrites the values set by CGeometry::SetWallVelocity() at the walls, and if a wall is not actually moving (like the top wall in a cavity problem) the value is set to zero.

Now, fixing this should be relatively easy (I hardcoded some tests that look like they are working), but I want to ask what is the preferred way to fix this problem. We either call CGeometry::SetWallVelocity() after CGeometry::SetGridVelocity() at each time step, or explicitly treat the MOVING_WALL markers differently inside the no-slip boundary conditions. My preliminary implementation was along the lines of the latter option, but I wanted to ask before proceeding further. I will open a WIP pull request as soon as I finish up some tests.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions