Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • N NIFTy
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 16
    • Issues 16
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 14
    • Merge requests 14
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • ift
  • NIFTy
  • Issues
  • #155
Closed
Open
Issue created Jun 27, 2017 by Martin Reinecke@mtrOwner

New storage format for harmonic RGSpaces?

I'm wondering whether we can apply the hermitian/anti-hermitian separation trick that we employ for spherical harmonic coefficients in the LMSpace to harmonic RGSpaces as well.

The symmetries are nearly the same: on the sphere we have

a_l,m = (-1)**m *conj(a_l,-m)

in a (multidimensional) RGSpace it is

f_k = conj(f_-k)

So in principle we could store the Fourier coefficients of a real-valued field in another real-valued field with exactly the same dimensions.

A 1D example:

Instead of storing the complex values

[ f0 f1 f2 f(-2) f(-1) ]

we would simply store

[ f0.re x*f1.re x*f1.im x*f2.re x*f2.im ], where x=sqrt(2.)

The coefficients at negative frequencies can be recovered trivially, and f0.im is 0 by symmetry. In analogy to the spherical case, sqrt(2.) is needed to conserve the dot products.

For arrays of even length:

[ f0 f1 f(-2) f(-1) ]

becomes

[ f0.re x*f1.re x*f1.im x*f2.re ]

(f2.im is zero in this case)

In multi-D, this treatment has to be applied to exactly one dimension; in analogy with FFTW, I suggest to use the last one.

Adopting such a scheme would have several significant advantages:

  • memory requirements go down
  • FFTs of real data will be faster
  • the input data type of an FFToperator can always be the same as the output data type
  • the transform of a real field will by construction always be exactly hermitian, and operators cannot destroy the hermitianity by accident
  • minimizers won't be able to explore degrees of freedom that do not really exist in a given problem

Of course there will be drawbacks as well:

  • whenever Fourier coefficients in the traditional format are required, conversions need to be run, which are quick but not absolutely free. (I don't think that this will be needed often.)
  • the get_distance_array method of RGSpace will have to be adjusted.
  • probably more stuff I'm missing at the moment.

I know that this is a crazy-looking idea, but especially in the light of the numerical problems we are currently encountering with the reconstruction of radio data, I think it should be investigated.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking