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

Better error checking for BoundaryRestricted objects #6987

Closed
friedmud opened this issue May 17, 2016 · 0 comments
Closed

Better error checking for BoundaryRestricted objects #6987

friedmud opened this issue May 17, 2016 · 0 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

@friedmud
Copy link
Contributor

Description of the enhancement or error report

Currently, BoundaryRestrictable objects are checked to make sure their boundary IDs exist... BUT they're checked against both nodesets and sidesets (when they may be restricted to just a single type). This can allow some objects to "slip through" if they are "nodal" and assigned to a nodeset that doesn't exist but a sideset does exist with that same ID (or vice versa). This needs to get fixed up.

Rationale for the enhancement or information for reproducing the error

We should enhance BoundaryRestrictable so that it understands whether the object is being restricted to sidesets or nodesets and can do the appropriate check.

Identified impact

Limited internal API modifications. User developed objects most likely won't inherit directly from BoundaryRestrictable so changing that API shouldn't effect most applications (I'm sure there will be one or two though!)

@friedmud friedmud self-assigned this May 17, 2016
@friedmud friedmud added C: Framework T: task An enhancement to the software. P: normal A defect affecting operation with a low possibility of significantly affects. labels May 17, 2016
friedmud added a commit to friedmud/moose that referenced this issue May 17, 2016
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