|
|
|
|
|
2.3.x_scotch_8procs_error.png (3,426 bytes) |
|
|
2.4.x_scotch_4procs_error.png (15,581 bytes) |
|
|
2.4.x_scotch_8procs_error.png (11,839 bytes) |
|
|
Not sure if it's related to the errors I'm seeing or not, but it looks like mattijs submitted a bug report over a year ago to the scotch bug tracker that has yet to be resolved. I'll document the link here just in case it is relevant... http://gforge.inria.fr/tracker/index.php?func=detail&aid=17142&group_id=248&atid=1079 EDIT: I didn't find any non-manifold edges at the processor boundaries per mattijs' bug report, so my errors may not be related to mattijs' report. |
|
|
For another case we've heard that scotch 6.0.4 actually solved a dgraphFold2 error. This might just be related to a slightly different decomposition but it might be good to try this version anyway. |
|
|
mattijs, I've been unsuccessful in getting scotch 6.0.4 to compile properly. And judging by the comment in OpenFOAM-dev on commit 38415f8, it looks like OpenFOAM-dev hasn't been upgraded to 6.0.4 for the same reason. Have you been able to successfully compile OpenFOAM with scotch 6.0.4? |
|
|
You can add a –DCOMMON_PTHREAD to the CFLAGS in $WM_THIRD_PARTY_DIR/etc/wmakeFiles/scotch/Makefile.inc.i686_pc_linux2.shlib-OpenFOAM-64Int32 However this will enable thread support. scotch should compile without but there currently is a bug in 604: https://gforge.inria.fr/tracker/index.php?group_id=248&atid=1079 |
|
|
Mattijs, thanks for the additional compile flag that allowed be to build scotch 6.0.4. Unfortunately I received the same errors with scotch 6.0.4 that I did with scotch 6.0.3 for this model. |
|
|
Mattjs, I started researching strategy strings today in scotch to see if I could find a workaround to this error. It looks like OpenFOAM tries to support custom strategy strings through the 'strategy' keyword under 'scotchCoeffs' in the decomposeParDict file. However, none of the examples in $FOAM_SRC/parallel/decompose/scotchDecomp/scotchDecomp.C work when placed in the quotes after the 'strategy' keyword. Even the long default string referred to in that file produces an error. Is this functionality broken at the moment? |
|
|
The strategy string varies from version to version of scotch so it might be that the one in our header file is out of date. You can get the default strategy string by keeping the binaries of scotch (remove the 'make realclean' from the $WM_THIRD_PARTY_DIR/Allwmake) and run gmap with option -vs. I've never tweaked these settings myself but interested in feedback. Can you post your findings here? |
|
|
NEW DEVELOPMENT! I was able to reproduce the IOstream error completely separate from the scotch decomposition. I had a feeling that we might have been hitting two separate errors, so I started running meshing tests with simple decomp (varying proc counts and xyz decomps). I was able to reproduce the IOstream error using only simple decomp. These are the settings... - 24 procs, simple decomp, OpenFOAM 2.4.x, OpenMPI 1.8.7 simpleCoeffs { n (3 4 2); delta 0.001; } I've uploaded an additional model (meshing_bug_simple_24procs.tar.gz) with these preset. Can you please take a look at this new model Mattijs? This looks like it might be pointing to a bug elsewhere (possibly within OpenFOAM's mesher snappyHexMesh). |
|
|
|
|
2015-08-26 09:20
|
|
|
|
The problem is in the findCell routine in the polyMesh where some modes can trigger the building of the cell tet-decomposition and this needs to be done in parallel. Please apply the uploaded patch. (this patch is also in commit 34e062da in https://github.com/OpenFOAM/OpenFOAM-dev.git) Kind regards, Mattijs |
|
|
Mattijs, thanks for looking at this. The patch however doesn't appear to fix the problem in 2.4.x or dev. I'm currently on OpenFOAM-dev commit 32b7a26 from Aug 10th (after the June commit you referenced) and after re-running the case I still receive the same error. Can you reproduce this on your end still in OpenFOAM-dev? Which commit did you test with? I also applied your patch to build bb146c867bf2 of 2.4.x and retested. I still receive the same error in the patched 2.4.x as well. Which build did you test with where the patch worked? |
|
|
Mattijs, my apologies. The patch does appear to have worked for this model for 2.4.x build bb146c8. I got my OpenFOAM versions mixed up when I did the initial test of 2.4.x. OpenFOAM-dev still appears to have regressed though. Can you take a look there and make sure there isn't anything additional that needs to be applied to 2.4.x? Thanks GRAUPS |
|
|
The patch is for 2.4.x. I will test dev. |
|
|
Mattijs, were you able to reproduce the errors I'm seeing in dev? |
|
|
@GRAUPS: I am looking into this problem in OpenFOAM-dev and pushed a tentative fix: commit 2c46bf1554a1d5e581d5ebcaa4516359bdc6bdf0 could you test it and provide feedback? |
|
|
The issues in this thread relate to the confusion in thread: http://www.openfoam.org/mantisbt/view.php?id=1544 in which there is no clear resolution of the issue and the purpose of the proposed "fixes" also unclear. I will now work on this directly to resolve the issue. |
|
|
For the meshing_bug_simple_24procs.tar.gz case you provided I get a different error: Introducing baffles to block off problem cells ---------------------------------------------- [12] [12] [12] --> FOAM FATAL ERROR: [12] Maximum number of iterations reached. Increase maxIter. maxIter:1 nChangedCells:0 nChangedFaces:0 Does this case mesh for you in either OpenFOAM-dev or OpenFOAM-2.4.x? |
|
|
Henry, thanks for picking this up. With Mattijs' patch for 2.4.x provided in this thread I was able to mesh it previously. I will run it again in 2.4.x to confirm and get back to you ASAP. |
|
|
I get "Maximum number of iterations reached. Increase maxIter." for both of your cases for both OpenFOAM-dev and OpenFOAM-2.4.x built with gcc or clang with or without the changes to the handling of CELL_TETS. |
|
|
Henry, I can confirm that the attached model meshes successfully on my build. Here are the details of my current build... 2.4.x-8685344a0b1f with Mattijs' patch applied Built with Gcc 5.2.0 OpenMPI-1.8.7 scotch_6.0.4 (compiled with –DCOMMON_PTHREAD to avoid errors) Let me know if you need more info. |
|
|
I always get "Maximum number of iterations reached. Increase maxIter." for your cases. Could you test the latest OpenFOAM-dev? |
|
|
P.S. If it does not run with the latest OpenFOAM-dev try reverting commit 2c46bf1554a1d5e581d5ebcaa4516359bdc6bdf0 |
|
|
My current dev build is pretty dated. I will update, recompile, and retest and get back to you when I am finished. |
|
|
I've compiled and tested the latest version of dev (2c46bf1) and also compiled and tested the previous commit (95c4f93). In dev I receive the same "Maximum number of iterations reached. Increase maxIter." that you got for both the latest and previous commits. This is a new error that I haven't seen or encountered before. So now to determine why it meshes flawlessly in my 2.4.x build (with Mattijs patch) but doesn't in dev. Time to review the commits to 2.4.x since my 2.4.x-8685344a0b1f build, since you said you were getting it in 2.4.x as well. |
|
|
To be clear, I was using the meshing_bug_simple_24procs.tar.gz test case to do my testing. |
|
|
In dev I reverted the change made to globalMeshData.C in commit 511489a and then tested again. I now receive the "Iostream" error that I previously documented. I then re-applied the changes made in the latest commit (2c46bf1) and then tested, but I still receive the "Iostream" error. So the "Maximum number of iterations reached. Increase maxIter." error must have been introduced in commit 511489a in dev and efc3810 in 2.4.x. |
|
|
Resolved by commit 1da3d4aa6f9572bf43d027b54830317fd9189d1c in OpenFOAM-2.4.x Resolved by commit e64a8929a6483af1311c0b6853d912adff72532b in OpenFOAM-dev |
- Anonymous
