MOVING_WALL not working if another marker has a DEFORMING SURFACE_MOVEMENT option

[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.

[pcarruscag]

It would be better to modify the grid velocity computation instead of modifying the boundary conditions.

[pcarruscag]

There is an open PR where the moving wall functions are called more often, instead of just at the start. That may already fix this issue.