[roadRunner]

Hi,

im using ccm26toFoam to convert starccm+ meshes to OF, and it works perfectly. However, when I try to import a very big mesh, ~70mil cells, it reports this (double free or corr.) and crashes. This is the first time I ever had a problem with this.

I assume this is a problem related to ccm plugin. From what I found online, it seems that it's a memory management problem, which is strange since this program usually works perfectly except in this case.

Also i'm sure that file isn't corrupted and that the mesh is valid, since it has several regions, from which small ones are imported with no problems, only the biggest fails.

I work in science, and I have all the licences for all the stuff.

Is there a newer version of the ccm plugin?

I was thinking, maybe I'm supposed to increase maximum array size or something like that, that seems plausible explanation...

Its extremely frustrating to have the mesh ready and unable to access it....

Is it possible to import ccm mesh to fluent? Without using OF? Or some other format? VTK?

[roadRunner]

As I compile libccmio, I get these warnings:

libccmio/ccmioutility.c:302:10: warning: attempt to free a non-heap object ‘dims’ [-Wfree-nonheap-object]
free(dims);
^

and:

ccmioutility.c.text+0xbcf): warning: the use of `mktemp' is dangerous, better use `mkstemp' or `mkdtemp'


is this relevant?

[wyldckat]

Originally Posted by roadRunner

However, when I try to import a very big mesh, ~70mil cells, it reports this (double free or corr.) and crashes. This is the first time I ever had a problem with this.

Quick questions:

1. Do you mean "70 000 000" cells or "70 000 000 000"?
2. Can you reproduce the problem with a simple hexahedral, tetrahedral or even polyhedral mesh with the same number of cells?
3. Did you select both the volume and the surface meshes before exporting?
4. Did you select any special internal interface surface meshes?

[roadRunner]

Thanks for your reply. However, I have to object to moving the thread, in my opinion it was in an appropriate position.. Now it's visibility has been greatly reduced.

Mesh has around 70 million cells.

As I wrote in my original thread, this procedure has been validated with different meshes of the same approach just with different number of cells.
What I'm doing now: I'm recreating the same mesh with the exact same settings, just with the number of mesh that has been shown to work.

Yes, I used special interfaces, but those are ignored by the utility. The mesh is "merged" together by the utility and exported successfully.
I should point out that the correct approach is not to avoid using those special interfaces, because they are proven not to create issues on a number of other occasions.

This is a major problem in my work, and will create a lot of problems for me. Especially because I have no idea how to solve it as this is not an OF error but that of the ccm library (in my opinion).

[wyldckat]

Greetings roadRunner,

Originally Posted by roadRunner

However, I have to object to moving the thread, in my opinion it was in an appropriate position.. Now it's visibility has been greatly reduced.

OK, I've moved again back, namely from OpenFOAM Other Meshers: ICEM, Star, Ansys, Pointwise, GridPro, Ansa, ... to OpenFOAM Meshing & Mesh Conversion - although, please keep in mind that the other sub-forum is the correct one for this topic.

Originally Posted by roadRunner

Mesh has around 70 million cells.

Mmm... OK, I was afraid that one of the counters (points, faces or cells) might be hitting the limit of 2^31 = 2147483648, but 70000000 is still very far away from that limit.

Originally Posted by roadRunner

As I wrote in my original thread, this procedure has been validated with different meshes of the same approach just with different number of cells.
What I'm doing now: I'm recreating the same mesh with the exact same settings, just with the number of mesh that has been shown to work.

Please let us know if with a smaller number of cells it works as intended.

Because if it does work, then my suspicion is that there is something wrong in the mesh with 70 million cells. If there is a missing point that is incorrectly addressed, it could lead to ccm26ToFoam to try and create a cell that has a point with the index "-1", which would result in accessing the memory location in the array that is before the 0 index, which would in turn lead to memory corruption. This would explain why it tried to free twice the same memory place.

The other thing to check for is the minimum and maximum number of vertices a cell has in your bigger mesh, since this might be related to the "dims" problem.

Originally Posted by roadRunner

Yes, I used special interfaces, but those are ignored by the utility. The mesh is "merged" together by the utility and exported successfully.
I should point out that the correct approach is not to avoid using those special interfaces, because they are proven not to create issues on a number of other occasions.

That is very good to know! Usually I always suspect special interfaces, since they are not always supported by the mesh converters and can lead to problems when converting

Originally Posted by roadRunner

This is a major problem in my work, and will create a lot of problems for me. Especially because I have no idea how to solve it as this is not an OF error but that of the ccm library (in my opinion).

I can try and debug the utility, but I'll need a mesh to reproduce the error and another mesh that doesn't give this kind of error, in order to ensure that I don't break something while trying to solve the problem.

You can send me a download link via PM, if you prefer to not have it available publicly. And if the mesh has a sensitive geometry in it, then please try meshing something more generic, but that still reproduces the same problem.

