Default block restriction #30300

ChengHauYang · 2025-04-10T18:41:32Z

Reason

When using element subdomain modifiers (e.g., additive manufacturing, welding), simulations are often restricted to a specific subset of blocks (subdomains). However, users currently need to manually specify these block restrictions repeatedly in multiple places within the input file, such as kernel_coverage_block_list, material_coverage_block_list, and the block parameter for individual Kernels, Materials, and Variables.

This repetitive setup increases the chances of user error and makes input files harder to maintain. A more user-friendly and centralized way to control block restrictions is desired.

Design

This PR introduces a new parameter default_block under the [Problem] block to provide a centralized way to control block restrictions throughout the input file.

[Problem]
  default_block = '0 1 3'
[]

Setting default_block will automatically:

(a) Set kernel_coverage_check = ONLY_LIST and kernel_coverage_block_list = '0 1 3' to [Problem].

(b) Set material_coverage_check = ONLY_LIST and material_coverage_block_list = '0 1 3' to [Problem].

(c) Apply the specified blocks to any BlockRestrictable object (e.g., Kernels, Materials, Variables) that does not explicitly define its own block parameter.

Flexibility & Overriding Behavior
(a) Users can still override kernel_coverage_block_list or material_coverage_block_list inside [Problem] even if default_block is set.

(b) Users can explicitly set block for individual Kernels, Materials, or Variables, provided that the specified blocks are a subset of default_block.

(c) If a user tries to specify blocks outside of default_block, an warning will be raised to prevent unintended behavior.

Example:

[Kernels]
  [./diff]
    type = HeatConduction
    variable = cond
  [../]
[]

This will automatically apply to blocks 0 1 3.

But if user set:

[Kernels]
  [./diff]
    type = HeatConduction
    variable = cond
    block = '0 1 2 3' # block 2 is not in default_block
  [../]
[]

Will show a warning:

*** Warning ***
The supplied block list is not a subset of the default block list

Impact

This change improves usability and reduces duplication in input file setup, especially for simulations involving subdomain-based modifiers. It provides a clear and centralized control for block restrictions while preserving flexibility for advanced users.

This enhancement is particularly useful for applications like additive manufacturing, and welding.

close idaholab#30299

… (`modules/heat_transfer/test/tests/default_block_check`) (c) material_coverage_check fixing

hugary1995

Looks good overall. Some minor comments.

framework/include/problems/FEProblemBase.h

framework/src/actions/AddVariableAction.C

modules/heat_transfer/test/tests/default_block_check/convection-with-null-material.i

modules/heat_transfer/test/tests/default_block_check/tests

python/chigger/exodus/ExodusReader.py

lindsayad

We'll need some markdown documentation for this. It will help me understand the context more. I always want to carefully understand the need any time we're adding a parameter to our kitchen sink object (FEProblemBase)

lindsayad · 2025-04-10T21:25:28Z

Your PR description is nice and thorough, so a good start candidate for translation into markdown

lindsayad · 2025-04-10T21:27:03Z

Most importantly, thank you for contributing!

