Star mesh conversion
 

Hello,

we have a first version available of a Star '.ccm'
format converter. It can read both Prostar generated .ccm files (couples have to be merged) and Star-ccm+ generated .ccm files.

It has a few limitations:
- it does not handle couples. These have to be merged beforehand in either Prostar or Star-ccm+.
- it does not handle cyclics and or other 'interfaces'
- it does not yet read the patch names, instead naming them patch0, patch1, ..

It does however handle all cells that either Prostar or Star-ccm+ can handle so general polyhedra are no problem.

It will probably be in future Foam releases; contact me if you need it sooner.

Mattijs

Hi, I am attempting to imp
 

Hi,

I am attempting to import a grid from STAR to FOAM. The geometry has rotational symmetry - a 60deg wedge. I am having difficulties applying the cyclic boundary conditions - if a different boundary type is applied (wall, say) all is well. However, as soon as I attempt to include the cyclic patches, errors arise such as:

--> FOAM FATAL ERROR : face 0 and 2514 areas do not match by 176.478% -- possibleface ordering problem

Function: cyclicFvPatch::makeWeights(scalarField& w) const
in file: meshes/fvMesh/fvPatches/derivedFvPatches/cyclicFvPatch/cyclicFvPatch.C at line: 62.

I looked at the couplePatches and autoPatch utilities, but both were unable to correct the problem. I noticed that the couplePatches utility stated that:

'This will only work for cyclics if they are parallel or their rotation is defined across the origin'

My model has rotation about the z-axis - does the routine need the axis to be oriented along a specific axis?

- any help would be appreciated

The grid passed all geometry checks in PROSTAR before the attempted conversion

Many thanks,

Andy

Hi Andy, The limitation is
 

Hi Andy,

The limitation is actually more strict: the axis of rotation should be one of the coordinate axes (so not just parallel).

See if shifting your whole geometry so the axis of rotation is the z-axis helps. (and run couplePatches to correct the cyclic face ordering)

Mattijs

Hi Mattijs, Sorry - I shou
 

Hi Mattijs,

Sorry - I should have been clearer - the model already uses the z-axis as the axis of rotation...

Andy

Could you rerun couplePatches
 

Could you rerun couplePatches with in the foamDebugSwitches section in .OpenFOAMXXX/controlDict

polyMeshMorph 1;

This will produce some interesting output.

(b.t.w. you are aware that couplePatches (probably) writes the corrected mesh to a time directory and you'll have to move it to the constant/ directory for the solver to use it)

Hi Andrew, you can have a
 

Hi Andrew,

you can have a look at the .obj files with e.g. javaview or run objToVTK and use paraview. It will write:

cyclic_zone_0.obj : face centres of one half of the cyclic

cyclic_zone_1.obj : ,, of the other half

cyclic_faceCentres.obj : lines between matched points on the cyclic halves.

Judging from the output

... with difference to point 7.31437e-05 ...

it is just a tolerance issue.

You could try changing the tolerance in couplePatches.C. Just add

coupledPolyPatch::setGeometricMatchTol(1E-3);


(default is 1E-5)

and see if that helps.

Mattijs

Hi Mattijys, Sorry for the
 

Hi Mattijys,

Sorry for the delay in getting back - just installed javaview in the hope of seeing what was going on more clearly (- paraview did not display an output when i loaded the .vtk files geneterated by objToVTK???)

Looking at the zone 0/1 and faceCentres obj files it appears that the routine has matched the faces correctly (visually when using javaview, and inspecting the 'hard-numbers') + thanks for the cyclicPolyPatchMorph.C update - the regionEdges appear correct... However, the problem comes after the matching when using couplePatches - when it tries to 'match vectors'

I get the output:
--> FOAM Serious Error : cyclicPolyPatch::order : patch:cyclic : Cannot match vectors to faces on both sides of patch
half0Ctrs[0]: (0.00827715 -0.00467724 5.00871)
half1Ctrs[0]: (0.00823317 -0.00475342 5.00871)

Many thanks,

Andy

So you still get the 'Cannot
 

So you still get the 'Cannot find point in pts1' messages?

Did you try lowering the tolerance? Less of the above messages?

2] if the .obj file contains only points you will probably only get points in your .vtk file and have to put 'glyphs' on those to see them.

