Fix bug in RenameBlockGenerator

[yjung-anl]

Bug Description

Found that the block id is not properly re-assigned for certain cases. The following is the case having this issue. The resulting block_id of "RenameBlockGenerator" is "1 2 1" not "3 2 1" as shown in below figures.

[Mesh]
  [a]
    type = ConcentricCircleMeshGenerator
    num_sectors = 4
    radii = '0.4 0.5'
    rings = '2 1 1'
    has_outer_square = on
    pitch = 1.2
    preserve_volumes = yes
    smoothing_max_it = 3
  []

  [b]
    type = RenameBlockGenerator
    input = 'a'
    old_block_id = '1 2 3'
    new_block_id = '3 2 1'
  []
[]

Before applying RenameBlockGenerator (Block: 1 2 3 from center to outer)

After applying RenameBlockGenerator (Block: 1 2 1 from center to outer)

Steps to Reproduce

It can be reproduced for the input case attached above.

Impact

Fix bug in RenameBlockGenerator

[yjung-anl]

Already Fixed this bug in RenameBlockGenerator and will make PR soon.

[loganharbour]

Are you creating temporary blocks when a from block exists in the to blocks? That's how it should be done here; we just did the same with RenameBoundaryGenerator.

[yjung-anl]

@loganharbour
In case of creating multiple pins and merging them together, I renamed the block IDs after each pin creation for assigning for different materials in the final merged mesh.

This is the code section of replacing the block id in RenameBlockGenerator

  for (const auto & elem : mesh->active_element_ptr_range())
    for (unsigned i = 0; i < _old_block_id.size(); ++i)
      if (elem->subdomain_id() == _old_block_id[i])
        elem->subdomain_id() = _new_block_id[i];

I think break should be inserted as:

  for (const auto & elem : mesh->active_element_ptr_range())
    for (unsigned i = 0; i < _old_block_id.size(); ++i)
      if (elem->subdomain_id() == _old_block_id[i])
      {
        elem->subdomain_id() = _new_block_id[i];
        break;
      }

Otherwise, block 1 is replaced to 3 first then, replaced again to 1 due to new_block_id setting.

[loganharbour]

I'm afraid that won't work in the case of when boundary names are input. We need to keep track of the underlying ID, and then create temp blocks. For example:

We have the following blocks

• exterior (0)
• interior (1)
• something_else (2)

And the user wants this

old_block_id = '0 1 2'
new_block_id = '1 2 0'

What we would do is first notice that 0 exists within the new IDs, so we would create a temp '3'. Then, we would do
0 -> 3, 1 -> 2, 2-> 0, 3-> 1.

This makes it independent of ordering. In addition, I'd like to simplify the parameters and only have a single parameter old_block and new_block. I did the same for RenameBoundaryGenerator. I can actually take a look at this right now, I suspect it's a little more work than you expected. Let me know.

[yjung-anl]

Now I see your point. For avoiding the issue, it would be better to define a temporary block id rather than doing the way I did. Good to know. Thank you!

[loganharbour]

I just rewrote RenameBoundaryGenerator for this similar behavior, and I'm in a good place to rework RenameBlockGenerator in the same sense. We'd also like to remove the {}_id and {}_name parameters and let the user supply both IDs and names at the same time. If you have something that works for you for now, how about you use that and I'll work on reworking RenameBlockGenerator this morning?

[yjung-anl]

I think your modification would work for my cases - providing both Names an IDs at the same time. Thank you for very quick response!

[loganharbour]

@yjung-anl, see #17711 for the new capability

[yjung-anl]

I checked your updates. It looks good to me!