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

RenameBoundaryGenerator does not handle merging boundaries #15786

Closed
permcody opened this issue Aug 25, 2020 · 7 comments
Closed

RenameBoundaryGenerator does not handle merging boundaries #15786

permcody opened this issue Aug 25, 2020 · 7 comments
Assignees
Labels
C: Framework C: Meshing MeshGenerator system, mesh loading Good first issue P: normal A defect affecting operation with a low possibility of significantly affects. T: task An enhancement to the software.

Comments

@permcody
Copy link
Member

permcody commented Aug 25, 2020

Reason

From Joe Kelley at the NRC:

I am working on a 7-cell model that uses the GapHeatTransfer BC for every pair of sidesets as was done for the "reference" calculation in the extended scope task.

In that calculation, there were only two axial regions in the meshing-tools script, the support plate and everything else. Unfortunately, the real geometry has 6 axial regions above the support plate (eg, lower reflector, fuel, etc). I don't want to have to specify GapHeatTransfer BCs for every axial level (if possible) as that would result in 6x12 = 72 BCs. I'd much rather just have to deal with only 12 BCs (especially as the tensor mechanics part is going to have to change the gap width for all of these).

So, why not merge them into one boundary (sideset) for all the axial regions of a given face? This is what I tried putting in a Mesh block:

  [merge_100_1]   # sidesets for face #1 of SA #100. 
    type = RenameBoundaryGenerator
    input = deleteHP7
    old_boundary_name = 's_1_2_2_1 s_2_2_2_1 s_3_2_2_1 s_4_2_2_1 s_5_2_2_1 s_6_2_2_1'
    new_boundary_name = 's_100_1   s_100_1   s_100_1   s_100_1   s_100_1   s_100_1'
  []

This does indeed collapse all 6 axial levels into one sideset. But, the axial extent of that sideset is only the first level.

Design

Being able to merge sidesets when renaming seems like a logical feature that should be supported. If not, we probably should produce a concise error explaining why we can't do this instead of giving the incorrect result.

Impact

Minor annoyance - but should be improved for better useability

@permcody permcody added C: Framework T: task An enhancement to the software. P: normal A defect affecting operation with a low possibility of significantly affects. Good first issue labels Aug 25, 2020
@GiudGiud GiudGiud added the C: Meshing MeshGenerator system, mesh loading label Apr 21, 2022
@socratesgorilla socratesgorilla self-assigned this May 2, 2022
@GiudGiud
Copy link
Contributor

GiudGiud commented May 2, 2022

@joe61vette can you share an example we can try this on?
I think this should have worked like this already

@joe61vette
Copy link

Wow. Almost 2 years ago. I vaguely remember this and somehow found a work around. But I did have a simple test problem and it runs fine
Archive.zip
.

@GiudGiud
Copy link
Contributor

GiudGiud commented May 2, 2022

I think this was fixed shortly after by a rework of that object. I wasnt aware of this issue.
We ll find out soon.

@loganharbour
Copy link
Member

loganharbour commented May 2, 2022

Yeah. My changes for independence of ordering should have fixed this.

Refs #16890 and #16885

@joe61vette
Copy link

In my previous comment, there is an archive with a simple 2 block test problem for this. It ran fine.

@socratesgorilla
Copy link
Contributor

socratesgorilla commented May 3, 2022

I will verify with some tests, and close the issue then if nothing is wrong.

@socratesgorilla
Copy link
Contributor

Seems to be working. No reason for this to stay open.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: Framework C: Meshing MeshGenerator system, mesh loading Good first issue P: normal A defect affecting operation with a low possibility of significantly affects. T: task An enhancement to the software.
Projects
None yet
Development

No branches or pull requests

5 participants