Skip to content
GitLab
  • Menu
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 53
    • Issues 53
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 21
    • Merge requests 21
  • 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
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