Yes - lowering the tolerance
 

Yes - lowering the tolerance led to fewer messages...

Looking at the .obj files all of the faces have been patched - each (half of the cyclic) patch has 5029 cells, and 5029 (matched) entries were written to each file. But, the error given above remained...

Hi Andrew, the message me
 

Hi Andrew,

the message means that there still are unmatched faces. Try lowering the tolerance even more.

Also print out 'tols' in cyclicPolyPatchMorph.C:345 and see how it compares to the values printed in the

" .. with difference to point ..."

Any ideas for better tolerance level and/or calculation are welcome. I only ran it on a few simple geometries and put the tolerance really tight.

Hi Mattijs, Increasing the t
 

Hi Mattijs,
Increasing the tolerance to 0.1 seemed to overcome the problem, and the couplePatches routine completed successfully. However, as a result of the transformation process the coupled face areas are now causing the following problem -

--> FOAM FATAL ERROR : face 129 and 5158 areas do not match by 0.000203986% -- possible face ordering problem

Is it possible to relax this tolerance also? (albeit with caution!)

..will have a think about tol/calc methods for the couplePatches routine. Eg how about (for rotational problems) - defining the angle, from which two planes could be constructed, and points 'massaged' so that they lay exactly on the plane. By locking the position of the vertices on one plane, they could be mirrored exactly onto the matching cyclic plane. Obviously tolerances would play a part again + warnings/errors raised if they are exceeded...

Hi Andrew, thanks for the
 

Hi Andrew,

thanks for the feedback & glad you got it to work. Do you have some code for me? Is bit hard to absorb without.

Mattijs

Hi Mattijs, How about the
 

Hi Mattijs,

How about the following - nothing concrete written so far - still seeing how the mesh structures work...

Andy


// ***************************
cyclicDict

// Dictionary file to specify cyclic boundaries

type translational; // translational/rotational flag

tolerance 1.0E-5; // tolerance - used for checking only

rotationalCyclic // rotational cyclic parameters
{
autoCalc off; // calc axis of rotation (on/off)
axis // axis of rotation (if autoCalc=off)
(
0.0
0.0
1.0
);
}

translationalCyclic // translational cyclic parameters
{
autoCalc on; // calc geometric transform (on/off)
transform // transform (if autoCalc=off)
(
0.0
-1.0
0.0
);
}

// ***************************

Pseudo code/method for cyclic face matching

Driver:
1. Determine number of faces in each 'half' of the cyclic patch (as in couplePacthes)
2. Create and initialsie a flag array to indicate whether a face has been treated or not (size of one half of cyclic)
forAll(flags,i)
{
flags[i] = NOTSET;
}
3. Determine translation or axis of rotation (as in couplePacthes if is autoCalc=on) or use user-supplied value
4. In either cylindrical or cartesian co-ordinates (determined by type of cyclic) - select face at minimum co-ordinates
5. The face selected on each half of the cyclic should be equivalent (face1ID, face2ID)
6. Set these faces as a cyclic pair, and flag the face on the first half (say) in the flag array as SET
flags[face1ID] = SET;
7. Pass these faces and the flag array into a recursive function that goes something like:

matchingFunction(face1, face2, flags)
{
// get faces that border face1
faceNeighbours1 = getAdjacentFaceIDs(face1);
// get faces that border face2
faceNeighbours2 = getAdjacentFaceIDs(face2);

// check that each face has the same number of neighbours
if (faceNeighbours1.size() = faceNeighbours2.size())
{
// loop across all neighbours of face1
forAll(faceNeighbours1, i)
{
// only consider if flag is not set
if (flags[i] = NOTSET)
{
// recursive call to matching function with neighbour of face1
matchingFunction(faceNeighbours1[i],faceNeighbours2[i],flags);
// couple the faces
coupleFaces(faceNeighbours1[i], faceNeighbours2[i]);
// set the flag to SET
flags[i] = SET;
}
}
}
// raise error
else
FatalError << "inconsistent neighbours on cyclic patch";

}

intArray getAdjacentFaceIDs(faceID)
{
// return a list of faceIDs that border the face, faceID, on cyclic patch (half)
}

8. As post-processing checks:
- ensure all elements of flag array = SET
- ensure face areas are within tolerance given by dictionary tolerance entry
- ensure faces lie on the same plane (massage to plane if not - as previous posting)

...

Hi Andrew, pretty impressi
 

Hi Andrew,

pretty impressive. Problem we have is that all this code is buried inside cyclicPolyPatch::order(...) which has no access to any dictionary since it gets called by the mesh morphing functionality.

(since after any mesh change the coupled faces have to be reordered to be consistent)

couplePatches as you have noticed is just a very light wrapper around it so yes we could build in additional user input through a dictionary. I especially would appreciate your suggestion of having an option to move the points to the correct position (so any future mesh morphing runs without any problems)

And yes the default tolerance is very strict.

Did you notice that part of the recursive matching technique is already in the topologicalOrder(...) but there the problem is that you need a correct starting face.

Problems with cyclics:
- cyclic patch might not have two feature edge separated regions
- cyclic patch might be more than two regions
- cyclic patch might not have planar sides (but still single transformation tensor)
- cyclic patch might have different transformation tensor per face (not really supported)
- cyclic patch might not be along coordinate axis (not supported yet)

Hi Andrew, forgot to menti
 

Hi Andrew,

forgot to mention another problem ;-): recursion tends to run out of stack just when you're doing a really big simulation.

Have a look at walkPatch (used in topologicalOrder) where it constructs a list of visited vertices in the form of
-label of face
-index in face
since on coupled patches corresponding faces
- have the same face label
- have their 0th point matched
(so if fA[0] is matched to fB[0] , fA[1] is matched to fB[fB.size()-1], etc.

Hi I was reading through the t
 

Hi I was reading through the thread, but there are still some questions open regarding cyclic patches.

1.What does couplePatch do?
2.What does autoPadch do?
3.I have a mesh containig 15 cyclics. 12 of them work without any problems. But 3 with the following error message (after running the case):

--> FOAM FATAL ERROR : face 2 and 352 areas do not match by 0.00010804% -- possibleface ordering problem

Function: cyclicFvPatch::makeWeights(scalarField& w) const
in file: meshes/fvMesh/fvPatches/derivedFvPatches/cyclicFvPatch/cyclicFvPatch.C at line: 62.

3a)What does this error mean?
3b)This error seems to me very small? Can I somehow enhance the tolerance lets say to 0.0003%

Your help is appreciated

Best regards

1) reorder faces on coupled pa
 

1) reorder faces on coupled patches (cyclics, processor patches) so that they conform to the OpenFOAM ordering.

2) Search for 'autoPatch'.

3a) cyclic faces need to match in area (and also in point position). OpenFOAM assumes a 1 to 1 coupling. Any mismatch causes conservation errors.

3b) Make sure your mesher puts the points at the exact positions. Increase the writePrecision in the controlDict to 12 before converting.

Hi Mattijs, Thanks for your
 

Hi Mattijs,

Thanks for your help! A question regarding ordering:

1)If in one half of the cyclic patch the velocity vectors point out of the domain and in the second half of the domain the vectors point also out (so that the vectors would point against each other), is this a face ordering problem?

2)How can I resolve this problem? just couplePatch?

1) is not a problem. All bound
 

1) is not a problem. All boundary faces should point outwards. OpenFOAM takes care of the opposing normals when mapping vectors.

So I wonder why the vectors po
 

So I wonder why the vectors point at each other? I assumed what leave one part of the cyclic enters its counterpart.

How can I make sure, that the cyclic patches are set up the right way?

Here is what I did:
1)Transformed a FluentMesh with FluentMeshToFoam.
2)associated to the cyclic boundaries cyclic
3)started the case (no error messages occured)
(I did not use couplePatch)

How does OpenFoam know whether it is a translational or a rotational cyclic patch? In my case I need a 180° rotational cyclic .

Best regards