|
snappyHexMesh - memory corruption (OF-v. 2.2.x) [SOLVED]
Good morning everybody,
i'm not sure if this is actually a bug or just an unfortunate effect of different wrong settings or a bad mesh, but since it's not a regular OF-error but a memory-corruption i'll post it here. i'm currently doing my diploma-thesis at university, which includes working with OpenFoam. (v. 2.2.x) From one of my predecessors working on the project i have a basic case for mesh generation, including several *.stl-files for the geometry, which resembles a turbine-cascade. The problem occurs while processing the outlet.stl and looks like this: Code:
*** glibc detected *** snappyHexMesh: malloc(): memory corruption: 0x0000000006051b50 ***Since i have no access to valgrind and next to zero experience with gdb i simply started digging, by searching for the provided info-strings to see where the error actually occured an traced it to: /src/mesh/autoMesh/autoHexMesh/autoHexMeshDriver/autoSnapDriverFeature.C the last output given was from line 2853 to 2888 (codeblock commented with "//Count") By inserting my own Info-outputs i reached syncTools::syncPointList ( ...) Of course by inserting said info-outputs i changed the memorymap and from a certain length of output-string onwards the whole error collapsed to: Code:
snappyHexMesh: malloc.c:4625: _int_malloc: Assertion `(unsigned long)(size) >= (unsigned long)(nb)' failed.Since something like that can always be the consequence of corrupted base-data: surfaceCheck for said *.stl looks like this. Code:
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //Code:
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //If more data on the used geometry or one of the Dict-files is needed, just say so, i'll post it. Any input is appreciated... thanks in advance.. Alex |
Greetings Alex and welcome to the forum!
Quote:
Quote:
Quote:
Was Icc used with the "fast math" option turned on? Best regards, Bruno |
Hi Wyldckat,
thanks for the response. Icc is Version 12.0.4.191 Build 20110427 You think that might be reason enough for this error? RAM and Hardware-failure: I tested it on three different machines with 8, 24 and 64 GB RAM, everytime, exact same error... so i guess it's neither of it. Since we use a shared-installation at the institut, we're not supposed to compile the whole package for ourselves. If i try however, to compile the autoMesh-module with wmake CC or CXX=/usr/bin/gcc-4.3 i get a bunch of compiling-errors about "undefined reference to" ... I'll see what i can do about that inequality expression.. that may give another clue.. But like i said, that only occurs if i shift the whole memorymap by inserting a pretty long outputstring somewhere before the failing expression in the source-code.. The final geometry is "cut in form" by repeatingly using snappyhexmesh with different *.stl-files. Also, snappyHexMesh writes out the already cut mesh before starting the morphing-phase. checkMesh reports for both meshes a final evaluation of "mesh ok". If i take a look at the already cut out mesh with paraFoam, it has a bad case of ugly staircase. The mesh is cut in/with the right plane, but the cells are not yet snapped to fit it. Thats what the morphing should do, but there it crashes. I don't know if "fast math" was used, but i can ask. You think there was too much algebraic optimization for performance-reasons? best regards Alex |
Hi Alex,
Gcc 4.3 is no longer supported in OpenFOAM 2.2. The minimum is Gcc 4.5. As for ICC, yes that could be a big problem. The supported versions of ICC are recommended, simply because ICC is sometimes slower to catch up to GCC, in terms of supported features, where some of those features are necessary for OpenFOAM to be built properly. There is another possibility: if OpenFOAM was built on a machine with a more recent Linux Distribution and then shared among all other machines, that could lead to some incompatibilities between the base C/C++/Intel libraries. Yet another possibility is that the machines you're using are AMD based and the OpenFOAM build you're using might have been built on an Intel machine, leading to this crazy issue. To check this, run: Code:
lscpuLast but not least, if you share a small test case that reproduces the crash you get, it would help to make sure if this is only a problem you're having or if it's a specific problem with OpenFOAM. edit: from my experience, snappyHexMesh is very sensitive to math precision. As for fast math option itself, check this: http://www.cfd-online.com/Forums/blo...-amd-cpus.html - sorry, it's a long read, but you should also check the comments, where fast math is mentioned ;) Best regards, Bruno |
Hey,
I run all my simulations on the provided servers/workstations which are all equipped with intel-processors. Gcc-version on these ones is 4.3 and 4.6 but that changed only recently. (the update to 4.6). ICC (which was used for compiling) is still 12.0.4 on these machines. I forwarded the information about a recommended update to 12.1 / 13.1 .. When this is done and helped, i'll tell you. About a test-case. I'll try, but the problem seem's limited to the one special case i have, because all the tutorials and other test-cases i had, worked fine so far. The 5.9 faces per Cell (which indeed sound strange) don't seem to affect the other snappyHexMesh-procedures in the overall build-script for the final geometry. I'll have a second look at the *.stl-file in question but since the whole case isn't exactly what you would call "properly documented", altough it's relativly complex, this is more trial&error than it sould be. I'm not sure i can share this case, since it resembles a part of a test-bench used here at the department. If i'm allowed to, i'll upload it. edit: thanks for the information on snappyhexmesh and fastmath. I didn't know there were such big differences in performace from gcc to icc.. guess thats why we use the icc-compiler.. But for ffast-math: Does the "not guaranteed (numerical) precision" affects every calculation or does it only come into play if i use extreme write-precision or tolerance-values? For instance 8 to 10 decimal places or more? Or does it favor things like numerical diffusion and overall rounding-errors in general? Best regards Alex |
Hi Alex,
I had to go look for at least one example: http://forums.anandtech.com/showthread.php?t=1796118 Mmm... from this, I would say that at first it shouldn't affect much. But I've had a few situations where an error of something like 1e-5 was more than enough for sHM to complain about not being able to snap to the geometry, simply because "a >= b" wasn't giving the right result. Although solver-wise, the small errors could accumulate over the millions of calculations that solvers usually do. Then there are the trigonometrical functions, where faster versions can have rather higher errors, given the accumulation of inherent mathematical operations. I would suggest that you test the tutorials in OpenFOAM that use sHM to ascertain if any of them crashed or gave any strange messages, because back when I got that strange error, was with one of the tutorials. Best regards, Bruno |
sHM-tutorials
Hi Bruno,
i just ran all OF-tutorials which had a sHMDict, none of them crashed with a memorycorruption or any other sort of error. Though some of them also had relativly odd numbers for the "faces per cell", like 6.095 or 6.1512.. but always > 6. In my case it's 5.9.. from the beginning (after blockMesh). But the first sHM-operation runs smoothly. After this there are some topo-set-operations, then comes the second sHM-operation which crashes. So i guess this problem is _very_ specific to my case. Or at least some of the files related to it. I'll keep experimenting, maybe something turns up. I'm also still waiting for the update on icc 12.1/13.1 and the rebuilt, but the person responsible is out of the office is far as i know. Also thanks for the link on ffast-math. Guess if you don't need the "extreme" math-precision in your case, you might as well take the performance-increase which comes with it. Do you use ffast-math for your builds or is this a no-go on principal for you? Best regards Alex |
solved..
it's solved. The *.stl used for this operation had
a) some negative coordinates and was b) apparently a little bit to small, to cut the provided mesh along all edges. So, even before doing the point-sync or somewhere in the process, it compared to points/values not compatible with each other and crashed.. aaand, it was corrupted base-data. -.- Regardless, thanks for your help, it turned up some other things i'll have a look at... best regards Alex |
Hi Alex,
I'm glad you've found the problem! In reply to your question: Quote:
Best regards, Bruno |
Hi Alex,
I have to apologize for something, namely about this: Quote:
But apparently this is normal in OpenFOAM, namely to have these non-rounded kinds of values, when there are cells that are not of the type "hexahedra". Best regards, Bruno |
| All times are GMT -4. The time now is 04:52. |