- 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)
- this builds on Mattijs' commit 968f0bbd57 but with a first()
as well.
- Added both to FixedList, IndirectList, UIndirectList and *PtrList and
since they can certainly be useful there. Did not add to BiIndirectList,
since I'm not sure what it should mean there. Did not add to PackedList,
since it's not clear how useful they'd be yet in these contexts (and I'm
not sure how it would interact with the iterator proxy implementation).
- Note: STL defines front() and back() for these methods.
