CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Meshing & Mesh Conversion (https://www.cfd-online.com/Forums/openfoam-meshing/)
-   -   [Commercial meshers] .CCM to OpenFoam mesh issue (https://www.cfd-online.com/Forums/openfoam-meshing/110783-ccm-openfoam-mesh-issue.html)

otq December 20, 2012 12:44

.CCM to OpenFoam mesh issue
 
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 December 21, 2012 08:21

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.

kwardle December 21, 2012 09:57

Quote:

Originally Posted by otq (Post 398446)
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 December 21, 2012 10:00

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.

otq December 21, 2012 19:02

I ran checkMesh and it said the mesh was fine. I haven't tried swapping the controlDic to ascii, I'll try that.

otq January 2, 2013 09:19

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 January 8, 2013 10:57

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.


All times are GMT -4. The time now is 04:31.