View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001157||OpenFOAM||[All Projects] Bug||public||2014-02-12 11:06||2015-06-16 15:34|
|Fixed in Version|
|Summary||0001157: faceAgglomerate crashes with hanging pointer error|
|Description||A geometry is meshed with snappyHexMesh and then the patches are agglomerated using the faceAgglomeration utility.|
faceAgglomeration crashes with the following error:
Agglomerating patch : geometry_ascii
--> FOAM FATAL ERROR:
hanging pointer at index 4 (size 50), cannot dereference
From function PtrList::operator
in file /home/user/OpenFOAM/OpenFOAM-2.2.x/src/OpenFOAM/lnInclude/PtrListI.H at line 150.
#0 Foam::error::printStack(Foam::Ostream&) in "/home/user/OpenFOAM/OpenFOAM-2.2.x/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#1 Foam::error::abort() in "/home/user/OpenFOAM/OpenFOAM-2.2.x/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#2 Foam::pairPatchAgglomeration::setEdgeWeights(int) in "/home/user/OpenFOAM/OpenFOAM-2.2.x/platforms/linux64GccDPOpt/lib/libpairPatchAgglomeration.so"
#3 Foam::pairPatchAgglomeration::agglomerate() in "/home/user/OpenFOAM/OpenFOAM-2.2.x/platforms/linux64GccDPOpt/lib/libpairPatchAgglomeration.so"
#5 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
Aborted (core dumped)
|Steps To Reproduce||Run the attached case with the latest git version of OpenFOAM 2.2.x|
|Tags||No tags attached.|
faceAgglomerationBug.tar.gz (71,910 bytes)
The case you sent is extremely large. We would need a small case which can
reproduce the problem for the faceAgglomeration.
|I am sorry, that I can can not give you a smaller case, but this problem only occurs with rather complex geometries. Simple geometries like boxes run smoothly.|
|In viewFactorsDict, the geometry patch is called "geometry_ascii", whereas it is called "geometry" in snappyHexMeshDict. Changing back to "geometry" in viewFactorsDict does not make the faceAgglomeration run, however it changes the error that is generated.|
|It depends on, which version of OpenFOAM you are using. As this bug is reported for version 2.2.x the resulting patch name will be "geometry_ascii". If you are using version 2.3.x then the name will be "geometry".|
You're right indeed, Martin.
Well, maybe the following could help better, then. The patch geometry_ascii has 10067 faces. I tried to use faceAgglomerate with different values for nFacesInCoarsestLevel, keeping all other settings unchanged.
||This bug still exists in 2.3.1 with meshes created by blockmesh.|
||@derekm: Can you provide a test case with such a mesh?|
faceglomtest.zip (66,107 bytes)
see attached file faceglomtest.zip two cases one fails the other passes only difference is the file faceglomtest/fail/constant/topAir/viewFactorsDict line 32
if set to 210 it fails set to 250 it passes in single processor
if you run it in parallel the threshold changes in value upwards.
The bug is in 2.4.0 as well O/S opensuse 12.3
I have spent a bit of time testing faceAgglomerate on your case with valgrind and the issue relates to the logic in
in which the results of agglomeratePatch were being used even if the return flag indicates that they are not valid. I have corrected the logic and your case now runs fine but I haven't tested any other cases. I have pushed the correction into OpenFOAM-2.4.x and OpenFOAM-dev; could you test either and report back?
faceAgglomerationTest.tar.gz (1,501,355 bytes)
I have added a new test case (faceAgglomerationTest). I tried faceAgglomeration on region FLUID using the new logic. Now it doesn't crash anymore, but it doesn't stop either. I have the impression, that faceAgglomeration is trapped in an endless loop for patch FLUID_to_plate.
Maybe it is not possible for the algorithm to connect more faces. In this case the algorithm should quit instead of endless trying.
I have just pushed a further fix into OpenFOAM-2.4.x to stop the agglomeration loop if a reduction in the number of faces is not achieved. It is not clear why the agglomeration stalls but at least this fix avoids the infinite loop. Let me know if it works.
If you need further agglomeration than this provides you will need to analyse the algorithm and look at the intermediate results to find out why the agglomerations stalls.
Last edited: 2015-06-16 10:03
Thank you henry, this fix works. Unfortunately for complex meshes the algorithm stops the agglomeration very early. This results in a very large number of agglomerations. For me viewFactor radiation is still not usable for real world problems.
Maybe I try to analyse the pairPatchAgglomeration code sometime. I already started to develop a new agglomeration logic, but I haven't finished it yet.
||We have not received any funding for the development or maintenance of the viewFactor radiation functionality since the initial release in 2011. If you or others can secure funding we will do more work on it alternatively if you can provide bug-fixes or improvements we can include them.|
||File Added: faceAgglomerationBug.tar.gz|
||Note Added: 0002820|
||Note Added: 0002821|
||Note Added: 0002861|
||Note Added: 0002862|
||Note Added: 0002870|
|2015-04-28 12:19||derekm||Note Added: 0004669|
|2015-05-28 13:03||wyldckat||Note Added: 0004825|
|2015-05-29 12:26||derekm||File Added: faceglomtest.zip|
|2015-05-29 12:31||derekm||Note Added: 0004837|
|2015-05-29 12:32||derekm||Note Edited: 0004837||View Revisions|
|2015-05-29 12:35||derekm||Note Edited: 0004837||View Revisions|
|2015-06-13 23:15||henry||Note Added: 0004923|
||File Added: faceAgglomerationTest.tar.gz|
||Note Added: 0004928|
|2015-06-15 16:14||henry||Note Added: 0004929|
||Note Added: 0004948|
|2015-06-16 09:57||henry||Note Added: 0004949|
||Note Edited: 0004948||View Revisions|
|2015-06-16 15:33||henry||Status||new => resolved|
|2015-06-16 15:33||henry||Resolution||open => fixed|
|2015-06-16 15:33||henry||Assigned To||=> henry|