|
[Sponsors] |
November 11, 2004, 10:19 |
Star mesh conversion
|
#1 |
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 |
|
January 13, 2005, 12:48 |
Hi,
I am attempting to imp
|
#2 |
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 |
|
January 13, 2005, 13:13 |
Hi Andy,
The limitation is
|
#3 |
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 |
|
January 13, 2005, 13:20 |
Hi Mattijs,
Sorry - I shou
|
#4 |
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 |
|
January 13, 2005, 13:40 |
Could you rerun couplePatches
|
#5 |
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) |
|
January 14, 2005, 09:18 |
Hi Andrew,
you can have a
|
#6 |
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 |
|
January 14, 2005, 11:28 |
Hi Mattijys,
Sorry for the
|
#7 |
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 |
|
January 14, 2005, 11:58 |
So you still get the 'Cannot
|
#8 |
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. |
|
January 14, 2005, 12:16 |
Yes - lowering the tolerance
|
#9 |
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... |
|
January 14, 2005, 12:37 |
Hi Andrew,
the message me
|
#10 |
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. |
|
January 14, 2005, 13:50 |
Hi Mattijs,
Increasing the t
|
#11 |
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... |
|
January 19, 2005, 08:50 |
Hi Andrew,
thanks for the
|
#12 |
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 |
|
January 19, 2005, 11:27 |
Hi Mattijs,
How about the
|
#13 |
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) ... |
|
January 19, 2005, 11:55 |
Hi Andrew,
pretty impressi
|
#14 |
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) |
|
January 19, 2005, 12:24 |
Hi Andrew,
forgot to menti
|
#15 |
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. |
|
April 17, 2005, 09:15 |
Hi I was reading through the t
|
#16 |
Member
Duderino
Join Date: Mar 2009
Posts: 40
Rep Power: 17 |
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 |
|
April 18, 2005, 06:45 |
1) reorder faces on coupled pa
|
#17 |
Senior Member
Mattijs Janssens
Join Date: Mar 2009
Posts: 1,419
Rep Power: 26 |
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. |
|
April 20, 2005, 10:57 |
Hi Mattijs,
Thanks for your
|
#18 |
Member
Duderino
Join Date: Mar 2009
Posts: 40
Rep Power: 17 |
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? |
|
April 20, 2005, 12:29 |
1) is not a problem. All bound
|
#19 |
Senior Member
Mattijs Janssens
Join Date: Mar 2009
Posts: 1,419
Rep Power: 26 |
1) is not a problem. All boundary faces should point outwards. OpenFOAM takes care of the opposing normals when mapping vectors.
|
|
April 20, 2005, 17:00 |
So I wonder why the vectors po
|
#20 |
Member
Duderino
Join Date: Mar 2009
Posts: 40
Rep Power: 17 |
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 |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Star CCM Overset Mesh Error (Rotating Turbine) | thezack | Siemens | 7 | October 12, 2016 12:14 |
[snappyHexMesh] No layers in a small gap | bobburnquist | OpenFOAM Meshing & Mesh Conversion | 6 | August 26, 2015 10:38 |
Moving mesh | Niklas Wikstrom (Wikstrom) | OpenFOAM Running, Solving & CFD | 122 | June 15, 2014 07:20 |
[Gmsh] 2D Mesh Generation Tutorial for GMSH | aeroslacker | OpenFOAM Meshing & Mesh Conversion | 12 | January 19, 2012 04:52 |
fluent add additional zones for the mesh file | SSL | FLUENT | 2 | January 26, 2008 12:55 |