- 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.

- ensure that the standard options (eg, from timeSelector) also have
  some usage information

- 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()

Note:

PackedList constructor initializes to zero, faster not to do it
ourselves.
ie,
    PackedList foo(nPoints);
vs.
    PackedList foo(nPoints, 0);

saves an extra nPoints operations with shifts/masks etc.

If speed is important, change this type of code

    PackedList isMaster(nPoints, 1u);
    for (loop)
    {
        if (condition)
        {
            isMaster.set(i, 0u);   // unset bit
        }
    }
    return isMaster;

into this:

    PackedList notMaster(nPoints);
    for (loop)
    {
        if (!condition)
        {
            notMaster.set(i, 1u);
        }
    }
    notMaster.flip();
    return notMaster;

or this:

    PackedList isMaster(nPoints);
    isMaster.flip();

    for (loop)
    {
        if (condition)
        {
            isMaster.set(i, 0u);
        }
    }
    return isMaster;

- exception calcType.H since it'll most likely be used for building
  applications anyhow

- use quailified names in more of the lagrangian code

- killed some tab indents in various places.

- was not touched for a very long time, seems to be left over from
  the pre-git era

- new optionLookupOrDefault and additional form of optionReadIfPresent
  with a default value

- this probably should have been in commit c7c9a6e0 (2009-11-04)
  but got overseen in the HashTbl -> HashTable switch

- allow insert() and set() from a UList of Key
  This complements the existing erase(const UList<Key>&) method

- adjust code to more closely resemble sampledSets / sampledSurfaces

- adjust code to more closely resemble sampledSurfaces

- this allows something like this:
      fields( T U "Ua.*" );
  to select normal fields and all the adjoint velocity fields

Mark Olesen authored 15 years ago and Andrew Heather committed 15 years ago

- forgot to use readList in removeEntry, which caused the test failure.

- remaining problem:

it doesn't work as might be expected
This is the problem:

dict
{
   foo xxx;
   bar yyy;
}

dict
{
   baz zzz;
   #remove foo
}

This only removes 'foo' from the current scope (the second dict), since
it occurs before the dictionary merge does.

To remove from the final, merged dictionary, we'd need a new
deleteEntry type that would do the right thing on the merge before
self-destructing (ie, removing itself too).

- forgot to use readList in removeEntry, which caused the test failure.

- remaining problem:

it doesn't work as might be expected
This is the problem:

dict
{
   foo xxx;
   bar yyy;
}

dict
{
   baz zzz;
   #remove foo
}

This only removes 'foo' from the current scope (the second dict), since
it occurs before the dictionary merge does.

To remove from the final, merged dictionary, we'd need a new
deleteEntry type that would do the right thing on the merge before
self-destructing (ie, removing itself too).

- reduce duplicate code by using some HashTable methods directly

- could also be the default

- reduce duplicate code by using some HashTable methods directly

- useful when using alternative dictionary names/locations

- missing in 1.6.x as well

- space between keyword and bracket in 'for(..)', 'if(..)', 'while(..)'

- 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)

- markup codingStyleGuide.org examples so they actually indent correctly

- use 'Info<<' as per codingStyleGuide instead of 'Info <<'

- use first() method in some places as well where it helps clarity

- there are a few remaining cases: git grep 'size()-1]'