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

The block parameter should always be valid #2096

Closed
aeslaughter opened this issue Feb 14, 2014 · 2 comments
Closed

The block parameter should always be valid #2096

aeslaughter opened this issue Feb 14, 2014 · 2 comments
Assignees
Labels
C: Framework P: normal A defect affecting operation with a low possibility of significantly affects. T: task An enhancement to the software.

Comments

@aeslaughter
Copy link
Contributor

Block restricted objects rely on the "blocks" parameter, which should be populated if not defined. Derek proposes adding a BlockRestrictedInterface to enable this behavior for all objects that should be restricted.

@aeslaughter
Copy link
Contributor Author

I attached a patch that implements and tests a BlockRestrictable class that is inherited by any object that you would like to user the 'block' input parameter. Someone should take a look at it and see if this will work.

Two things that I believe still need to be addressed are:

  • The SubdomainIDs are passed using std::set and std::vector in MOOSE and libMesh, it seems like we should pick one and be consistent (if possible). Currently the BlockRestrictable class in this patch attempts allows you to use either.
  • Some objects, Postprocessors, default to ANY_BLOCK_ID. This seems like it should be the default for all objects. It seems that currently in MOOSE and empty block is the same as ANY_BLOCK_ID, I think we should pick one and use this new class to control the behavior.

@aeslaughter
Copy link
Contributor Author

In 40bcede:

Created BlockRestrictable class for restricting objects to block ids (closes-#2096)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: Framework 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

1 participant