Skip to content

Comments

Implement vector copy operation#183

Open
julianlitz wants to merge 5 commits intomainfrom
litz_copy
Open

Implement vector copy operation#183
julianlitz wants to merge 5 commits intomainfrom
litz_copy

Conversation

@julianlitz
Copy link
Collaborator

Merge Request - GuideLine Checklist

Guideline to check code before resolve WIP and approval, respectively.
As many checkboxes as possible should be ticked.

Checks by code author:

Always to be checked:

  • There is at least one issue associated with the pull request.
  • New code adheres with the coding guidelines
  • No large data files have been added to the repository. Maximum size for files should be of the order of KB not MB. In particular avoid adding of pdf, word, or other files that cannot be change-tracked correctly by git.

If functions were changed or functionality was added:

  • Tests for new functionality has been added
  • A local test was succesful

If new functionality was added:

  • There is appropriate documentation of your work. (use doxygen style comments)

If new third party software is used:

  • Did you pay attention to its license? Please remember to add it to the wiki after successful merging.

If new mathematical methods or epidemiological terms are used:

  • Are new methods referenced? Did you provide further documentation?

Checks by code reviewer(s):

  • Is the code clean of development artifacts e.g., unnecessary comments, prints, ...
  • The ticket goals for each associated issue are reached or problems are clearly addressed (i.e., a new issue was introduced).
  • There are appropriate unit tests and they pass.
  • The git history is clean and linearized for the merge request. All reviewers should squash commits and write a simple and meaningful commit message.
  • Coverage report for new code is acceptable.
  • No large data files have been added to the repository. Maximum size for files should be of the order of KB not MB. In particular avoid adding of pdf, word, or other files that cannot be change-tracked correctly by git.

@codecov
Copy link

codecov bot commented Feb 18, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.18%. Comparing base (39ce1dd) to head (f95ddec).

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #183   +/-   ##
=======================================
  Coverage   95.18%   95.18%           
=======================================
  Files          94       94           
  Lines        9345     9348    +3     
=======================================
+ Hits         8895     8898    +3     
  Misses        450      450           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Copy link
Collaborator

@EmilyBourne EmilyBourne left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this PR makes sense. The if/throw is found inside Kokkos::deep_copy in the form of a KOKKOS_ASSERT and the added parallelism can be obtained from Kokkos using Kokkos::parallel_deep_copy instead of Kokkos::deep_copy

This would not have the if condition in the OpenMP pragma but it is the function that we will use anyway when we move to GPU.

@julianlitz
Copy link
Collaborator Author

I think it makes sense to move the implementation details into a separate function (here copy_vector) instead of calling the Kokkos:: manually.

@EmilyBourne
Copy link
Collaborator

I think it makes sense to move the implementation details into a separate function (here copy_vector) instead of calling the Kokkos:: manually.

I would agree if there were any implementation details 😅 here you are basically just changing the name of the function call. Burying the Kokkos call gives you less control (e.g. you can no longer pass an ExecutionSpace in order to use asynchronous execution)

@julianlitz
Copy link
Collaborator Author

julianlitz commented Feb 19, 2026

We assume all Vectos to have the same execution space (cpu or gpu).
I think it makes sense to have less control, since we just want to copy a vector and don't need to worry about the execution spaces.

The only time where we have cpu <-> gpu transfers will be in the
coo_mumps_solver.h or csr_lu_solver.h.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants