CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Other Meshers: ICEM, Star, Ansys, Pointwise, GridPro, Ansa, ...

Star mesh conversion

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

Reply
 
LinkBack Thread Tools Display Modes
Old   November 11, 2004, 10:19
Default Hello, we have a first ver
  #1
Mattijs Janssens (Mattijs)
Guest
 
Posts: n/a
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
  Reply With Quote

Old   January 13, 2005, 12:48
Default Hi, I am attempting to imp
  #2
Andrew Heather (Heather)
Guest
 
Posts: n/a
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
  Reply With Quote

Old   January 13, 2005, 13:13
Default Hi Andy, The limitation is
  #3
Mattijs Janssens (Mattijs)
Guest
 
Posts: n/a
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
  Reply With Quote

Old   January 13, 2005, 13:20
Default Hi Mattijs, Sorry - I shou
  #4
Andrew Heather (Heather)
Guest
 
Posts: n/a
Hi Mattijs,

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

Andy
  Reply With Quote

Old   January 13, 2005, 13:40
Default Could you rerun couplePatches
  #5
Mattijs Janssens (Mattijs)
Guest
 
Posts: n/a
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)
  Reply With Quote

Old   January 14, 2005, 09:18
Default Hi Andrew, you can have a
  #6
Mattijs Janssens (Mattijs)
Guest
 
Posts: n/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
  Reply With Quote

Old   January 14, 2005, 11:28
Default Hi Mattijys, Sorry for the
  #7
Andrew Heather (Heather)
Guest
 
Posts: n/a
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
  Reply With Quote

Old   January 14, 2005, 11:58
Default So you still get the 'Cannot
  #8
Mattijs Janssens (Mattijs)
Guest
 
Posts: n/a
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.
  Reply With Quote

Old   January 14, 2005, 12:16
Default Yes - lowering the tolerance
  #9
Andrew Heather (Heather)
Guest
 
Posts: n/a
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...
  Reply With Quote

Old   January 14, 2005, 12:37
Default Hi Andrew, the message me
  #10
Mattijs Janssens (Mattijs)
Guest
 
Posts: n/a
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.
  Reply With Quote

Old   January 14, 2005, 13:50
Default Hi Mattijs, Increasing the t
  #11
Andrew Heather (Heather)
Guest
 
Posts: n/a
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...
  Reply With Quote

Old   January 19, 2005, 08:50
Default Hi Andrew, thanks for the
  #12
Mattijs Janssens (Mattijs)
Guest
 
Posts: n/a
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
  Reply With Quote

Old   January 19, 2005, 11:27
Default Hi Mattijs, How about the
  #13
Andrew Heather (Heather)
Guest
 
Posts: n/a
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)

...
  Reply With Quote

Old   January 19, 2005, 11:55
Default Hi Andrew, pretty impressi
  #14
Mattijs Janssens (Mattijs)
Guest
 
Posts: n/a
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)
  Reply With Quote

Old   January 19, 2005, 12:24
Default Hi Andrew, forgot to menti
  #15
Mattijs Janssens (Mattijs)
Guest
 
Posts: n/a
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.
  Reply With Quote

Old   April 17, 2005, 08:15
Default Hi I was reading through the t
  #16
Member
 
Duderino
Join Date: Mar 2009
Posts: 40
Rep Power: 8
duderino is on a distinguished road
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
duderino is offline   Reply With Quote

Old   April 18, 2005, 05:45
Default 1) reorder faces on coupled pa
  #17
Super Moderator
 
Mattijs Janssens
Join Date: Mar 2009
Posts: 1,416
Rep Power: 16
mattijs is on a distinguished road
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.
mattijs is offline   Reply With Quote

Old   April 20, 2005, 09:57
Default Hi Mattijs, Thanks for your
  #18
Member
 
Duderino
Join Date: Mar 2009
Posts: 40
Rep Power: 8
duderino is on a distinguished road
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?
duderino is offline   Reply With Quote

Old   April 20, 2005, 11:29
Default 1) is not a problem. All bound
  #19
Super Moderator
 
Mattijs Janssens
Join Date: Mar 2009
Posts: 1,416
Rep Power: 16
mattijs is on a distinguished road
1) is not a problem. All boundary faces should point outwards. OpenFOAM takes care of the opposing normals when mapping vectors.
mattijs is offline   Reply With Quote

Old   April 20, 2005, 16:00
Default So I wonder why the vectors po
  #20
Member
 
Duderino
Join Date: Mar 2009
Posts: 40
Rep Power: 8
duderino is on a distinguished road
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
duderino 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
Plot3dToFoam mesh conversion error rcpoudel OpenFOAM Native Meshers: blockMesh 15 July 11, 2010 17:18
Help: mesh conversion from Gambit to ICEM sarah_ron2002 FLUENT 2 April 5, 2008 01:53
polyhedral mesh conversion ali FLUENT 4 September 14, 2007 11:55
About mesh conversion Spyros CD-adapco 0 January 5, 2007 21:18
Mesh Conversion Problem ms903 OpenFOAM Running, Solving & CFD 0 October 16, 2006 13:39


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