[Ya_Squall2010]

To begin with, I am working on foam-ext-3.1. I came across the "area does not match neighbour by ... % -- possible face ordering problem" quite often when running parallel simulation for 6DOFs problems. Originally I thought this could be because of the mesh quality deterioration as sometimes I can circumvent it by re-designing the mesh or simply reducing the time step size. Until recently, I occasionally replaced the "motionU" file in an interTrackFoam case by "pointMotionU", and this literally switched the mesh motion solver from the default "feMotionSolver" to a traditional "fvMotionSolver". It turned out that the case crashed after tens of seconds, and this didn't happen before the change in motion solver. This has reminded me that the aforementioned "area does not match neighbour" error could come from the fact that so far all of my 6DOFs cases are utilizing "fvMotionSolver", either velocity or displacement based. After checking the interTrackFoam results in paraview, I found something weird is happening at the processor boundary when using "fvMotionSolver". Please see the attached snapshots where the instantaneous mesh is displayed and the location of the processor boundary is highlighted. It is obvious that the processor boundary points were not moving in the same pace as their neighbours. And eventually something horrible happened, as shown in the last image. I am not sure what is going wrong here and whether should I report it as a bug? Your kind suggestion is much appreciated!

2016-03-14_16-33-48.jpg

2016-03-14_16-34-24.jpg

2016-03-14_16-34-57.jpg

2016-03-14_16-43-18.jpg