- now that I re-examined the code, the note in commit 51fd6327a6
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.
- 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.
- 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).
- 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)
