Description: Default matchin
 

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:

Also would be nice to have ut
 

Also would be nice to have utility which can adjust points automatically and write new mesh.

Running in parallel trying to
 

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)

Hi Mattijs! I was having th
 

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.

This tolerance should not be m
 

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?

Hi 2) - i made some changes
 

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

To conclude this thread: I fou
 

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)

Hi Bernhard, Not sure wheth
 

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.

Hi Mattijs, I agree with yo
 

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.