Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • SWIFTsim SWIFTsim
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 56
    • Issues 56
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 18
    • Merge requests 18
  • Deployments
    • Deployments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • SWIFT
  • SWIFTsimSWIFTsim
  • Issues
  • #123
Closed
Open
Issue created Mar 13, 2016 by Pedro Gonnet@nnrw56Developer

Fix gpart id/pointer

Making a union of the gpart ID and the part pointer seemed like a good idea at first, but it's just an accident waiting to happen, as the pointers are not guaranteed to be less than 2^63. I therefore suggest the following:

  • Store the gpart ID as a ptrdiff_t.
  • If the gpart ID is positive, it's just the particle's ID.
  • If the gpart ID is negative, then it is the negative offset in the space->parts[] array of its part counterpart.

This storage format has the additional advantage that it makes it easier to re-link the particles if we ever do have to send them around between nodes, e.g. by making the offsets relative to whatever array the data is stored/sent in.

This is currently just a proposal. Please let me know what you think and if there is no opposition I will change this as soon as the initial gpart branch has been merged (!116 (merged)).

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