Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in
  • I IPPL
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 39
    • Issues 39
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 12
    • Merge requests 12
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • OPAL
  • Libraries
  • IPPL
  • Issues
  • #80

Closed
Open
Created Mar 31, 2021 by vinciguerra_a@vinciguerra_aDeveloper

Implement deep copy for fields

Currently, if a and b are ippl::Fields, the assignment a = b does not invoke operator=(ippl::detail::Expression) but instead simply performs a shallow copy. This means that the Kokkos views in a and b will address the same memory space and changes to one field will affect the other. To copy the contents from one field to another, one can

  • use an explicit loop; or
  • force a detour through an expression, such as by writing a = b * 1.

The field type should provide a deep copy function to simplify this.

Possible signatures:

  • void ippl::Field::copy(Field&, Field&) copy the contents of one field into another
  • ippl::Field ippl::Field::copy() return a newly constructed field with the same properties and contents
  • ippl::Field& operator=(const Field&) redefine the assignment operator

The second option seems best as it's explicit, fits well with object oriented code (as opposed to the first one), and doesn't break any copy constructions (such as for functions that take non-reference arguments, even though there don't appear to be any such functions in IPPL).

Assignee
Assign to
Time tracking