CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Bugs

Cyclic patch matching tolerance

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

Reply
 
LinkBack Thread Tools Display Modes
Old   January 14, 2005, 11:04
Default Description: Default matchin
  #1
Mattijs Janssens (Mattijs)
Guest
 
Posts: n/a
Description:
Default matching in couplePatches is geometric which uses a very strict tolerance.
- the messages are not very clear on how to solve it
- the tolerance cannot be set without programming


Solver/Application: couplePatches

Source file: cyclucPolyPatchMorph.C

Testcase: any case with cyclics.

Platform: Linux but guess all platforms will

Version: 1.0.2

Notes:
  Reply With Quote

Old   January 17, 2005, 10:59
Default Also would be nice to have ut
  #2
Mattijs Janssens (Mattijs)
Guest
 
Posts: n/a
Also would be nice to have utility which can adjust points automatically and write new mesh.
  Reply With Quote

Old   March 16, 2005, 12:27
Default Running in parallel trying to
  #3
Super Moderator
 
Mattijs Janssens
Join Date: Mar 2009
Posts: 1,416
Rep Power: 16
mattijs is on a distinguished road
Running in parallel trying to reorder incorrectly ordered processor faces gives error message:

.. processorFvPatch::makeWeights(scalarField& w)
.. area does not match neighbour ..
.. possible face ordering problem ..

and the code exits without ever reordering things.

For now the only fix seems to be to comment out the error message in processorPolyPatch.C (line ~170)
mattijs is offline   Reply With Quote

Old   March 30, 2005, 10:16
Default Hi Mattijs! I was having th
  #4
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,915
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
Hi Mattijs!

I was having the same problem with cyclicFvPatch::makeWeight (Gambit Meshes seem to have errors in the magnitude of 0.01%: higher than the hardcoded tolerance)

I replaced the hardcoded tolerance with a value that was read from the .OpenFoam/controlDict (like this):
MeshSwitches
{
makeWeightTolerance 1e-4;
}

The disadvantage is that by doing that this value is set for the whole installation. But at least it's better than recompiling the relevant files for every case.

Should I send the changes to you? They're quite trivial and general enough to be applicable for other hardcoded parameters (don't know if there are any more)

I'd really appreciate it if something like this could be built into the next release. That way I won't have to change it in my installation with every release.
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request
gschaider is offline   Reply With Quote

Old   March 30, 2005, 11:02
Default This tolerance should not be m
  #5
Super Moderator
 
Mattijs Janssens
Join Date: Mar 2009
Posts: 1,416
Rep Power: 16
mattijs is on a distinguished road
This tolerance should not be messed with - any error in face areas introduces conservation errors.

1) fix Gambit!

2) Andrew Heather had the idea of extending couplePatches to optionally align the matching points and write out a new point position. Andrew, you still there and feel like taking this up again?
mattijs is offline   Reply With Quote

Old   March 30, 2005, 12:10
Default Hi 2) - i made some changes
  #6
New Member
 
Andrew Heather
Join Date: Mar 2009
Posts: 16
Rep Power: 8
heather is on a distinguished road
Hi

2) - i made some changes to the code similar to Bernhard for my case - the calculations proceeded adequately with a reduced tolerance of 1E-4 (default being 1E-6) in the cyclicFvPatch and processorPolyPatch routines - admittedly not ideal - but was ok for my purpose...

Re. changes to the couplePatches routine - i have not implemented any of the 'automatic' alignments as yet - For my case i was able to create the cyclic patch by hard-coding the n0 and n1 vectors in the morphing routine.

Andy
heather is offline   Reply With Quote

Old   April 19, 2005, 08:28
Default To conclude this thread: I fou
  #7
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,915
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
To conclude this thread: I found the solution in another thread (similar problems while importing from StarMesh): the writePrecision in the controlDict should be set to 12 before manipulating the mesh. If this is not done the mesh points are truncated to a default precision of 6 and then makeWeight complains about the non-matching surfaces.

The mesh-importers have this hardcoded via a call to IOstream::defaultPrecision() (and even some of the mesh-manipulation applications) but the createPatch and couplePatch-utilities, which are needed to make cyclic-boundaries from Gambit-meshes, have not.

I think all applications in the mesh directory should set the default precision in order to avoid such problems in the future.

(I agree with you, Mattijs, that Gambit should be fixed, but in this special case it was innocent, it was a user problem)
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request
gschaider is offline   Reply With Quote

Old   April 19, 2005, 09:10
Default Hi Bernhard, Not sure wheth
  #8
Super Moderator
 
Mattijs Janssens
Join Date: Mar 2009
Posts: 1,416
Rep Power: 16
mattijs is on a distinguished road
Hi Bernhard,

Not sure whether the write precision should be higher for mesh data than for field data. Most cases do not use cyclics and have no need for high precision. And if you need it you can always put it in your controlDict.

For now I added the high precision setting to the utilities you mentioned, couplePatches and createPatch.
mattijs is offline   Reply With Quote

Old   April 19, 2005, 15:23
Default Hi Mattijs, I agree with yo
  #9
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,915
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
Hi Mattijs,

I agree with your reasoning that unneeded digits should not be written. On the other hand in most cases (when the mesh is not deformed etc) the mesh data is only written once to disk. Therefor the extra precision wouldn't have such a big impact on the disk usage. An as we have seen for the mesh data the loss of precision can be harmful.

How about this solution (I haven't looked into the IO-stuff too much, so I don't know if it's easy to do):
- introduce a new dictionary item like writePrecision (for instance writeMeshPrecision)
- make a subclass of IOobject (for instance MeshIOobject). The only difference is, that this class uses writeMeshPrecision for it's precision
- use MeshIOobject for the mesh-constructurs in the applications

This would give everyone the opportunity to set the mesh-precision according to the requirements of the case.
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request
gschaider 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
Changing Temperature in Cyclic patch panara OpenFOAM Running, Solving & CFD 3 March 30, 2011 11:28
Cyclic patch bug in version 141 patched cosimobianchini OpenFOAM Bugs 10 February 1, 2011 20:16
Cyclic patch in parallel calculations didomenico OpenFOAM Running, Solving & CFD 4 March 7, 2007 06:46
Arbitrary cyclic patch luca OpenFOAM Running, Solving & CFD 5 December 21, 2006 18:50
CYCLIC BOUNDARIES MATCHING robert CD-adapco 3 September 7, 2000 01:08


All times are GMT -4. The time now is 10:59.