View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001465 | OpenFOAM | Bug | public | 2014-12-19 11:35 | 2014-12-29 12:42 |
| Reporter | arnaud6 | Assigned To | henry | ||
| Priority | high | Severity | crash | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Platform | centOS 6.3 | OS | kernel Linux 2.6.2-279.el6.x86_6 | OS Version | GNOME 2.28.2 |
| Summary | 0001465: openfoam fluent3DMeshToFoam error message "new cannot satisfy memory request ..." | ||||
| Description | I have a 160M cells unstructured mesh of fluent ASCII .cas type. I would like to convert it using fluent3DMeshToFoam but it crashes just before the stage "writing mesh ...." with the error message "new cannot satisfy memory request. This does not necessarily mean you have run out of virtual memory. It could be due to a stack violation caused by e.g. bad use of pointers or an out of date shared library" The max memory taken by this job is 100Gb and I run it on 512Gb workstation, so it may not be memory related. On cases of 15M and 40M cells run on the same workstation, the utility runs until the end without any problems. I have tried different things to overcome the issue but none of them worked: *create a new utility to reduce the writing precision at the writing mesh step (I have changed the "10u" value by "6u") *write in binary (keeping the writing precision of 6) in the controlDict file of my case | ||||
| Steps To Reproduce | Use a fluent ASCII mesh in a .cas file (160M cells for me) and run fluent3DMeshToFoam <name_file.cas> -scale 0.001 | ||||
| Tags | No tags attached. | ||||
|
|
Just a couple of quick questions, regarding the mesh with 160M cells: 1. How many vertexes and how many faces does it have? 2. How many cells does it have for each type of cell? |
|
|
Hello Wyldckat, Thanks for your quick answer ! Number of vertexes 150889490 (151M) Number of faces 477037641 (477M) Cells 161858450 (162M) Number of cells per type (approximatively) Hexaedra 129M Prisms 4.6M wedges 0 Pyramids 14M tet wedges 0 tetrahedra 10.5M polyhedra 5M (half of the cells concerned contains 9 faces) What do you think about it ? |
|
|
None of the numbers go even near the 2^31 - 1 limit for 32-bit signed integer, which is 2,147,483,647. Which leaves me to suspect a few possibilities: a) I vaguely remember reading about a format converter among OpenFOAM's utilities that is not able to handle polyhedral cells... But I can't figure out if it's "fluent3DMeshToFoam" the one that can't handle it. b) The file extension ".cas" doesn't look familiar enough to me. I think that ASCII ".msh" is the only format supported by OpenFOAM for Fluent-type meshes. Perhaps you should double check if you can export the original mesh first to ASCII ".msh" instead. c) "fluent3DMeshToFoam" relies on "flexLexer" to do most of the file parsing. Perhaps the limitation is reached by this particular part of the code, which is somewhat automatically generated. d) Number of zones and/or names might be relevant to diagnose the problem. e) There might be some _alien_ characters in the names of the boundaries and/zones, which is leading to an infinite loop. For example, if you have a patch named "inlet(10m/s)", would likely be more than enough to cause this problem. In either case, my advice is that you try the following steps and report back here with the results found: 1. Try exporting to ".msh" format. And I don't mean simply renaming the file ;) 2. If this is to be diagnosed and fixed, a small example mesh is necessary, with which this issue can be reproduced. Not only because 100GB is way too complicated to debug, but because it's somewhat hard to access workstations with that amount of RAM. And not everyone has access to tools that can generate Fluent meshes. 3. Addendum to step #2: Don't forget that polyhedral cells are the ones that are suspicious here. A mesh with only 50000 of those cells might be enough to trigger the same error message. 4. Double and triple check all names of the patches and zones. Output the list to TXT if necessary. If you can provide this list, it could perhaps suffice to diagnose this bug, although the names therein might be subject to confidential status... so you might want to rename them before uploading ;) |
|
|
I can give you some update on the testing I have been doing. 1)In fact, I am exporting in .msh since the beginning, and I was renaming the file into a .cas. It was better to use a .cas, as the problematic boundaries where automatically renamed differently. So no improvement using a .msh than using a .cas, it crashes exactly at the same point. 2)For the test case, unfortunately the 2 reduced models I have - 15M and 40M cells are converted properly ! I am investigating if I can find one small case with the problem. 3)It may come from the "flexLever", yes. That was my first thought about this issue. Well, I don't have enough experience to fully understand a meshing code related problem. Is the "flexLever" acting when the writing of the mesh (or just before) is called ? 4)Poly looks good because I have been able to convert a fluent mesh with poly into openfoam (1M of poly over 40M cells). I think it is well supported by the fluent3DMeshToFoam. 5)My boundary conditions look good as well, and usually openfoam is complaining when something is going wrong with the names of them. For example, a boundary with "/" is not accepted. I am looking into new models to see if this problem is really persisting or only specific to my case. If you have any ideas meanwhile, please let me know. It is really frustrating to be stuck at that point ! Thanks for your help and your guidelines ! |
|
|
Comments on the details you've provided: 3) "flexLexer" assists in parsing the file contents, in other words, it assists in figuring out which piece of information is a point/vertex, which is the name, which is the type, and so on. Sort of like parsing a CSV file, but for a lot more complex scenarios :) Problem is that every "once in a blue moon" there is some corner case where the parser might simply not be prepared to handle a particular character or group of characters. 5) Something I learned some time ago when using OpenFOAM is that the user should never assume anything. In other words, just because one expects something to act the same way it always does, might lead to a situation this assumption leads to the wrong diagnosis, simply because a very tiny and yet very different detail was overlooked. If the problem has to do with the "lexer", then OpenFOAM might not contemplate diagnosing a specific operation that can go wrong. For example, the crash might occur while the parser is still searching for the end of the name of the boundary, even before giving said name to OpenFOAM's name validation algorithm. Beyond this, since you haven't provided a test case yet, then please try using the latest OpenFOAM 2.3.1. With any luck, this issue was already fixed sometime in the 2.3.x bug fix version and has made it into 2.3.1. |
|
|
Hello Wyldckat, I am coming with some fresh news. I have managed to overcome my problem! Here is how I did. I have created 3 test cases with an increasing number of cells, with and without poly. -50M cells worked in the 2 cases (with and without poly) -84M cells worked in the 2 cases (with and without poly) -151M cells crashed in the 2 cases (with and without poly) So the problem was not "poly-related" I guess. Then, I set all the debug flags to 2 in /etc/controlDict file to all the flags related to my case, so related to "mesh" or "poly" or "IO". My "memory" crash was happening just before the "writing mesh" stage. In fact, it corresponds to the storing of the major faceZone of my case (faceZone of 400M faces !). As it appears that I don't need to save this faceZone for future operations, I have used the option provided by the fluent3DMeshToFoam which is -ignoreFaceGroups. Ignoring the faceZone of 400M faces solved my problem! I am really sorry but I can't update any testcase here on the bug report. Firstly because it is confidential and secondly because I am unable to create a small test case crashing... I am sorry about it and I hope you understand my difficulties to produce it. Thanks a lot for your explanations ! Now I know what the "flexLever" is used for ;) cheers |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2014-12-19 11:35 | arnaud6 | New Issue | |
| 2014-12-19 12:58 | wyldckat | Note Added: 0003340 | |
| 2014-12-19 16:22 | arnaud6 | Note Added: 0003341 | |
| 2014-12-20 16:28 | wyldckat | Note Added: 0003344 | |
| 2014-12-23 09:06 | arnaud6 | Note Added: 0003359 | |
| 2014-12-23 09:07 | arnaud6 | Note Edited: 0003359 | |
| 2014-12-29 10:00 | wyldckat | Note Added: 0003370 | |
| 2014-12-29 12:38 | arnaud6 | Note Added: 0003390 | |
| 2014-12-29 12:42 | henry | Status | new => closed |
| 2014-12-29 12:42 | henry | Assigned To | => henry |
| 2014-12-29 12:42 | henry | Resolution | open => no change required |
