Feature/spherical sph #55
Conversation
interpolation from the Boost library.
than our home rolled interpolator. Not good enough.
simple-minded parabolic interpolator, so starting to switch back to that. In progress.
TableKernels again. The boost ones are nice, but this is 2x-3x faster.
parabola, it should always be good to roundoff.
interpolation coefficients.
BiQuadraticInterpoolator (not done).
interpolator, since there should be no cubic terms. Also extended testing. This reverts commit 9b71e9d.
flag to see what's going on.
realize had been left out of these classes), so fixed that.
than a Vector2d as arguments.
|
This merge brings up infrastructure developed to support the spherical (and eventually cylindrical) symmetry kernel formalism. The spherical kernel is pretty much working now, but the corresponding spherical SPH is not yet. I'm bringing this branch up to develop now because the infrastructure developed here (particularly the quadratic and bi-quadratic interpolators) are more generally useful (and needed for other work such as improving our ANEOS implementation. This merge also brings updates to 3 third party libs (boost, Py11Generator, and some PIP modules). I've confirmed these are all working building stand alone, as well as updated the pre-installed TPLs for the GCC versions on LC machines. |
jmikeowen
requested review from
mdavis36,
MishaZakharchanka,
ptsuji and
brbass
| double kernelValue(double etaMagnitude, double Hdet) const; | ||
| double gradValue(double etaMagnitude, double Hdet) const; | ||
| double grad2Value(double etaMagnitude, double Hdet) const; | ||
| double kernelValue(double etaMagnitude, const double Hdet) const; |
There was a problem hiding this comment.
Is there some reason why Hdet is const and not etaMagnitude? Is etaMagnitude changed in some of the routines?
There was a problem hiding this comment.
Offhand I think no particular reason. We could make the etaMagnitude constant as well. Is that a change you'd like to see?
There was a problem hiding this comment.
It doesn't matter that it happens now, but it would be nice to keep things consistent between TableKernel, SphericalTableKernel, and Kernel.
| //------------------------------------------------------------------------------ | ||
| // GeometryRegistrar | ||
| // | ||
| // A singleton class for maintaining global information about the type of |
There was a problem hiding this comment.
Might be worth considering certain things on Geometry rather than Dimension later on. That might cut down on duplicate code between Cartesian/Cylindrical/Spherical geometry as you could specialize things like kernel normalization, integration, etc. while keeping a lot of the machinery the same between them.
No description provided.