View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001450 | OpenFOAM | Bug | public | 2014-12-02 07:07 | 2015-02-25 20:53 |
Reporter | Assigned To | henry | |||
Priority | high | Severity | crash | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Platform | Linux | OS | OpenSuse | OS Version | 11.2 |
Summary | 0001450: decomposePar with scotch breaks for cyclicACMI patch in the tutorial of oscillatingInletACMI2D. | ||||
Description | I decomposed the tutorial mesh of oscillatingInletACMI2D by scotch, but segmentation fault errors are shown as follows, /*---------------------------------------------------------------------------*\ | ========= | | | \\ / F ield | OpenFOAM: The Open Source CFD Toolbox | | \\ / O peration | Version: 2.3.x | | \\ / A nd | Web: www.OpenFOAM.org | | \\/ M anipulation | | \*---------------------------------------------------------------------------*/ Build : 2.3.x-590d57f32fed Exec : decomposePar Date : Dec 02 2014 Time : 16:00:21 Host : "svxxxxx" PID : 25373 Case : /work3/uxxxxx/OpenFOAM/uxxxxx-2.3.x/tutorials/oscillatingInletACMI2D nProcs : 1 sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE). fileModificationChecking : Monitoring run-time modified files using timeStampMaster allowSystemOperations : Allowing user-supplied system call operations // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // Create time Decomposing mesh region0 Create mesh AMI: Creating addressing and weights between 40 source faces and 96 target faces AMI: Patch source sum(weights) min/max/average = 1, 1, 1 AMI: Patch target sum(weights) min/max/average = 0, 1, 0.4 Calculating distribution of cells Selecting decompositionMethod scotch Finished decomposition in 0.03 s Calculating original mesh data Distributing cells to processors Distributing faces to processors Distributing points to processors Constructing processor meshes #0 Foam::error::printStack(Foam::Ostream&) in "/home/u15002/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64Gcc48DPOpt/lib/libOpenFOAM.so" #1 Foam::sigSegv::sigHandler(int) in "/home/u15002/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64Gcc48DPOpt/lib/libOpenFOAM.so" #2 ?? in "/lib64/libc.so.6" #3 Foam::cyclicACMIPolyPatch::setNeighbourFaceAreas() const in "/home/u15002/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64Gcc48DPOpt/lib/libmeshTools.so" #4 Foam::cyclicACMIPolyPatch::resetAMI(Foam::AMIInterpolation<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::interpolationMethod const&) const in "/home/u15002/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64Gcc48DPOpt/lib/libmeshTools.so" #5 Foam::cyclicACMIPolyPatch::initGeometry(Foam::PstreamBuffers&) in "/home/u15002/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64Gcc48DPOpt/lib/libmeshTools.so" #6 Foam::polyBoundaryMesh::calcGeometry() in "/home/u15002/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64Gcc48DPOpt/lib/libOpenFOAM.so" #7 Foam::polyMesh::addPatches(Foam::List<Foam::polyPatch*> const&, bool) in "/home/u15002/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64Gcc48DPOpt/lib/libOpenFOAM.so" #8 Foam::domainDecomposition::writeDecomposition(bool) in "/home/u15002/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64Gcc48DPOpt/bin/decomposePar" #9 main in "/home/u15002/OpenFOAM/OpenFOAM-2.3.x/platforms/linux64Gcc48DPOpt/bin/decomposePar" #10 __libc_start_main in "/lib64/libc.so.6" #11 _start at /usr/src/packages/BUILD/glibc-2.10.1/csu/../sysdeps/x86_64/elf/start.S:116 Segmentation fault | ||||
Steps To Reproduce | # cp -r /home/u15002/OpenFOAM/OpenFOAM-2.3.x/tutorials/incompressible/pimpleDyMFoam/oscillatingInletACMI2D/ ./ # cd oscillatingInletACMI2D/ # ./Allrun Running blockMesh on oscillatingInletACMI2D Running topoSet on oscillatingInletACMI2D Running createBaffles on oscillatingInletACMI2D Running createPatch on oscillatingInletACMI2D Running pimpleDyMFoam on oscillatingInletACMI2D ^C # decomposePar | ||||
Additional Information | The number of decomposition with scotch is 4. | ||||
Tags | ACMI, cyclicACMI, decomposePar | ||||
|
Any update on this issue? I have exactly the same problem on OpenSUSE 13.2, with the latest git pull of OpenFOAM. |
|
Since I had a considerable good look into this, I think it's best to share what I managed to understand. First of all, a workaround has been reported here: http://www.cfd-online.com/Forums/openfoam-installation/146513-of2-3-1-os13-2-trying-use-dummy-pstream-library.html#post528475 post #19, where temporarily commenting out the method "resetAMI()" in the method "Foam::cyclicACMIPolyPatch::initGeometry" can help bypass the problem for decomposePar. Attached is the patch "hack_for_bug1450.patch" for somewhat better circumventing this issue, until an improved implementation for ACMI is done. The patch essentially changes in "resetAMI" to only call "setNeighbourFaceAreas()" if there are target faces; if not, it issues a warning message indicating that such a situation should only occur when decomposing a case. As for the bigger problem, here's what I could figure out: 1- In decomposePar, treating "cyclicAMIPolyPatch" the same way that "cyclicPolyPatch" is treated, seemed a good idea. It's probably not, taking into account that cyclic patches need strict correlation between the cells that each face corresponds to. 2- When assuming that "cyclicAMIPolyPatch" should be treated the same way as "cyclicPolyPatch", I triggered the next issue: each cyclicACMI patch relies on two other patches (instead of one), namely the sibling patch and the patch that will be used for covering the unexposed part. 3- This leads to the problem where we're not able to strictly correlate these 3-4 patches of the same groups to be part of the same processor, simply because the "blockage" patches are standard wall patches, with no coupling identification, apart from the grouping. 4- This leads me to believe that a new derived patch class would be needed, derived from a wall patch, such as "wallACMI" or something like that, with at least the special "coupled==true" indication and neighbour correlation data. This way we could then at least use the "preservePatches" feature. For now, I guess there isn't much more I can to try and help here, aside from the attached patch file. |
|
hack_for_bug1450.patch (956 bytes)
diff --git a/src/meshTools/AMIInterpolation/patches/cyclicACMI/cyclicACMIPolyPatch/cyclicACMIPolyPatch.C b/src/meshTools/AMIInterpolation/patches/cyclicACMI/cyclicACMIPolyPatch/cyclicACMIPolyPatch.C index 46a9468..41ef8de 100644 --- a/src/meshTools/AMIInterpolation/patches/cyclicACMI/cyclicACMIPolyPatch/cyclicACMIPolyPatch.C +++ b/src/meshTools/AMIInterpolation/patches/cyclicACMI/cyclicACMIPolyPatch/cyclicACMIPolyPatch.C @@ -98,7 +98,16 @@ void Foam::cyclicACMIPolyPatch::resetAMI noSf[faceI] *= 1.0 - srcMask_[faceI]; } - setNeighbourFaceAreas(); + if(tgtMask_.size()>0) + { + setNeighbourFaceAreas(); + } + else + { + WarningIn("cyclicAMIPolyPatch::resetAMI(...) const") + << "Target mask is not populated." + << " Should only occur when decomposing." << endl; + } // set the updated flag updated_ = true; |
|
I agree than the cyclicACMIPolyPatch has some SERIOUS issues and will probably need a rewrite but then the cyclicAMIPolyPatch also has SERIOUS issues which need to be addressed first. In the meantime I am OK with the hack you propose except that is it reasonable to assume that tgtMask_ might be empty indicating that decomposition is taking place? Might tgtMask_ have some elements but a different number to cp.size()? |
|
Hacked by commit ea9cfb1213c302d48dd9c55597895e9be9a7fb8b |
Date Modified | Username | Field | Change |
---|---|---|---|
2014-12-02 07:07 |
|
New Issue | |
2014-12-02 08:53 |
|
Tag Attached: cyclicACMI | |
2014-12-02 08:53 |
|
Tag Attached: decomposePar | |
2014-12-29 18:42 | wyldckat | Tag Attached: ACMI | |
2015-01-19 18:02 |
|
Note Added: 0003566 | |
2015-02-14 21:04 | wyldckat | Note Added: 0003770 | |
2015-02-14 21:06 | wyldckat | File Added: hack_for_bug1450.patch | |
2015-02-25 20:08 | henry | Note Added: 0003913 | |
2015-02-25 20:53 | henry | Note Added: 0003914 | |
2015-02-25 20:53 | henry | Status | new => resolved |
2015-02-25 20:53 | henry | Resolution | open => fixed |
2015-02-25 20:53 | henry | Assigned To | => henry |