Skip to content

Tridiagonal Solver#1234

Merged
lroberts36 merged 11 commits into
developfrom
lroberts36/tri-diag-solver
Jun 5, 2025
Merged

Tridiagonal Solver#1234
lroberts36 merged 11 commits into
developfrom
lroberts36/tri-diag-solver

Conversation

@lroberts36
Copy link
Copy Markdown
Collaborator

@lroberts36 lroberts36 commented Mar 24, 2025

PR Summary

This PR implements a tridiagonal solver within the Parthenon solver framework. This is meant for testing only and will only work for one-dimensional, single block runs. Additionally, it will only work for matrices that extend only one zone away in each direction. The advantage of this solver is that it is direct, so it sometimes allows for disentangling issues related to iterative solver convergence from downstream code implementation issues.

PR Checklist

  • Code passes cpplint
  • New features are documented.
  • Adds a test for any bugs fixed. Adds tests for new features.
  • Code is formatted
  • Changes are summarized in CHANGELOG.md
  • Change is breaking (API, behavior, ...)
    • Change is additionally added to CHANGELOG.md in the breaking section
    • PR is marked as breaking
    • Short summary API changes at the top of the PR (plus optionally with an automated update/fix script)
  • CI has been triggered on Darwin for performance regression tests.
  • Docs build
  • (@lanl.gov employees) Update copyright on changed files

Copy link
Copy Markdown
Collaborator

@Yurlungur Yurlungur left a comment

Choose a reason for hiding this comment

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

Looks reasonable. Also looks like it might be incomplete? Is everything in here you want? And should it be tested in the CI?


auto [rebuild, nbound] = CheckReceiveBufferCacheForRebuild<bound_type, false>(md);

if (rebuild) {
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Is this stuff no longer necessary?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

That should be removed from this PR since it isn't relevant to the solver (it got included in the PR by mistake), but I think the change may actually be necessary. There was a bug I ran into a few weeks ago that was fixed by this change, but I never was able to fully wrap my head around what was going on.

@lroberts36 lroberts36 changed the title Tridiagonal Solver WIP: Tridiagonal Solver Mar 25, 2025
@lroberts36
Copy link
Copy Markdown
Collaborator Author

@Yurlungur:

Looks reasonable. Also looks like it might be incomplete? Is everything in here you want? And should it be tested in the CI?

The solver as written is complete (it is very simple), but the changes to bvals stuff should not be included here. I have put the PR in WIP status until I remove that stuff. I guess it would be trivial to add a test to the solver CI as well.

@lroberts36 lroberts36 changed the title WIP: Tridiagonal Solver Tridiagonal Solver Mar 26, 2025
Copy link
Copy Markdown
Collaborator

@pgrete pgrete left a comment

Choose a reason for hiding this comment

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

LGTM

other minor comments:

  • how about adding a comment somewhere at the top of the file that this is just for testing purpose (and already mention the restrictions in addition to the already implemented hard checks)?
  • how hard/useful would it be to add some kind of (simple) test that makes use of the solver (motivated by the comment in the description that this was useful to test some part of the infrastructure downstream)?

std::string container_base;
// User defined container in which the solution will reside, only needs to contain
// sol_fields
// TODO(LFR): Also allow for an initial guess to come in here
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Future todo or this PR?

Comment on lines +196 to +200
// Since this needs to be sequential, we launch an outer loop of size one. Obviously
// this would be really inefficient on device
parthenon::par_for(
DEFAULT_LOOP_PATTERN, "DotProduct", DevExecSpace(), 0, 0,
KOKKOS_LAMBDA(const int) {
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Could this be replaced by a parallel_scan (in principle)?

DEFAULT_LOOP_PATTERN, "PrintSolution", DevExecSpace(), 0, 0, kb.s, kb.e, jb.s,
jb.e, ib.s - 1, ib.e + 1,
KOKKOS_LAMBDA(const int b, const int k, const int j, const int i) {
printf("row %i: %e %e %e %e \n", i, pack_u(b, 0, k, j, i),
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Maybe Kokkos::printf?

Comment on lines +303 to +304
Real GetSquaredResidualSum() const { return 0.0; }
int GetCurrentIterations() const { return 1; }
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

This is hardcoded because it's not needed for the direct, single block solve, isn't it?

@Yurlungur Yurlungur enabled auto-merge May 15, 2025 18:18
@Yurlungur Yurlungur disabled auto-merge May 15, 2025 18:18
@lroberts36 lroberts36 enabled auto-merge June 5, 2025 17:01
@lroberts36 lroberts36 merged commit ba82484 into develop Jun 5, 2025
35 checks passed
@Yurlungur Yurlungur deleted the lroberts36/tri-diag-solver branch June 20, 2025 19:51
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.

3 participants