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