[roadRunner]

Dear Bruno,
thank you for your answer and suggestions.

I created another ~40m cell mesh, and it seems to produce the same error. So it seems that you're right, mesh is actually corrupted somehow. Or at least the biggest region. Small ones import with no problem.
Anyway, I have to roll back my meshing to the previous working version and move on from there. I will keep you posted.

Thank you for your suggestion, my geometry is in fact sensitive. Now I believe that I would be unable to reproduce this problem for a simple geometry. But I will try in order to rule out mesh size problem.
If I'm unable to solve this on my own, I will contact you.

Thanks again

ps I will report back in any case

[roadRunner]

I was wrong, the smaller mesh actually works. To be more precise it works if I only convert the biggest region. If I try to do all, it brakes, which is consistent with what I've seen so far.

Ive tried to do some debugging myself:

It brakes exactly at line 714 of ccm26ToFoam.C:

ReadVertices(err, vertices, foamPointMap, foamPoints);

But the funny thing is: the subroutine is completed successfully! Which means, when I write out something at it's end, it's written out, which wouldn't be the case if there were problems.

So this has to be related somehow to memory management.

So anyway, this looks bad. Any idea how to proceed?

Also, when I run it on a different system, i get:

Reading state 'default' (Default state)
nPoints:309668433
bounding box:(0 0 0) (0 0 0)

--> FOAM FATAL ERROR: 
"Error reading cells"

    From function CheckError
    in file ccm26ToFoam.C at line 167.

FOAM exiting

from the code:

    CCMIOID mapID;
    CCMIOReadCells(&err, id, &mapID, &cellType[0], 0, nCells);
    CCMIOReadMap(&err, mapID, &mapData[0], 0, nCells);
    CheckError(err, "Error reading cells");

and

void CheckError(CCMIOError const &err, const Foam::string& str)
{
    if (err != kCCMIONoErr)
    {
        FatalErrorIn("CheckError")
            << str << exit(FatalError);
    }
}

I don't think this is a mesh error because it works in every possible situation except with a higher number of cells. It even works if I read in a specific region of the mesh (I export a specific region to .ccm) and not for the whole thing..




Thanks for reading,

[wyldckat]

Hi roadRunner,

Without a test case, there isn't much I can do. All signs point to memory corruption when reading the ".ccm" file, on both machines.
The interesting detail is that the second machine is able to hold its own without crashing, but points out that there is "nothing" inside the mesh, given that even if there are over 300 million points, the bounding box is empty.

There might be a missing point on the list, or some weird file corruption is going on... which reminds me:

1. What's the file size of the ".ccm" file?
2. And what do the internal mesh reports give you in Star-CCM+?

There is a possible workaround, which is to output one region at a time, or to output a few regions at a time. Then you import into several OpenFOAM cases and then merge all of the meshes back into a single case. The you might need some uses of createPatch and possibly stitchMesh to make the mesh whole again, it necessary.

Best regards,
Bruno

[roadRunner]

Hi Bruno,
I have to apologize, I was busy with other stuff, so this thread slipped my mind.

I tried different approach, where I switched to tetrahedral mesh (everything else kept the same) and it worked perfectly.

I'm also trying with polyhedral, but without BL, that hasn't worked so far.

So you were right, it is somehow a mesh problem. Especially, when I import the ccm file back to starccm, I get something like mesh invalid massage.
This is incredibly strange, because I only increased the mesh size a little bit, everything else was the same as in course meshes...

I would like to give you a test case, unfortunately I'm not allowed to share the geometry, or say what it is. I can make a mesh of a pipe with the same approach I used here and see what happens. -> I will try to do that today and send it over PM.

ccm file size is cca 22 gb.

Please note my gratitude for your help

[wyldckat]

Hi roadRunner,

Originally Posted by roadRunner

So you were right, it is somehow a mesh problem. Especially, when I import the ccm file back to starccm, I get something like mesh invalid massage.

Hold on, if even Star-CCM+ is unable to import the mesh, then there isn't much we can do on OpenFOAM's import side.

Clearly there is a weird cell formation somewhere in the mesh that results in this problem. Therefore, whichever problem this is, it's on Star-CCM+'s side. Very likely there is a flat or negative volume cell somewhere.

Creating at test case will likely not be very successful, given that the problem is likely due to a specific geometrical issue in your case, e.g. a very tight corner or a boundary layer addition gone wrong between two surfaces that are very close to one another.

There is however another thing you can do with the tetrahedral mesh, you can convert in OpenFOAM with polyDualMesh to create the dual mesh of the tetrahedral mesh, namely a polyhedral mesh. For more details, I quickly Googled for is and found this thread: http://www.cfd-online.com/Forums/ope...h-utility.html - although there are more on this topic.


In the meantime, I'm returning this thread to the right place, namely the mesh conversion sub-forum for commercial meshers.

Best regards,
Bruno

