# Trying to model the motion of a submerged plate due to water waves. BC problem.

 Register Blogs Members List Search Today's Posts Mark Forums Read

 July 13, 2016, 17:56 Trying to model the motion of a submerged plate due to water waves. BC problem. #1 New Member   Join Date: Dec 2015 Posts: 27 Rep Power: 10 Hi, I have been working for a while on modeling the wave induced vertical motion of a completely submerged plate. I am using the waves2Foam package to generate waves and a modified interDyMFoam solver so solve the fluid problem. I am trying to use sixDoFRigidBodyMotion so solve the plate EOM. My problem seems to be with the boundary conditions on the plate. I am able to run the case well when I apply zeroGradient conditions to both the pressure and velocity on the plate. Doing so is obviously not correct because the plate is moving, so there should be a pressure gradient. The simulation is stable because sixDoF only needs forces at one time step to calculate the motion. However when the fluid equations are solved at the next time step, they don't "know" the plate is moving. This leads to a model where the plate does move but with no representation of the added mass or drag, I.e. An over estimation of the motion. I feel that I need to use movingWallVelocity BC for the velocity and a fixedFluxPressure of 0 for the pressure, but the simulation blows up very early when doing so. The way I picture this happening is that the plate velocity solved from sixDoF gets passed to movingWallVelocity (not sure if that happens automatically?) and the pressure is then calculated using this velocity and assuming zero flux through the plate. This all seems to make logical sense, however I can not understand why it is blowing up. Almost immediately the plate shoots out of the domain and completely destroys the mesh. This should be almost the exact same as the floatingBody tutorial case, except submerged and with some springs and dampers added. I am not sure what is going wrong; I would greatly appreciate any suggestions.

 July 14, 2016, 11:37 #2 New Member   Join Date: Dec 2015 Posts: 27 Rep Power: 10 After further thinking of this problem, why do you need a boundary condition for pressure at all? Assuming that we know the velocity of the wall, which we should from the sixDoF solver, then we should know that the velocity at the wall is equal to the wall, i.e. no-slip. Since we know the velocity, the pressure would just be solved using NS; there is no need for a boundary condition. Is there a way to implement this? Perhaps the 'calculated' condition?

 July 15, 2016, 13:57 #3 New Member   Join Date: Dec 2015 Posts: 27 Rep Power: 10 Any thoughts? I'm about ready to heave this pc out of the window. The solution converges and gives decent results with the zeroGradient condition even though this is not correct, but crashes very quickly with movingWallVelocity, which seems exactly what I need to be using.

 July 15, 2016, 14:53 #4 Senior Member   Join Date: Sep 2013 Posts: 353 Rep Power: 20 Your wall is not moving. movingWallVelocity is for moving walls and a stationary domain. You are moving your entire domain. Hence in the reference frame of the domain itself the wall is stationary. What you are hence trying to simulate is a moving domain which has conveyor belt like walls in addition to this. The same logic applies for the pressure boundary. fixedFluxPressure is also a zeroGradient pressure boundary condition. It is just calculated slightly differently and could improve performance.

July 17, 2016, 06:53
#5
New Member

Join Date: Dec 2015
Posts: 27
Rep Power: 10
Quote:
 Originally Posted by Bloerb Your wall is not moving. movingWallVelocity is for moving walls and a stationary domain. You are moving your entire domain. Hence in the reference frame of the domain itself the wall is stationary. What you are hence trying to simulate is a moving domain which has conveyor belt like walls in addition to this. The same logic applies for the pressure boundary. fixedFluxPressure is also a zeroGradient pressure boundary condition. It is just calculated slightly differently and could improve performance.

Hi, thanks for your reply; however, I am pretty confused at what you mentioned. You are correct -- none of my exterior walls are moving. However, this plate I am trying to study is essentially a wall and is moving within the domain. I modelled the case based off of the floatingObject tutorial in openFOAM, so I know that it is possible to use these boundary conditions, but do you have any recommendations on what BCs to use for this plate.

Also, I am completely lost about what you said on the conveyer belt thing. I have a wave flume that is basically just a rectangle with fixed walls, and made the plate by subtracting cells in the interior of the flume.

I know that using both zeroGradients BCs is incorrect because I tried to force oscillate it to see if it generated waves and it doesn't; thus, the added mass and drag components are not being captured, which is leading to an over estimation of the motion.

 July 19, 2016, 05:03 #6 New Member   Join Date: Dec 2015 Posts: 27 Rep Power: 10 The problem seems to be linked with the width of my plate. If I make the object a square block, the simulation runs fine; however, that is not the geometry that I want to model. When I make the object a thin plate, the solution diverges very quickly. What in the world could this be?