1. 26 Oct, 2015 1 commit
    • mattijs's avatar
      BUG: snappyHexMesh: minThickness > 1 caused truncation of layers · 2de68a9a
      mattijs authored
      The start of the layer addition loop does a synchronisation of the wanted
      displacement. This also does a truncation of the displacement if it is <
      minThickness. At the first iteration the displacement was initialised to
      vector::one which might trigger the truncation logic (and then disable
      extrusion altogether). Instead we now initialise the displacement to
      vector::GREAT before entering the synchronisation.
      2de68a9a
  2. 14 Oct, 2015 1 commit
    • mattijs's avatar
      ENH: snappyHexMesh: various improvements. See below or the default snappyHexMeshDict. · 4d1159e6
      mattijs authored
      Refinement:
      -----------
      // Optionally avoid patch merging - keeps hexahedral cells
      // (to be used with automatic refinement/unrefinement)
      //mergePatchFaces off;
      
      // Optional multiple locationsInMesh with corresponding optional cellZone
      // (automatically generates faceZones inbetween)
      locationsInMesh
      (
          ((-0.09 -0.039 -0.049)  bottomAir)  // cellZone bottomAir
          ((-0.09 0.009 -0.049)   topAir)     // cellZone topAir
      );
      
      // Optional faceType and patchType specification for these faceZones
      faceZoneControls
      {
          bottomAir_to_topAir
          {
              faceType baffle;
          }
      }
      
      / Optional checking of 'bleeding' of mesh through a specifying a locations
      // outside the mesh
      locationsOutsideMesh ((0 0 0)(12.3 101.17 3.98));
      
      // Improved refinement: refine all cells with all (or all but one) sides refined
      
      // Improved refinement: refine all cells with opposing faces with different
      // refinement level. These cells can happen on multiply curved surfaces.
      // Default on, can be switched off with
      //interfaceRefine false;
      
      Snapping
      --------
      // Optional smoothing of points at refinement interfaces. This will reduce
      // the non-orthogonality at refinement interfaces.
      //nSmoothInternal $nSmoothPatch;
      
      Layering
      --------
      
      // Layers can be added to patches or to any side of a faceZone.
      // (Any faceZone internally gets represented as two patches)
      
      // The angle to merge patch faces can be set independently of the
      // featureAngle. This is especially useful for large feature angles
      // Default is the same as the featureAngle.
      //mergePatchFacesAngle 45;
      
      // Optional mesh shrinking type 'displacementMotionSolver'. It uses any
      // displacementMotionSolver, e.g. displacementSBRStress
      // (default is the medial-axis algorithm, 'displacementMedialAxis')
      //meshShrinker displacementMotionSolver;
      4d1159e6
  3. 04 Aug, 2015 1 commit
  4. 02 Aug, 2015 1 commit
  5. 12 Jul, 2015 1 commit
    • Henry Weller's avatar
      blockMesh: added experimental fast-merge algorithm · 171c25ab
      Henry Weller authored
      The standard merge-algorithm is N^2 over the face-points and uses a
      geometric proximity test for the merge.  These are both choices for
      implementation simplicity and are rather inefficient for large meshes.
      I have now implemented an experimental linear topological merge
      algorithm which is VERY fast and effective for meshes of any size.
      Currently it will merge internal faces on meshes of arbitrary complexity
      but does not yet handle edge or face collapse needed for wedges and
      other degenerate blocks.
      
      The new fast-merge algorithm may be selected using the optional
      "fastMerge" entry:
      
      fastMerge yes;
      
      and if not present the standard N^2 algorithm will be used.
      
      Henry G. Weller
      CFD Direct
      171c25ab
  6. 05 Jul, 2015 1 commit
  7. 18 May, 2015 1 commit
  8. 04 May, 2015 2 commits
  9. 05 Mar, 2015 1 commit
  10. 14 Feb, 2015 1 commit
  11. 05 Feb, 2015 1 commit
  12. 03 Feb, 2015 2 commits
    • Henry's avatar
      Update headers · 92f9825a
      Henry authored
      92f9825a
    • Henry's avatar
      blockMesh: Add support for multi/sectional grading in a block · 7ec17dfd
      Henry authored
      Consider a block describing a channel with two opposite walls.
      Currently in order to grade the mesh towards the walls and have a
      uniform region in the centre the channel would need to be spit into 3
      blocks.  With the new multi/sectional grading this can be achieved in a
      single block e.g.
      
      blocks
      (
          hex (0 1 2 3 4 5 6 7) (20 60 20)
          simpleGrading
          (
              1
              ((0.2 0.3 4) (0.6 0.4 1) (0.2 0.3 0.25))
              1
          )
      );
      
      In this example the block is divided uniformly in the x and z -directions
      and split into three grading sections in the y-direction described by
      three triples:  ((0.2 0.3 4) (0.6 0.4 1) (0.2 0.3 0.25)).  Each of the
      grading sections is described by a triple consisting of the fraction of
      the block, the fraction of the divisions and the grading ratio (size of
      first division/size of last division).  Both the fraction of the block
      and the fraction of the divisions are normalized automatically so they
      can be specified scaled in anyway, e.g. as percentages:
      
      blocks
      (
          hex (0 1 2 3 4 5 6 7) (20 60 20)
          simpleGrading
          (
              1
              ((2 3 4) (6 4 1) (2 3 0.25))
              1
          )
      );
      
      and they need not sum to 1 or 100.
      
      This is very new functionality and not well tested but backward
      compatibility has been well tested so all existing blockMeshDicts should
      parse correctly.
      7ec17dfd
  13. 31 Dec, 2014 1 commit
    • Henry's avatar
      Added and verified support for 64bit labels · 325b003b
      Henry authored
      To compile with 64bit labels set
      
      WM_LABEL_SIZE=64
      
      in ~/OpenFOAM/dev/prefs.sh
      
      source ~/.bashrc
      
      then Allwmake in OpenFOAM-dev.
      
      This will build into for example OpenFOAM-dev/platforms/linux64ClangDPInt64Opt
      
      If WM_LABEL_SIZE is unset or set to 32:
      
      WM_LABEL_SIZE=32
      
      the build would be placed into OpenFOAM-dev/platforms/linux64ClangDPInt32Opt
      
      Thus both 32bit and 64bit label builds can coexist without problem.
      325b003b
  14. 14 Dec, 2014 1 commit
  15. 11 Dec, 2014 1 commit
  16. 07 Nov, 2014 1 commit
  17. 24 Sep, 2014 1 commit
  18. 03 Sep, 2014 1 commit
  19. 21 Aug, 2014 1 commit
  20. 23 Jul, 2014 1 commit
  21. 09 Jul, 2014 1 commit
  22. 06 Jun, 2014 1 commit
  23. 22 May, 2014 1 commit
  24. 07 May, 2014 1 commit
  25. 22 Apr, 2014 2 commits
  26. 19 Feb, 2014 1 commit
  27. 18 Feb, 2014 1 commit
  28. 11 Feb, 2014 1 commit
  29. 03 Feb, 2014 1 commit
  30. 24 Jan, 2014 1 commit
  31. 23 Jan, 2014 1 commit
  32. 22 Jan, 2014 1 commit
  33. 21 Jan, 2014 1 commit
  34. 20 Jan, 2014 1 commit
  35. 15 Jan, 2014 1 commit
  36. 14 Jan, 2014 1 commit
  37. 10 Jan, 2014 1 commit