Skip to content

Conversation

yhmtsai
Copy link
Member

@yhmtsai yhmtsai commented Oct 9, 2024

This adds a cache/workspace for the intermediate vector in advanced_apply of Schwarz.
Also, it makes apply_uses_initial_guess rely on the local_solver->apply_uses_initial_guess().
We might need to revisit this function after adding refining step in Schwarz.

@yhmtsai yhmtsai added the 1:ST:ready-for-review This PR is ready for review label Oct 9, 2024
@yhmtsai yhmtsai requested review from a team and pratikvn October 9, 2024 12:40
@yhmtsai yhmtsai self-assigned this Oct 9, 2024
@ginkgo-bot ginkgo-bot added reg:testing This is related to testing. mod:core This is related to the core module. type:preconditioner This is related to the preconditioners labels Oct 9, 2024

template <typename ValueType, typename LocalIndexType, typename GlobalIndexType>
template <typename VectorType>
void Schwarz<ValueType, LocalIndexType, GlobalIndexType>::set_cache_to(
Copy link
Member

Choose a reason for hiding this comment

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

You only need this function once, right? Then I would prefer to just add this directly, it's not that much IMO.

* (could also be done with writing `operator=` and copy
* constructor of the enclosing class by hand)
*/
mutable struct cache_struct {
Copy link
Member

Choose a reason for hiding this comment

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

I think this should be a DenseCache instead.

Copy link
Member Author

Choose a reason for hiding this comment

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

I think it does not support distributed::Vector.

Copy link
Member

Choose a reason for hiding this comment

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

you're right. Perhaps it would make sense to add VectorCache, instead of using the cache construct.

Copy link
Member

@pratikvn pratikvn left a comment

Choose a reason for hiding this comment

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

I agree with the Marcel that it can be a DenseCache instead of cache_struct. But otherwise looks good to me. I approve it as Marcel has already requested that change.

@MarcelKoch MarcelKoch added this to the Ginkgo 1.9.0 milestone Oct 17, 2024
@yhmtsai yhmtsai force-pushed the schwarz_update branch 2 times, most recently from 8948a5d to 4ed9711 Compare November 4, 2024 00:14
friend class SparsityCsr<ValueType, int64>;
friend class Dense<to_complex<ValueType>>;
friend class experimental::distributed::Vector<ValueType>;
friend class gko::detail::VectorCache<ValueType>;
Copy link
Member

Choose a reason for hiding this comment

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

why is this necessary?

Copy link
Member Author

Choose a reason for hiding this comment

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

Because distributed::Vector holds the Dense object not Dense pointer, I need the constructor to construct the object directly and then use the move_to

Copy link
Member Author

Choose a reason for hiding this comment

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

ah, I might use the unique_ptr.release from create function

Copy link
Member

Choose a reason for hiding this comment

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

No it's fine, I just got confused. I thought this was in the distributed::Matrix.

Copy link
Member

@pratikvn pratikvn left a comment

Choose a reason for hiding this comment

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

Nice work! LGTM!

// handle locally to eliminate the mpi call
std::cout << "local diff" << comm.rank() << std::endl;
vec->local_ =
std::move(gko::matrix::Dense<ValueType>(exec, local_size));
Copy link
Member

Choose a reason for hiding this comment

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

nit: use the create function instead ?

Copy link
Member Author

Choose a reason for hiding this comment

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

We hold the object not the pointer.
However, I can create the unique pointer and release the object out actually, right?

Copy link
Member Author

Choose a reason for hiding this comment

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

do you think it is neccessary to do unique_ptr through the create function?
I slightly prefer the constructor to avoid calling release from unique_ptr, but it requires the friend declration in dense such that VectorCache can use Dense constructor

Copy link
Member

Choose a reason for hiding this comment

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

No, It is a only a nit from my side. Using the constructor should also be okay.

} else if (vec->get_local_vector()->get_size() !=
template_vec->get_local_vector()->get_size()) {
// handle locally to eliminate the mpi call
vec->local_ = std::move(gko::matrix::Dense<ValueType>(
Copy link
Member

Choose a reason for hiding this comment

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

nit: use the create function instead ?

Copy link
Member

@pratikvn pratikvn left a comment

Choose a reason for hiding this comment

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

Some fixes needed

#if GINKGO_BUILD_MPI


namespace gko {
Copy link
Member

Choose a reason for hiding this comment

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

I think it might make sense to put this into the experimental and distributed namespaces.

Copy link
Member Author

Choose a reason for hiding this comment

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

I move it into gko::experimental::distributed::detail

@yhmtsai yhmtsai added 1:ST:ready-to-merge This PR is ready to merge. and removed 1:ST:ready-for-review This PR is ready for review labels Nov 4, 2024
yhmtsai and others added 2 commits November 5, 2024 10:57
Co-authored-by: Pratik Nayak <pratikvn@protonmail.com>
@yhmtsai yhmtsai changed the title add workspace for intermediate vector in and adapt apply_uses_initial_guess in Schwarz Add Distributed VectorCache and use it for intermediate vector in and adapt apply_uses_initial_guess in Schwarz Nov 5, 2024
@yhmtsai yhmtsai merged commit 7b04094 into develop Nov 5, 2024
8 of 11 checks passed
@yhmtsai yhmtsai deleted the schwarz_update branch November 5, 2024 14:02
Copy link

sonarqubecloud bot commented Nov 5, 2024

MarcelKoch pushed a commit to MarcelKoch/ginkgo that referenced this pull request Dec 2, 2024
…intermediate vector in and adapt `apply_uses_initial_guess` in Schwarz

This PR adds distributed VectorCache and uses it as the workspace in Schwarz to avoid alloc/free memory operation.

Related PR: ginkgo-project#1688
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

1:ST:ready-to-merge This PR is ready to merge. mod:core This is related to the core module. reg:testing This is related to testing. type:preconditioner This is related to the preconditioners

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants