1. 03 Dec, 2009 6 commits
    • Mark Olesen's avatar
      PackedBoolList specializaton for operator= · 063d8ede
      Mark Olesen authored
      - now that I re-examined the code, the note in commit 51fd6327
        can be mostly ignored
      
        PackedList isMaster(nPoints, 1u);
        is not really inefficient at all, since the '1u' is packed into
        32/64-bits before the subsequent assignment and doesn't involve
        shifts/masking for each index
      
        The same misinformation applies to the PackedList(size, 0u) form.
        It isn't much slower at all.
      
        Nonetheless, add bool specialization so that it is a simple assign.
      063d8ede
    • Mark Olesen's avatar
      58740164
    • Mark Olesen's avatar
      commit existing sizeof test · 67b79d92
      Mark Olesen authored
      67b79d92
    • Mark Olesen's avatar
      pedantic changes: 'forAll (' -> 'forAll(' in applications/ · c091d856
      Mark Olesen authored
      - to match coding guidelines
      c091d856
    • Mark Olesen's avatar
      Use argList::addOption, argList::addBoolOption (almost) everywhere · 58b7e641
      Mark Olesen authored
      - ensure that the standard options (eg, from timeSelector) also have
        some usage information
      58b7e641
    • Mark Olesen's avatar
      argList fixes/enhancements · ca7acea5
      Mark Olesen authored
      - bugfix: noParallel() didn't remove 'parallel' from validParOptions
        allowing it to sneak through to the Pstream layer.
        noParallel() now clears the entire validParOptions as well
      
      - new convenience methods
        * addOption()
        * removeOption()
        * addBoolOption() - as per addOption(), but for bool options (no param)
      
      - printUsage() output format
        * options sorted alphabetically
        * options listed on separate lines for better readability
      
      - new optionUsage static member for short usage information about
        an option
        * corresponding addUsage() method or provide usage information
          in addOption() / addBoolOption()
      ca7acea5
  2. 02 Dec, 2009 7 commits
  3. 01 Dec, 2009 22 commits
  4. 30 Nov, 2009 4 commits
  5. 29 Nov, 2009 1 commit
    • Mark Olesen's avatar
      Added Catmull-Rom splines to blockMesh. · 5648be03
      Mark Olesen authored
      - the blockMesh interface is splineEdge.H, selectable as "spline"
      
      The first tests look fine - it works as expected for the case with
      buggy polySpline reported on the forum. Should of course do some more
      extensive testing.
      
      The advantages compared to the current B-Spline implementation:
      
      - Doesn't need a matrix solver.
      - The coding resembles something that can be found in the literature.
      - In contrast to the B-Spline implementation, it is fairly clear what
        is actually going on. I don't even know if the B-Spline are actually
        B-Spline, Beta-Splines or something else.
      - Catmull-Rom splines seem to be what all the graphics people have as
        their stable workhorse.
      
      We now have 3 different names for splines in blockMesh:
      - "spline" - *new* Catmull-Rom for arbitrary segments.
      - "simpleSpline" - B-Spline for a single segment
      - "polySpline" - B-Spline for a multiple segments
      
      Assuming the Catmull-Rom splines continue to behave nicely, there is
      no reason to keep the other (broken) B-Splines. This would help clean
      up the blockMesh interface too.
      
      Placed the older ones under legacy/ for easier identification in the
      future.
      
      TODO:
      - currently no handling of non-zero end tangents
      - could be extended to handle closed loops, which might be useful
        for feature edges from CAD (eg, for the cvm mesher)
      5648be03