Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add local to global index mapping #1707

Open
wants to merge 8 commits into
base: develop
Choose a base branch
from
Open

Conversation

MarcelKoch
Copy link
Member

This PR adds a local-to-global mapping to the index_map class. It is necessary for the follow-up PR #1639. This also introduces a device-side view of a partition, and adds another member to the partition which stores the range-ids segmented by their part-id.

(I know that the branch name is wrong...)

@MarcelKoch MarcelKoch added the 1:ST:ready-for-review This PR is ready for review label Oct 23, 2024
@MarcelKoch MarcelKoch added this to the Ginkgo 1.9.0 milestone Oct 23, 2024
@MarcelKoch MarcelKoch self-assigned this Oct 23, 2024
@ginkgo-bot ginkgo-bot added reg:testing This is related to testing. mod:all This touches all Ginkgo modules. labels Oct 23, 2024
@MarcelKoch MarcelKoch mentioned this pull request Oct 23, 2024
2 tasks
@fritzgoebel fritzgoebel self-requested a review October 30, 2024 10:36
@MarcelKoch MarcelKoch modified the milestones: Ginkgo 1.9.0, Ginkgo 1.10.0 Dec 9, 2024
Copy link
Member

@yhmtsai yhmtsai left a comment

Choose a reason for hiding this comment

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

not finish review yet.
why is it required for PGM?
after merging row and column, do they still need to map back to the global index?
you need to reindex all of them because the size will be the smaller than the original one after coarsening.

//
// SPDX-License-Identifier: BSD-3-Clause

#ifndef GINKGO_PARTITION_HPP
Copy link
Member

Choose a reason for hiding this comment

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

nit:

Suggested change
#ifndef GINKGO_PARTITION_HPP
#ifndef GKO_CORE_DISTRIBUTED_DEVICE_PARTITION_HPP_

Comment on lines +36 to +38
/**
* Create device_segmented_array from a segmented_array.
*/
Copy link
Member

Choose a reason for hiding this comment

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

forgot to update documentation?

Comment on lines +62 to +64
* Explicitly create a const version of device_segmented_array.
*
* This is mostly relevant for tests.
Copy link
Member

Choose a reason for hiding this comment

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

same here

*/
template <typename LocalIndexType, typename GlobalIndexType>
constexpr device_partition<const LocalIndexType, const GlobalIndexType>
to_device_const(
Copy link
Member

Choose a reason for hiding this comment

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

is there any difference between to_device_const and to_device?

*
* The relevant input parameter from the index map are:
*
* - partition: the global partition
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
* - partition: the global partition
* - partition: the global partition

});

sizes.resize_and_reset(num_parts);
std::fill_n(sizes.get_data(), num_parts, int64(0));
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
std::fill_n(sizes.get_data(), num_parts, int64(0));
std::fill_n(sizes.get_data(), num_parts, zero<int64>());

Comment on lines +123 to +125
auto seed = engine_dist(rd);
std::cout << "seed = " << seed << std::endl;
engine.seed(490729788);
Copy link
Member

Choose a reason for hiding this comment

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

some leftover?

Comment on lines +133 to +137
exec->run(partition::make_build_ranges_by_part(
part_ids_.get_const_data(), get_num_ranges(), get_num_parts(),
range_ids, num_ranges_per_part));
ranges_by_part_ = segmented_array<size_type>::create_from_sizes(
std::move(range_ids), num_ranges_per_part);
Copy link
Member

Choose a reason for hiding this comment

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

currently, this rely on the atomic add to count the size.
then segmented_array will convert size to offset.
Maybe you can implement a similar kernel with convert_idxs_to_ptrs + additional index map from i to range_id[i] because range_part[range_id[i]] is sorted. then segmented_array can create_from_offsets directly

template <typename LocalIndexType, typename GlobalIndexType>
GlobalIndexType map_to_global(
LocalIndexType idx,
device_partition<const LocalIndexType, const GlobalIndexType> partition,
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
device_partition<const LocalIndexType, const GlobalIndexType> partition,
const device_partition<const LocalIndexType, const GlobalIndexType>& partition,

device_partition<const LocalIndexType, const GlobalIndexType> partition,
size_type range_id)
{
auto range_bounds = partition.offsets_begin;
Copy link
Member

Choose a reason for hiding this comment

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

assert range_id is lower than num_range?

@MarcelKoch
Copy link
Member Author

after merging row and column, do they still need to map back to the global index?
you need to reindex all of them because the size will be the smaller than the original one after coarsening.

@yhmtsai I don't understand your point, could you rephrase this?

@yhmtsai
Copy link
Member

yhmtsai commented Dec 18, 2024

rank 0: holds row 0, 1, 4
rank 1: holds row 2, 3
if we mege 0, 1 and 2, 3
rank 0: 0, 4
rank 1: 2
we need to compute the size of each gap from different node and then reindex the global index
rank 0: 0, 2
rank 1: 1

@MarcelKoch
Copy link
Member Author

@yhmtsai I think this discussion makes more sense in #1639. I don't see much relevance to this PR.

@yhmtsai
Copy link
Member

yhmtsai commented Dec 18, 2024

yes, but if PGM does not need it, do you still need this function for something else?

@MarcelKoch
Copy link
Member Author

I think I need at least parts of it to keep the old distributed matrix constructor around. @fritzgoebel also seems to need it for his domain decomposition matrix.

Anyway, this still sounds like a discussion for #1639.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1:ST:ready-for-review This PR is ready for review mod:all This touches all Ginkgo modules. reg:testing This is related to testing.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants