Namespace for spinweighted 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 spinweighted 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 spinweighted spherical harmonic utilities.

strong 
A set of labels for the possible representations of complex numbers for the ComplexDataView
and the computations performed in the spinweighted 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 hardwaredependent). 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 compiletime structure which acts as a threadsafe lookup table for all l_max values that have been requested so far during execution, so that the libsharp generation need not be rerun. 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.