Namespace for spin-weighted spherical harmonic utilities. More...
Classes | |
class | Collocation |
A wrapper class for the spherical harmonic library collocation data. More... | |
struct | LibsharpCollocationPoint |
A container for reporting a single collocation point for libsharp compatible data structures. More... | |
Enumerations | |
enum | ComplexRepresentation { Interleaved, RealsThenImags } |
A set of labels for the possible representations of complex numbers for the ComplexDataView and the computations performed in the spin-weighted spherical harmonic transform library. More... | |
Functions | |
template<ComplexRepresentation Representation> | |
const Collocation< Representation > & | precomputed_spherical_harmonic_collocation (size_t l_max) noexcept |
precomputation function for those collocation grids that are requested More... | |
Variables | |
constexpr size_t | collocation_maximum_l_max = 200 |
Namespace for spin-weighted spherical harmonic utilities.
|
strong |
A set of labels for the possible representations of complex numbers for the ComplexDataView
and the computations performed in the spin-weighted spherical harmonic transform library.
The representation describes one of two behaviors:
Interleaved
: The vectors of complex numbers will be represented by alternating doubles in memory. This causes both the real and imaginary part at a given gridpoint to be near one another, but successive real values farther. This is the native representation of complex data in the C++ standard, and is the representation needed for Blaze math operations. Therefore, using this representation type in libsharp computations will cause operations which access only the real or imaginary parts individually to trace over larger memory regions. However, this representation will give rise to fewer copying operations to perform the libsharp operations.RealsThenImags
: The vectors of complex numbers will primarily be represented by a pair of vectors of doubles, one for the real values and one for the imaginary values (the full computation cannot be performed exclusively in this representation, as it must return to a vector of std::complex<double>
for Blaze math operations). This causes the successive real values for different gridpoints to be closer in memory, but the real and imaginary parts for a given gridpoint to be farther in memory. This is not the native representation for complex data in C++, so the data must be transformed between operations which use Blaze and the transform operations which use RealsThenImags
. Therefore, using this representation in libsharp computations will cause operations which act on real or imaginary parts individually to have better memory locality (so likely improved cache performance, but such statements are highly hardware-dependent). However, this representation will give rise to more copying operations to perform the libsharp operations.
|
noexcept |
precomputation function for those collocation grids that are requested
keeps a compile-time structure which acts as a thread-safe lookup table for all l_max values that have been requested so far during execution, so that the libsharp generation need not be re-run. If it has been generated, it's returned by reference. Otherwise, the new grid is generated and put in the lookup table before it is returned by reference.