[abe]

Hi,

I am trying to convert a star mesh into OpenFOAM using ccm26ToFoam. The mesh is around 95 million cells with 500 million faces.
However, when I try to convert the mesh if fails. The error message is Foam::error:rintStack(Foam::Ostream&) .

when I tracked it down, I noticed the error happens at the following loop inside the ReadVertices,

forAll(foamPointMap, i) { foamPointMap[i] = mapData[i]; for (direction cmpt = 0; cmpt < dims; cmpt++) { foamPoints[i][cmpt] = verts[dims*i + cmpt]*scale; } }

Any advice or suggestion is most appreciated.

[abe]

Any ideas?

[alexeym]

Hi,

Since you are hiding mesh, could you at least post full printStack output? Less and less people want to spend time guessing what could be wrong.

[abe]

Unfortunately due to copy right issue I cannot share the mesh.
The terminal repost is as follow,

***********************
Create time
Reading state 'default' (Default state)
#0 Foam::error:rintStack(Foam::Ostream&) in "/c3se/priv/c3-hydro/Glenn/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#1 Foam::sigFpe::sigHandler(int) in "/c3se/priv/c3-hydro/Glenn/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#2 ? in "/lib64/libc.so.6"
#3 ? in "/c3se/users/asnaghi/Glenn/OpenFOAM/asnaghi-2.3.x/platforms/Opt/bin/ccm26ToFoam"
#4 ? in "/c3se/users/asnaghi/Glenn/OpenFOAM/asnaghi-2.3.x/platforms/Opt/bin/ccm26ToFoam"
#5 __libc_start_main in "/lib64/libc.so.6"
#6 ? in "/c3se/users/asnaghi/Glenn/OpenFOAM/asnaghi-2.3.x/platforms/Opt/bin/ccm26ToFoam"
Floating point exception (core dumped)
*************

Regards,

[alexeym]

And if you run the same command with Debug build of OpenFOAM? Since, this stack trace is rather useless, except, since it is Floating Point Exception, in general, it should not happen on the line you have posted in the first message.

[abe]

I have got similar error messages with other versions of OF. For smaller mesh size, the conversion works without any problem. Problem appears when the number of cells/faces are relatively large (500 million faces in my case). I was wondering whether it is related to definition of parameters in ccm26ToFoam.

[alexeym]

Debug build allow you to have more precise location of the error. Right now it is just a matter of guessing. Since it is your "Any ideas?" post, guess, a) nobody with the same error reads the forum, b) nobody wants to guess what is wrong, since your post lacks any relevant information.

[abe]

Following is the report from the debug version,

#0 Foam::error:rintStack(Foam::Ostream&) addr2line failed
#1 Foam::sigFpe::sigHandler(int) addr2line failed
#2 ? addr2line failed
#3 ?
#4 ?
#5 __libc_start_main addr2line failed
#6 ?
Floating point exception (core dumped)


I appreciate any comments, and help.

[alexeym]

Somebody misguided you, usual output of Debug version looks like (below is an example of crashed icoFoam on macOS):

Courant Number mean: 109996 max: 403684
#0  "Foam::error::printStack(Foam::Ostream&)" at printStack.C:272
#1  "Foam::sigFpe::sigHandler(int)" at sigFpe.C:134
#2  "_sigtramp" in /usr/lib/system/libsystem_platform.dylib
#3  ? in /usr/lib/system/libsystem_platform.dylib
#4  "Foam::symGaussSeidelSmoother::smooth(Foam::Field<double>&, Foam::Field<double> const&, unsigned char, int) const" at symGaussSeidelSmoother.C:238
#5  "Foam::smoothSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const" at smoothSolver.C:160
#6  "Foam::fvMatrix<Foam::Vector<double> >::solveSegregated(Foam::dictionary const&)" at fvMatrixSolve.C:196
#7  "Foam::fvMatrix<Foam::Vector<double> >::solve(Foam::dictionary const&)" at fvMatrixSolve.C:82
#8  "Foam::fvMatrix<Foam::Vector<double> >::solve()" at fvMatrixSolve.C:315
#9  "Foam::SolverPerformance<Foam::Vector<double> > Foam::solve<Foam::Vector<double> >(Foam::tmp<Foam::fvMatrix<Foam::Vector<double> > > const&)" at fvMatrix.C:1361
#10  "main" at icoFoam.C:69
#11  "start" in /usr/lib/system/libdyld.dylib
#12  ? in /usr/lib/system/libdyld.dylib

As you can all your "?" and "addr2line failed" are converted into file names and line numbers.

[abe]

Thank you alexeym. I am really grateful for your comment. I used the debug version I was provided. I am compiling another version myself.

However, I guess the problem comes from the number of faces as in the mesh I am trying to convert:
95187700 cells, 612345350 faces, 502047784 verts.

And the crashes happens at:
List<label> ccmFaces(size);

/Regards