…d` to explain the `default_block` effect in coverage checking and block restrictions. (b) move the tests into `/test/tests/default_block_check`. (c) Fix according to Gary's comments.

ChengHauYang · 2025-04-11T14:17:49Z

Dear @hugary1995 and @lindsayad, thanks for your code review. I fixed the code according to Gary's comments and prepared some markdown documentation, adding them into sanity_checking.md and BlockRestrictable.md. Thanks

hugary1995

Just a few more minor comments then it's all clear from my side.

.idea/moose-chenghau.iml

.idea/.gitignore

framework/doc/content/source/interfaces/BlockRestrictable.md

framework/include/interfaces/BlockRestrictable.h

modules/doc/content/framework_development/sanity_checking.md

modules/heat_transfer/log

…aultBlockConsistency()

hugary1995

I approve. We should have at least one approve from the framework team. @lindsayad

…w default_block implementation.

moosebuild · 2025-04-11T18:42:46Z

Job Documentation, step Docs: sync website on ec5a868 wanted to post the following:

View the site here

This comment will be updated on new commits.

moosebuild · 2025-04-11T20:03:02Z

Job Coverage, step Generate coverage on ec5a868 wanted to post the following:

Framework coverage

Inconsistent report tags were found between the head and base reports.
This can happen when reports are missing from either the head or the base.

Inconsistent tags:
framework-torch-gpu
Full coverage report

Modules coverage

Fluid properties

	788dee	#30300 ec5a86
	Total	Total	+/-	New
Rate	86.08%	86.09%	+0.01%	-
Hits	7982	7983	+1	0
Misses	1291	1290	-1	0

Diff coverage report

Full coverage report

Full coverage reports

Reports

This comment will be updated on new commits.

lindsayad · 2025-04-11T22:41:30Z

framework/doc/content/source/interfaces/BlockRestrictable.md

+this behavior by explicitly specifying the `block` parameter within each object. If an explicitly
+specified `block` is not a subset of the `default_block`, MOOSE will throw a warning
+to notify the user about the inconsistency.


I'm not sure if we want this to be a warning. I think one possible use case for this @hugary1995 mentioned is excluding lower-dimensional subdomains. But in that case, any lagrange multipliers rightly living on the lower-d subdomains will trigger this warning

I agree. Also semantically it isn't a mistake to override default.

Dear @lindsayad and @hugary1995, thanks for your feedback. I removed the warning and associated function and test in the new commit. Thanks!

…te the associated function and regression test.

framework/include/problems/FEProblemBase.h

framework/src/interfaces/BlockRestrictable.C

framework/src/problems/FEProblemBase.C

framework/src/systems/SystemBase.C

ChengHauYang · 2025-04-12T04:45:02Z

In the new commit, I tried to address:

(a) The system shall throw an error if the user specifies either kernel_coverage_check or material_coverage_check together with default_block.
(b) The system shall allow users to include ANY_BLOCK_ID in the default_block parameter.
(c) Avoiding unnecessary copying of the block_param vector by using a reference.

Thanks for the feedback!

…nel_coverage_check` or `material_coverage_check` together with `default_block`. (b) The system shall allow users to include `ANY_BLOCK_ID` in the `default_block` parameter. (c) Avoiding unnecessary copying of the `block_param` vector by using a reference.

ChengHauYang · 2025-04-14T15:29:51Z

Dear @lindsayad,

I fixed the codes based on your feedback. Thanks.

With the discussions with @hugary1995 and his suggestions. We tried to have the below logic as well (which is aligned with your feedback):
If the user sets either kernel_coverage_check or material_coverage_check to ONLY_LIST or SKIP_LIST, and simultaneously provides a kernel_coverage_block_list or material_coverage_block_list, the presence of a default_block can introduce ambiguity in determining which blocks are subject to coverage checks. To avoid confusion, the system will throw an error in this case.
This restriction is necessary to prevent unintended behavior. However, there are situations where the user may want to completely disable kernel_coverage_check (kernel_coverage_check = FALSE) while still using default_block. In such cases, the system will not throw any error.

lindsayad

Almost there!

framework/include/problems/FEProblemBase.h

framework/src/interfaces/BlockRestrictable.C

test/tests/default_block_check/tests

…d be devoid of implementation details (test-driven development)

ChengHauYang · 2025-04-14T19:37:33Z

Dear @lindsayad,

Thanks for your constructive and detailed feedback. I have fixed the codes.

moosebuild · 2025-04-15T04:10:36Z

Job Conda build (ARM Mac) on ec5a868 : invalidated by @lindsayad

hugary1995 · 2025-04-15T15:24:29Z

Let's wait for @bwspenc 's review.

Default block restriction

1261730

close idaholab#30299

ChengHauYang requested review from roystgnr and lindsayad as code owners April 10, 2025 18:41

(a) make active block to be default block (b) add regression test…

391abd9

… (`modules/heat_transfer/test/tests/default_block_check`) (c) material_coverage_check fixing

ChengHauYang force-pushed the default_block branch from f3f9abc to 391abd9 Compare April 10, 2025 20:38

hugary1995 requested changes Apr 10, 2025

View reviewed changes

lindsayad requested changes Apr 10, 2025

View reviewed changes

ChengHauYang added 2 commits April 11, 2025 09:02

(a) Add some lines into sanity_checking.md and `BlockRestrictable.m…

ef87d1c

…d` to explain the `default_block` effect in coverage checking and block restrictions. (b) move the tests into `/test/tests/default_block_check`. (c) Fix according to Gary's comments.

minor removal

2a75f1f

hugary1995 requested changes Apr 11, 2025

View reviewed changes

hugary1995 self-assigned this Apr 11, 2025

(a) polish and fix the documentation (b) rename the function checkDef…

0394c56

…aultBlockConsistency()

ChengHauYang requested review from lindsayad and hugary1995 April 11, 2025 14:57

hugary1995 approved these changes Apr 11, 2025

View reviewed changes

hugary1995 mentioned this pull request Apr 11, 2025

Spurious solid-mechanics kernels on lower-dimensional meshes #27385

Open

Remove a regression test unrelated to the correctness check of the ne…

d8f29f4

…w default_block implementation.

fix website bug message

25ea296

lindsayad reviewed Apr 11, 2025

View reviewed changes

remove the warning for using blocks outside of default_block and dele…

8ccf55a

…te the associated function and regression test.

lindsayad reviewed Apr 11, 2025

View reviewed changes

ChengHauYang force-pushed the default_block branch from a3e4877 to c86b71a Compare April 12, 2025 04:52

user cannot set both 'coverage_check' and 'default_block' together

e17bc56

documentation fixing

fa480ba

path correction inside tests

91012f2

lindsayad requested changes Apr 14, 2025

View reviewed changes

framework/include/problems/FEProblemBase.h Outdated Show resolved Hide resolved

framework/src/interfaces/BlockRestrictable.C Outdated Show resolved Hide resolved

test/tests/default_block_check/tests Outdated Show resolved Hide resolved

(a) helper lambda to avoid duplicated lines (b) the requirement shoul…

ec5a868

…d be devoid of implementation details (test-driven development)

lindsayad approved these changes Apr 14, 2025

View reviewed changes

hugary1995 requested a review from bwspenc April 15, 2025 15:24

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Default block restriction #30300

Default block restriction #30300

ChengHauYang commented Apr 10, 2025 •

edited

Loading

hugary1995 left a comment

lindsayad left a comment

lindsayad commented Apr 10, 2025

lindsayad commented Apr 10, 2025

ChengHauYang commented Apr 11, 2025

hugary1995 left a comment

hugary1995 left a comment

moosebuild commented Apr 11, 2025 •

edited

Loading

moosebuild commented Apr 11, 2025 •

edited

Loading

lindsayad Apr 11, 2025

hugary1995 Apr 11, 2025

ChengHauYang Apr 11, 2025

ChengHauYang commented Apr 12, 2025 •

edited

Loading

ChengHauYang commented Apr 14, 2025

lindsayad left a comment

ChengHauYang commented Apr 14, 2025

moosebuild commented Apr 15, 2025

hugary1995 commented Apr 15, 2025

Default block restriction #30300

Are you sure you want to change the base?

Default block restriction #30300

Conversation

ChengHauYang commented Apr 10, 2025 • edited Loading

Reason

Design

Impact

hugary1995 left a comment

Choose a reason for hiding this comment

lindsayad left a comment

Choose a reason for hiding this comment

lindsayad commented Apr 10, 2025

lindsayad commented Apr 10, 2025

ChengHauYang commented Apr 11, 2025

hugary1995 left a comment

Choose a reason for hiding this comment

hugary1995 left a comment

Choose a reason for hiding this comment

moosebuild commented Apr 11, 2025 • edited Loading

moosebuild commented Apr 11, 2025 • edited Loading

Framework coverage

Modules coverage

Fluid properties

Full coverage reports

lindsayad Apr 11, 2025

Choose a reason for hiding this comment

hugary1995 Apr 11, 2025

Choose a reason for hiding this comment

ChengHauYang Apr 11, 2025

Choose a reason for hiding this comment

ChengHauYang commented Apr 12, 2025 • edited Loading

ChengHauYang commented Apr 14, 2025

lindsayad left a comment

Choose a reason for hiding this comment

ChengHauYang commented Apr 14, 2025

moosebuild commented Apr 15, 2025

hugary1995 commented Apr 15, 2025

ChengHauYang commented Apr 10, 2025 •

edited

Loading

moosebuild commented Apr 11, 2025 •

edited

Loading

moosebuild commented Apr 11, 2025 •

edited

Loading

ChengHauYang commented Apr 12, 2025 •

edited

Loading