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

Make getDefaultMaterialProperty work correctly with block restrictions #5055

Closed
dschwen opened this issue May 12, 2015 · 2 comments
Closed
Assignees
Labels
C: Framework P: normal A defect affecting operation with a low possibility of significantly affects. T: defect An anomaly, which is anything that deviates from expectations.

Comments

@dschwen
Copy link
Member

dschwen commented May 12, 2015

getDefaultMaterialProperty is currently not working correctly when used on multiple blocks. This is due to hasMaterialProperty not being block restricted. Using hasBlockMaterialProperty should fix this. @jasondhales encountered this bug.

Assign to me.

dschwen added a commit to dschwen/moose that referenced this issue May 12, 2015
@aeslaughter aeslaughter added C: Framework T: defect An anomaly, which is anything that deviates from expectations. P: normal A defect affecting operation with a low possibility of significantly affects. labels May 12, 2015
@aeslaughter aeslaughter assigned friedmud and dschwen and unassigned friedmud May 12, 2015
@jasondhales
Copy link
Contributor

Another wrinkle. In the example I showed Daniel, multiple mesh blocks need
the same material for a solid mechanics application. Since this material
is created three times (once for x, once for y, and once for z
displacements), the second two times getDefaultMaterialProperty is called
for a mesh block, it will see that the MatProp has been declared. However,
none of those materials compute the property, and the code errors
out. Any ideas outside of vector variables in MOOSE?

@dschwen
Copy link
Member Author

dschwen commented May 14, 2015

cfd4468 adds a new test (which fails in current moose) to demonstrate the problem (and to protect us from regressions once it is fixed)

aeslaughter added a commit to aeslaughter/moose that referenced this issue May 21, 2015
aeslaughter added a commit to aeslaughter/moose that referenced this issue May 21, 2015
aeslaughter added a commit to aeslaughter/moose that referenced this issue May 21, 2015
aeslaughter added a commit to aeslaughter/moose that referenced this issue May 21, 2015
aeslaughter added a commit to aeslaughter/moose that referenced this issue May 21, 2015
bwspenc pushed a commit to bwspenc/moose that referenced this issue May 22, 2015
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: defect An anomaly, which is anything that deviates from expectations.
Projects
None yet
Development

No branches or pull requests

4 participants