multi patch boundary condition

zhaozhenkai · March 31, 2016, 14:37

Hi, guys,

I am try to simulate a multi-body case using pimpleDyMFoam. I have got three moving patches so I have set their U BCs as movingWallVelocity. I use external programme to calculate their position and add the new position on to the patch using methods below:

pointDisplacement_.boundaryField()[patchID2] == pointsN2 - pointsI2;

the "patchID2" is the patch name.

However, when i run it, the simulation blows up quickly, and I have tested the case with only one moving patch and it worked fine. I have also used other BCs for the moving patches like zeroGradient which is not correct, and there is no blow up on the fly.

I wonder if there is a limitation on using movingWallVelocity BC or the problem is related to the mesh.update().

it may be unclear about my statements. If you need more information, please tell me.

ZHENKAI

zhaozhenkai · April 5, 2016, 10:45

Hi, guys,

I am try to simulate a multi-body case using pimpleDyMFoam. I have got three moving patches so I have set their U BCs as movingWallVelocity. I use external programme to calculate their position and add the new position on to the patch using methods below:

pointDisplacement_.boundaryField()[patchID2] == pointsN2 - pointsI2;

the "patchID2" is the patch name.

However, when i run it, the simulation blows up quickly, and I have tested the case with only one moving patch and it worked fine. I have also used other BCs for the moving patches like zeroGradient which is not correct, and there is no blow up on the fly.

I wonder if there is a limitation on using movingWallVelocity BC or the problem is related to the mesh.update().

it may be unclear about my statements. If you need more information, please tell me.

ZHENKAI

March 31, 2016, 14:37	multi patch boundary condition	#1
zhaozhenkai New Member ZHENKAI ZHAO Join Date: Oct 2015 Posts: 14 Rep Power: 10	Hi, guys, I am try to simulate a multi-body case using pimpleDyMFoam. I have got three moving patches so I have set their U BCs as movingWallVelocity. I use external programme to calculate their position and add the new position on to the patch using methods below: pointDisplacement_.boundaryField()[patchID2] == pointsN2 - pointsI2; the "patchID2" is the patch name. However, when i run it, the simulation blows up quickly, and I have tested the case with only one moving patch and it worked fine. I have also used other BCs for the moving patches like zeroGradient which is not correct, and there is no blow up on the fly. I wonder if there is a limitation on using movingWallVelocity BC or the problem is related to the mesh.update(). it may be unclear about my statements. If you need more information, please tell me. ZHENKAI

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Problem in setting Boundary Condition	Madhatter92	CFX	12	January 12, 2016 04:39
[mesh manipulation] Importing Multiple Meshes	thomasnwalshiii	OpenFOAM Meshing & Mesh Conversion	18	December 19, 2015 18:57
Problem with cyclic boundaries in Openfoam 1.5	fs82	OpenFOAM	36	January 7, 2015 00:31
Cyclic Boundary Condition	Luiz Eduardo Bittencourt Sampaio (Sampaio)	OpenFOAM Running, Solving & CFD	36	July 2, 2012 12:23
RPM in Wind Turbine	Pankaj	CFX	9	November 23, 2009 04:05

April 5, 2016, 10:45		#2
zhaozhenkai New Member ZHENKAI ZHAO Join Date: Oct 2015 Posts: 14 Rep Power: 10	Hi, guys, I am try to simulate a multi-body case using pimpleDyMFoam. I have got three moving patches so I have set their U BCs as movingWallVelocity. I use external programme to calculate their position and add the new position on to the patch using methods below: pointDisplacement_.boundaryField()[patchID2] == pointsN2 - pointsI2; the "patchID2" is the patch name. However, when i run it, the simulation blows up quickly, and I have tested the case with only one moving patch and it worked fine. I have also used other BCs for the moving patches like zeroGradient which is not correct, and there is no blow up on the fly. I wonder if there is a limitation on using movingWallVelocity BC or the problem is related to the mesh.update(). it may be unclear about my statements. If you need more information, please tell me. ZHENKAI