Skip to content
GitLab
Projects Groups Topics 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
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 22
    • Issues 22
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 17
    • Merge requests 17
  • 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

On Monday, June 12, 2023, from 9.00 to 10.00 am there will be a maintenance with a short downtime of the GitLab service.

  • ift
  • NIFTy
  • Issues
  • #67
Closed
Open
Issue created Mar 30, 2017 by Martin Reinecke@mtrOwner

Arbitrary constraints on GL geometry

In gl_space.py on current master, there are constraints on the grid layout which in my opinion make no sense.

  • in _parse_nlat, the number of rings is not allowed to be odd. Why ist this the case? I would argue that any positive number of rings is allowed and useful.
  • in _parse_nlon, a warning is given if nlon!=2*nlat-1. Depending on the actual values of lmax and mmax for the codomain, this choice is not necessarily the best one.

For GL grids, the connections between nlat, nlon, mmax and lmax should be the following:

  • nlat = lmax+1 (this is always a good choice, and a warning could safely be given if the user specifies something different)
  • nlon >= 2*mmax+1 (this is the minimum number of pixels per ring that can represent spherical harmonics up to and including mmax. However, it may be preferrable to choose a slightly higher nlon for performance reasons: if possible, nlon should be a product of prime factors <=5).

I am aware that the constructor for GLSpace currently does not have the desired lmax and mmax values at hand, and so cannot warn if the relations above do not hold. However, the current tests should be changed, since they are arbitrary and their restrictions do not improve the code in any way.

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