CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Meshing & Mesh Conversion

[Commercial meshers] .CCM to OpenFoam mesh issue

Register Blogs Community New Posts Updated Threads Search

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   December 20, 2012, 13:44
Default .CCM to OpenFoam mesh issue
  #1
otq
New Member
 
Christopher Hughes
Join Date: Oct 2012
Posts: 27
Rep Power: 14
otq is on a distinguished road
I have a .ccm file that was exported by STAR-CCM+ version 7.04.011. I have already ensured that within STAR-CCM+ it is a valid mesh. When I export the mesh into a .ccm file and convert it using ccm26ToFoam the program runs fine.

The problem arises when I try to use paraFoam to view the mesh. It crashes. I looked at the cellId file for the converted mesh and noticed the following
FoamFile
{
version 2.0;
format binary;
class volScalarField;
location "0";
object cellId;
}
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

dimensions [0 0 0 0 0 0 0];

internalField nonuniform List<scalar>
152559
(^@^@^@^@^@�v@^@^@^@^@^@�s@^@^@^@^@^@^Y�@^@^@^@^@` ��@^@^@^@^@^@�s@^@^@^@^@�^G�@$
�@^@^@^@^@^@�ȡ@^@^@^@^@^@]�@^@^@^@...

where the nonsense symbols go on for quite awhile.
The 152559 number makes sense because that is the total number of cells in the .ccm mesh. Am i exporting the .ccm file wrong or what is going on to cause this error?
otq is offline   Reply With Quote

Old   December 21, 2012, 09:21
Default
  #2
otq
New Member
 
Christopher Hughes
Join Date: Oct 2012
Posts: 27
Rep Power: 14
otq is on a distinguished road
I thought it was because I still had interfaces from the .ccm file when I tried to convert the mesh. I removed the interfaces since the source code documentation said ccm26ToFoam cannot handle them, but the same error occurs.
otq is offline   Reply With Quote

Old   December 21, 2012, 10:57
Default
  #3
Senior Member
 
Kent Wardle
Join Date: Mar 2009
Location: Illinois, USA
Posts: 219
Rep Power: 21
kwardle is on a distinguished road
Quote:
Originally Posted by otq View Post
format binary;
The symbols are because the format is binary. What does checkMesh say? I have used interfaces in ccm+ and converted to openfoam with no problems* in the past. That said (*), the meshes always have had some quality issues. Post the output of checkMesh and perhaps someone can give a useful comment.
kwardle is offline   Reply With Quote

Old   December 21, 2012, 11:00
Default
  #4
Senior Member
 
Kent Wardle
Join Date: Mar 2009
Location: Illinois, USA
Posts: 219
Rep Power: 21
kwardle is on a distinguished road
One other thing, I don't have any experience running with binary format. Perhaps the OF reader in ParaView cannot read this? I would be surprised, but that might be the case. Try to change the writeFormat to ascii in controlDict and see how things go.
kwardle is offline   Reply With Quote

Old   December 21, 2012, 20:02
Default
  #5
otq
New Member
 
Christopher Hughes
Join Date: Oct 2012
Posts: 27
Rep Power: 14
otq is on a distinguished road
I ran checkMesh and it said the mesh was fine. I haven't tried swapping the controlDic to ascii, I'll try that.
otq is offline   Reply With Quote

Old   January 2, 2013, 10:19
Default
  #6
otq
New Member
 
Christopher Hughes
Join Date: Oct 2012
Posts: 27
Rep Power: 14
otq is on a distinguished road
I changed the controlDict file as suggested and the cellId is now showing proper numbering instead of the binary jargon; however, when trying to run paraFoam the following error occurs.

--> FOAM FATAL IO ERROR:
inconsistent patch and patchField types for
patch type symmetryPlane and patchField type calculated

file: /home/chris/OpenFOAM/chris-2.1.1/run/Supercritical/multiRegionHeater/0/p::boundaryField::.* from line 25 to line 26.

From function fvPatchField<Type>::New(const fvPatch&, const DimensionedField<Type, volMesh>&, const dictionary&)
in file /home/opencfd/OpenFOAM/OpenFOAM-2.1.1/src/finiteVolume/lnInclude/fvPatchFieldNew.C at line 164.

FOAM exiting

Segmentation fault (core dumped)
Is this an error in my .ccm file or am I not converting something else? Again checkMesh says that everything is ok, though it mentions some errors in the boundary definition specifically:

Checking topology...
****Duplicate boundary patch 2 named Default of type wall.
Suppressing future warnings.
***Boundary definition is in error.
Cell to face addressing OK.
Point usage OK.
<<Found 7 neighbouring cells with multiple inbetween faces.
Upper triangular ordering OK.
<<Writing 14 unordered faces to set upperTriangularFace
Face vertices OK.
*Number of regions: 13
The mesh has multiple regions which are not connected by any face.
<<Writing region information to "0/cellToRegion"

Checking patch topology for multiply connected surfaces ...
Patch Faces Points Surface topology
Default 3498 6948 ok (non-closed singly connected)
Symmetry 532 1068 ok (non-closed singly connected)
Default 9803 19382 ok (non-closed singly connected)
Symmetry 532 1068 ok (non-closed singly connected)
Default 3602 7156 ok (non-closed singly connected)
Symmetry 548 1100 ok (non-closed singly connected)
Default 6726 13356 ok (non-closed singly connected)
Symmetry 532 1068 ok (non-closed singly connected)
Default 3602 7156 ok (non-closed singly connected)
Symmetry 548 1100 ok (non-closed singly connected)
Default 13285 26512 ok (non-closed singly connected)
Symmetry 7224 8828 ok (non-closed singly connected)
Inlet 539 702 ok (non-closed singly connected)
Outlet 539 702 ok (non-closed singly connected)
Default 96 178 ok (non-closed singly connected)
Inlet 12 26 ok (non-closed singly connected)
Outlet 12 26 ok (non-closed singly connected)
Symmetry 100 186 ok (non-closed singly connected)
Default 1808 3592 ok (non-closed singly connected)
Symmetry 1450 2838 ok (non-closed singly connected)
Default 6513 12848 ok (non-closed singly connected)
Symmetry 1352 2706 ok (non-closed singly connected)
Default 1861 3698 ok (non-closed singly connected)
Symmetry 1453 2844 ok (non-closed singly connected)
Default 3472 6894 ok (non-closed singly connected)
Symmetry 1348 2698 ok (non-closed singly connected)
Default 1863 3702 ok (non-closed singly connected)
Symmetry 1470 2878 ok (non-closed singly connected)
Default 25377 50240 ok (non-closed singly connected)
Symmetry 516 1036 ok (non-closed singly connected)
The model runs in STAR-CCM+ and has no issues with the boundary.
otq is offline   Reply With Quote

Old   January 8, 2013, 11:57
Default
  #7
otq
New Member
 
Christopher Hughes
Join Date: Oct 2012
Posts: 27
Rep Power: 14
otq is on a distinguished road
I was able to fix the issue. I was trying to use a solver template that had some leftover files from the previous mesh, creating a brand new folder helped.

I also had to go back and name every single surface in the STAR-CCM+ model before transfering it to a .ccm file and converting. The openfoam converter does not like the default boundary that STAR-CCM+ uses for unnamed surfaces.
otq is offline   Reply With Quote

Reply


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 Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Map of the OpenFOAM Forum - Understanding where to post your questions! wyldckat OpenFOAM 10 September 2, 2021 06:29
decomposePar problem: Cell 0contains face labels out of range vaina74 OpenFOAM Pre-Processing 37 July 20, 2020 06:38
[snappyHexMesh] Snappy Hex Mesh - issue with smoothness of the model edges olek.warc OpenFOAM Meshing & Mesh Conversion 1 August 31, 2018 12:31
[snappyHexMesh] Snappyhex mesh: poor inlet mesh Swagga5aur OpenFOAM Meshing & Mesh Conversion 1 December 3, 2016 17:59
[snappyHexMesh] snappyHexMesh won't work - zeros everywhere! sc298 OpenFOAM Meshing & Mesh Conversion 2 March 27, 2011 22:11


All times are GMT -4. The time now is 23:22.