CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Running, Solving & CFD

Parallel moving mesh problem

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

Reply
 
LinkBack Thread Tools Display Modes
Old   July 18, 2007, 07:31
Default Hi Frank, I encountered the
  #21
New Member
 
Thomas Gallinger
Join Date: Mar 2009
Posts: 28
Rep Power: 7
thomas is on a distinguished road
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
thomas is offline   Reply With Quote

Old   July 18, 2007, 08:48
Default Hi Thomas, It comes from t
  #22
Senior Member
 
Frank Bos
Join Date: Mar 2009
Location: The Netherlands
Posts: 338
Rep Power: 8
lr103476 is on a distinguished road
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
__________________
Frank Bos
lr103476 is offline   Reply With Quote

Old   July 18, 2007, 12:39
Default Hi Frank, I made this exper
  #23
New Member
 
Thomas Gallinger
Join Date: Mar 2009
Posts: 28
Rep Power: 7
thomas is on a distinguished road
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
thomas is offline   Reply With Quote

Old   July 18, 2007, 13:29
Default Hi Frank, I think a while ago
  #24
Member
 
Rolando Maier
Join Date: Mar 2009
Posts: 89
Rep Power: 7
rolando is on a distinguished road
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
rolando is offline   Reply With Quote

Old   July 19, 2007, 06:36
Default Is this the released OpenFOAM1
  #25
Super Moderator
 
Mattijs Janssens
Join Date: Mar 2009
Posts: 1,416
Rep Power: 15
mattijs is on a distinguished road
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.
mattijs is offline   Reply With Quote

Old   July 19, 2007, 06:55
Default I encountered this problem on
  #26
Senior Member
 
Frank Bos
Join Date: Mar 2009
Location: The Netherlands
Posts: 338
Rep Power: 8
lr103476 is on a distinguished road
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
__________________
Frank Bos
lr103476 is offline   Reply With Quote

Old   July 19, 2007, 14:17
Default Yes (Force the shared points t
  #27
Super Moderator
 
Mattijs Janssens
Join Date: Mar 2009
Posts: 1,416
Rep Power: 15
mattijs is on a distinguished road
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
mattijs is offline   Reply With Quote

Old   July 19, 2007, 18:06
Default Ok Mattijs. The error mess
  #28
Senior Member
 
Frank Bos
Join Date: Mar 2009
Location: The Netherlands
Posts: 338
Rep Power: 8
lr103476 is on a distinguished road
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
__________________
Frank Bos
lr103476 is offline   Reply With Quote

Old   July 26, 2007, 08:44
Default Dear Frank and Markus, I am
  #29
New Member
 
Thomas Gallinger
Join Date: Mar 2009
Posts: 28
Rep Power: 7
thomas is on a distinguished road
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
thomas is offline   Reply With Quote

Old   November 26, 2008, 01:55
Default Hi everyone, was trying to
  #30
pbo
Member
 
Patrick Bourdin
Join Date: Mar 2009
Posts: 40
Rep Power: 7
pbo is on a distinguished road
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
pbo is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Problem with moving mesh Sully FLUENT 7 September 11, 2008 00:38
moving mesh in parallel mode Karteek CD-adapco 4 June 16, 2008 04:12
how to parallel run in moving mesh case ELYOR CD-adapco 5 June 16, 2008 03:23
Moving Mesh Problem Rashad FLUENT 0 August 28, 2006 04:31
Moving mesh problem Samir CD-adapco 0 November 10, 2004 13:35


All times are GMT -4. The time now is 11:40.