[thomas]

Hi Frank,

I encountered the same problem, but: up to now I haven't found a soluion for and, even more bad, I have no idea where it comes from.

So I would be very, very interested if you find a solution for it.
Thanks
Thomas

[lr103476]

Hi Thomas,

It comes from the tolerances between moving processor boundaries, when the mesh moves. I encountered this error for OF-1.3 (01-05-2007) and OF-1.4.1 (12-07-2007).

When and if the error occurs depends on the main motion direction and the way you decompose the mesh. I tried changing processorMatchTol in .OpenFOAM-1.3/controlDict without success.

I think that more people should have seen this? Anyone any ideas?

Regards, Frank

[thomas]

Hi Frank,

I made this experience while doing FSI simulations and prescribing the motion field of a parallel boundary patch. What is strange: The "faces do not match" - error occurs in a region of the mesh, that is not part of the prescribed boundary, but "at the other end of the mesh".

Also, using more elements, there's no error. Having another decomposition - no error...

Next week, I will have time to setup a simple trial case, where this error can be reproduced. Maybe, Hrvoje is so kind to have a look at it :-)

Thomas

[rolando]

Hi Frank,
I think a while ago I had a similar problem with 1-3.
I wrote my own mesh deformation utility.
The problem was, that I used the class "volPointInterpolation" and the interpolation mechanism faild to interpolate at the boundaries. If the values at the processor boundaries are interpolated you may have wrong values at the boundaries, which could cause your problem.

Rolando

[mattijs]

Is this the released OpenFOAM1.4? What motionSolver?

Sounds like a problem across shared points (points shared by more than 2 processors) which is why you only see it on some decompositions.

[lr103476]

I encountered this problem on both OF-1.3 and OF-1.4 (no not the released OF), since my movingBodyFvMesh lib is still not working with the new finiteVolume based motionSolver (which is real fast). So I used the tetDecomposition laplace motionSolver, with faceDecompFiniteElement, for both (1.3 dev and 1.4 dev).

Mattijs, if your explanation is true, what would be a solution? Force the shared points to be equal?

Regards, Frank

[mattijs]

Yes (Force the shared points to be equal).

On a (tetDecomposition) point mesh there is usually a globalProcessorXXPatch and corresponding patch field which takes care of this. They get created automatically and should be last on the list of patch fields. When that patch field 'evaluates' it synchronises the multiply shared points. This is the theory.

- visualise the meshes that go wrong. Are the points those between more than 2 processors?
- Multiple shared points: mesh.globalData()
- Brute-force synchronisation: see or use syncTools.H

[lr103476]

Ok Mattijs.

The error message gives me the face labels where the tolerances are exceeded. If I understand you correct, all I need is to identify the multiple shared points of my parallel case. How do I obtain those face labels, something like the following?

const polyMesh& test = mesh;
Info << test.globalMeshData.nGlobalPoints() << endl;

Frank

[thomas]

Dear Frank and Markus,

I am currently implementing this brute-force syncronisaiotn Markus posted above.

Evereything works right, I can calculate the differences between the points, but at the end of Markus routine, I get a compilation error in this assignment:

mypoints_[f[index]] = pos[faceI];

in my case mypoints_ is replaced by tetMesh()().points() and I am not allowed to assign a new position to the mesh.


Any suggestions?

Thomas

[pbo]

Hi everyone,

was trying to use the dynamicBodyFvMesh library with turbDyMFoam. It WORKS fine with 1 proc. But if I try to perform parallel computations on 2 procs or more, I get the following error message:
Time = 0.01
[0]
[0]
[0] --> FOAM FATAL ERROR : Attempt to cast type processor to type processorLduInterfaceField
[0]
[0] From function refCast<to>(From&)
[0] in file lnInclude/typeInfo.H at line 103.

I tried different decomposition methods (simple, metis), but I always end up with the above error message.

Has anyone dealt with this before?
Cheers,

Patrick