reconstructParMesh stuck on reconstructing mesh if the mesh is in binary and too large
Summary
reconstructParMesh get stuck on writing mesh stage if the mesh format is in binary and too large (>50mil cells)
Steps to reproduce
Not sure how to reproduce, but this has occurred twice when I had to mesh 2 large cases (>50mil cells) is there an issue with the label size? OpenFoam is using 32bit label
Example case
Unable to create example
What is the current bug behaviour?
The process hangs when writing "faces" file, without any error, task manager shows that CPU is still used, but RAM usage is constant, no HDD usage either. Changing the mesh format to ascii, either with foamFormatConvert or running snappyHexMesh in ascii write format, will allow reconstructParMesh to reconstruct successfully. However, if I were to try converting the ascii mesh back into binary using foamFormatConvert, it will get stuck at the "faces" file too.
What is the expected correct behavior?
Error doesn't occur for smaller meshes (<30mil), I'm not sure if there's a threshold for binary format to stop working
Relevant logs and/or images
I opened both the ascii "face" file and the binary "face" file in notepad++ and it appears that the binary version had an extra entry when being written to. It should have only 184794251 instead of 184794252
In comparison, the successfully converted owner file shows that both numbers are matching when the conversion is successful. Also the note in the header shows that there are only 184794251 faces
I suppose this is more than a reconstructParMesh bug since it occurs in foamFormatConvert as well, maybe something to do with the IO writing
Copying the files over to a linux system to test the conversion from ascii to binary, it kind of works and converts as expected. This bug seems to only occur on windows
Environment information
- OpenFOAM version : v2312
- Operating system : Windows 10
- Hardware info : ?
- Compiler : mingw