Skip to content

Revise "Add block_ids_from_names"#7085

Merged
nilsvu merged 5 commits intosxs-collaboration:developfrom
nilsvu:block_ids_from_names
Mar 6, 2026
Merged

Revise "Add block_ids_from_names"#7085
nilsvu merged 5 commits intosxs-collaboration:developfrom
nilsvu:block_ids_from_names

Conversation

@nilsvu
Copy link
Member

@nilsvu nilsvu commented Feb 24, 2026

Proposed changes

Switch from std::set to std::vector as discussed in #7061.

Upgrade instructions

Code review checklist

  • The code is documented and the documentation renders correctly. Run
    make doc to generate the documentation locally into BUILD_DIR/docs/html.
    Then open index.html.
  • The code follows the stylistic and code quality guidelines listed in the
    code review guide.
  • The PR lists upgrade instructions and is labeled bugfix or
    new feature if appropriate.

Further comments

@nilsvu nilsvu force-pushed the block_ids_from_names branch 3 times, most recently from 3ba156b to e2e1d66 Compare February 27, 2026 23:34
Copy link
Member

@nilsdeppe nilsdeppe left a comment

Choose a reason for hiding this comment

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

LGTM, a few small suggestions that you can squash immediately. That's for doing this :)

block_groups);

/*!
* \brief Get the block IDs corresponding to the given block or group names.
Copy link
Member

Choose a reason for hiding this comment

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

maybe add sorted block IDs? Then people can rely on it being sorted.

Copy link
Member

Choose a reason for hiding this comment

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

That's a good point. Probably with fairly clear instructions it should do well. Given this is pretty deterministic and at least Claude can use clangd, this could work

"The block or group 'NoBlock' is not one of the block names or "
"groups of the domain."));
CHECK(block_ids_from_names({"Block1", "Group2"}, all_block_names,
block_groups) == std::vector<size_t>{0, 2, 3});
Copy link
Member

Choose a reason for hiding this comment

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

Could you add a test that explicitly verifies the data is sorted on output? I think this one sort of does, but it might be worth doing {"Block2", "Block1"} and checking it is sorted and that it is the same as {"Block1", "Block2"}.

Can you also test you get the expected output for {"Block1", "Group1"}?


/*!
* \brief Get the block IDs corresponding to the given block or group names.
*
Copy link
Member

Choose a reason for hiding this comment

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

Document that this will throw an exception if a block or group name is not present?

}
// Sort the block IDs just so they're easier to deal with.
alg::sort(only_dg_block_ids_.value());
only_dg_block_ids_ = domain::block_ids_from_names(
Copy link
Member

Choose a reason for hiding this comment

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

[optional but appreciated] I think the header file or whenever the binary_search is should also be switched to the linear search since that'll be faster for such small data.

* \param block_groups Block groups used to expand the names.
* \return std::vector<size_t> Sorted list of block IDs.
*/
std::vector<size_t> block_ids_from_names(
Copy link
Member

Choose a reason for hiding this comment

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

I'm undecided on this, but I wonder if we should in general switch to uint16_t for block IDs. I think we could even do so locally in places without worrying about it. It seems unlikely we will have ~2^16 blocks any time soon. The main advantage is reduced size and possibly faster lookup. This is going to be such a small cost that I don't think we should put extra effort into changing it, but if we decide it's a reasonable direction to go we could do so gradually as we remember 🤷 To be clear, I'm not asking for a change in this PR, just wanted to mention it.

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 also have the class BlockId that's used in some old code. We could revive that and use it instead of size_t, then we can swap out the underlying representation if we want. A coding agent might be able to do the refactor.

@nilsvu
Copy link
Member Author

nilsvu commented Mar 3, 2026

Pushed a fixup and another commit for the linear search

@nilsvu nilsvu force-pushed the block_ids_from_names branch from 90262a4 to 1263883 Compare March 5, 2026 00:23
@nilsvu nilsvu requested a review from nilsdeppe March 5, 2026 00:26
@nilsdeppe
Copy link
Member

LGTM! Please squash! And thanks for doing this :)

@nilsvu nilsvu force-pushed the block_ids_from_names branch from 1263883 to d674a85 Compare March 5, 2026 17:24
@nilsvu
Copy link
Member Author

nilsvu commented Mar 5, 2026

Rebased and squashed 👍

@nilsdeppe nilsdeppe enabled auto-merge March 5, 2026 17:34
@nilsdeppe nilsdeppe added the auto-merge GitHub's auto-merge has been enabled for this PR. label Mar 5, 2026
@nilsvu nilsvu disabled auto-merge March 6, 2026 21:54
@nilsvu nilsvu merged commit 8b14ba8 into sxs-collaboration:develop Mar 6, 2026
80 of 96 checks passed
@nilsvu nilsvu deleted the block_ids_from_names branch March 6, 2026 21:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

auto-merge GitHub's auto-merge has been enabled for this PR.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants