Dear reviewers,

This PR aims at improving the error message for the variable type, but shows in an error for the variable type e.g. MONOMIAL of order 0: The 'order' is only displayed as an integer value. Should a ‘better’ value be displayed there? If so, how?

Kind regards,
Jörg

Dear @GiudGiud,

you mentioned in #28560 (comment) that other aspects of the variables also should be checked. Therefore, I introduced the parameter variable_deduplication_check as MultiMooseEnum. Extending (and controlling) checks should be easier this way.

Jörg

So... The new check on the block-restriction makes several tests fail. I see three ways on how to deal with this:

1. Add cli_args = 'Problem/variable_deduplication_check=ALLOW_MISMATCHING_BLOCK_RESTRICTIONS' and allow_warnings = true to all tests

2. We introduce IGNORE_MISMATCHING_BLOCK_RESTRICTIONS (what shows no warning for mismatching blocks) and add cli_args = 'Problem/variable_deduplication_check=IGNORE_MISMATCHING_BLOCK_RESTRICTIONS' to all tests

3. We change the tests. That would be very time-consuming.

I suggest option 2. What do you think?

Job Documentation on dcd356f wanted to post the following:

View the site here

This comment will be updated on new commits.

jmeier requested review from bwspenc, dschwen, jiangwen84, cpgr and recuero as code owners

Oh no! Sorry for pestering all of you! I had to change some tests due to the now stricter testing on the block restriction. Most of the tests had to be changed due to the handling of the block-restriction in [Physics/SolidMechanics/QuasiStatic] (e.g. also see #28308).

Dear @GiudGiud, if I interpred the logs correctly, the tests for Moose are all green now. There are failing tests for Mastodon and Raccoon. I've a fix for Mastodon/examples/ex05a.ex05a but not for the others where I'd need help. How do we proceed?

I ll take a look. We're working on releasing fluid properties right now so there's quite a few apps in the red in the meantime

Will need a patch for

• BISON
• subchannel
• mastodon
• malamute
  I ll work on these

Job Coverage on dcd356f wanted to post the following:

Framework coverage

Diff coverage report

Full coverage report

Modules coverage

Solid mechanics

Diff coverage report

Full coverage report

Full coverage reports

Warnings

• framework new line coverage rate 82.00% is less than the suggested 90.0%

This comment will be updated on new commits.

Ok looking at bison, it s breaking on adding variables with a SMALLER block restriction than the existing one (for example ANY_BLOCK_ID).

We should actually just allow that. It does not hurt to be trying to add variables that are already defined on a larger set of blocks.
Let s see how many app patches we need after that

Ok looking at bison, it s breaking on adding variables with a SMALLER block restriction than the existing one (for example ANY_BLOCK_ID).
We should actually just allow that. It does not hurt to be trying to add variables that are already defined on a larger set of blocks. Let s see how many app patches we need after that

When I initially created the code, I also had this thought: If we allow this, the order of commands in a Moose input file has an influence on whether this error occurs or not. Should we still allow this?

The only case where this happens is when you have two actions that act on the same task, adding variables. I can see this help combining actions

We should actually just allow that. It does not hurt to be trying to add variables that are already defined on a larger set of blocks. Let s see how many app patches we need after that

With the widening on the check regarding block-restriction "Bison" seems now to be green alogg all "internal app tests". There are still failing "public app tests" for:

• Mastodon (I have a fix for Mastodon/examples/ex05a.ex05a - but not the other 3)
• Ferret (this is new! but from the error message one could think this is unrelated)
• Raccoon

and the "controlled app tests" are also red.

Ferret and racoon are unrelated
Controlled is subchannel, I m looking into it

EDIT:
Subchannel patch is there: https://github.inl.gov/ncrc/subchannel/pull/336

Do you mind creting the patch to mastodon and tagging me? If it s not complete let me know and I can look at the remaining test failures

Subchannel patch is merged

Mastodon patch is merged though might not show on this testing round

Thanks for the contribution of this extra check!
That latest delay was due to next being broken since Thursday