#230 Symmetry is not the same as symmetryPlane for some compiler versions

confirmed
nobody
None
normal
minor
havenottried
none
Linux
Centos 6.5
Intel
foam-extend-3.1
foam-extend-3.1
other
2014-06-05
2014-06-04
No

The cylinder tutorial-case for potentialFoam fails on some machines (see CDash-Link)

Problem seems to be that boundary/blockMeshDict specify symmetry while 0/p specifies symmetryPlane. Setting symmetryPlane in the blockMeshDict fixes this.

The strange thing is that for the identical sources other machines run this test OK (http://openfoam-extend.sourceforge.net/CDash/testDetails.php?test=14429&build=666).

Most notable difference is that the failing machines has gcc 4.4 while the others have 4.7, 4.8

Usually I'd suggest changing the tutorial and forgetting about it but is it possible that this might be part of a subtle problem that older compilers have with runtime-selection?

Discussion

  • Henrik Rusche

    Henrik Rusche - 2014-06-04

    The real question is: Why isn't "symmetry" not flagged as an error?

     
  • Henrik Rusche

    Henrik Rusche - 2014-06-04

    The answer is in $FOAM_SRC/meshes/polyMesh/polyPatches/polyPatch/newPolyPatch.C

    ŒŒŒ if (cstrIter == dictionaryConstructorTablePtr_->end())
    ŒŒŒ {
    ŒŒŒŒŒŒŒ if (!disallowGenericPolyPatch)
    ŒŒŒŒŒŒŒ {
    ŒŒŒŒŒŒŒŒŒŒŒ cstrIter = dictionaryConstructorTablePtr_->find("genericPatch");
    ŒŒŒŒŒŒŒ }

    So it is converted into a genericPatch (I checked). It's still strange that the problem is platform dependant.

    For the moment, I think we should change to symmetryPlane and leave this bug open.

     
  • Bernhard Gschaider

    I don't understand the question. Or do you mean "Why is 'symmetry' not flagged as an error in the other builds?"? I'd say that it is somewhere added as an alias to "symmetryPlane" and that trick does not work with good old gcc 4.4

     
  • Henrik Rusche

    Henrik Rusche - 2014-06-04

    symmetry -> symmetryPlane in all blockMeshDicts (3332488e)

    Can disallowGenericPolyPatch enabled safely?

     
  • Bernhard Gschaider

    I'd think so. but of course one would have to know every bit of code by heart to be sure. And I think changing and running it through the test loop is not sufficient proof that it breaks nothing.

    What I'd suggest is: after the release enable it in the development-version and see whether anyone even notices

     
  • Henrik Rusche

    Henrik Rusche - 2014-06-05

    The disallowGenericFvPatchField is there for pre- and postprocessing where are boundary will not be able evaluate itself.

    I don't see why disallowGenericPolyPatch is not set.

    Anyway, needs to go through Hrv AND a trial period as suggested by you.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks