Compute Material Properties at DiracKernel points #2967
Conversation
You can now specify whether or not the 'swap' step for stateful materials occurs. Refs idaholab#2379.
|
Results of testing 62f59db using moose_PR_pre_test recipe: Passed on: linux View the results here: https://www.moosebuild.com/view_job/1498 |
|
Results of testing 62f59db using moose_PR_test recipe: Failed on: linux View the results here: https://www.moosebuild.com/view_job/1499 |
|
OK @WilkAndy it was just the |
|
Yes, please re-gold and send me the exodus file, John. With this PR I will have to re-explore all my dirac tests anyway, but I need the PR into devel before that is easy for me to do. a From: jwpeterson <notifications@github.commailto:notifications@github.com> OK @WilkAndyhttps://github.com/WilkAndy it was just the dirac.test_bh07 test which exodiffed on moosebuild, and you can see the diff on the link above. Let me know if you are OK with regolding and I will add another patch to this PR, I can also send you the Exodus file I get on my system if you'd like to take a closer look. — |
OK, will do. |
* Reinitialize materials before computing Dirac kernels, but only if those DiracKernels actually call getMaterialProperty(). * Adding MaterialPropertyInterface::statefulPropertiesAllowed(bool). This allows classes derived from MaterialPropertyInterface to declare that they do not work with stateful material properties. The only class which currently uses this functionality is the DiracKernel. The various getMaterialProperty*() interfaces have been updated to throw an error is stateful material properties are not allowed and the user asks for them. Note that only the MaterialPropertyStorage object knows if it has stateful material properties, so we had to provide an accessor from the MaterialData object which contains it that could be accessed by the MaterialPropertyInterface. Refs idaholab#2379.
Only swap back if the MaterialData has been swapped in the first place. Refs idaholab#2379.
| if ((*dirac_kernel_it)->getMaterialPropertyCalled()) | ||
| { | ||
| need_reinit_materials = true; | ||
| break; |
There was a problem hiding this comment.
Hah - I was trying to leave a comment about this issue - but you spotted it before I did and fixed it ;-)
There was a problem hiding this comment.
Damn, tried to sneak that one in there...
|
Results of testing a1b0d02 using moose_PR_pre_test recipe: Passed on: linux View the results here: https://www.moosebuild.com/view_job/1515 |
|
|
||
| // Note that we do not call swapBackMaterials() here as they were | ||
| // never swapped in the first place. This avoids messing up | ||
| // stored values of stateful material properties. |
There was a problem hiding this comment.
Good idea to put this comment here!
|
Results of testing a1b0d02 using moose_PR_test recipe: Passed on: linux View the results here: https://www.moosebuild.com/view_job/1516 |
It is a DiracKernel test that uses a MaterialProperty, as has been implemented by an earlier patch on this branch. If uncommented, the print statement in MaterialPointSource::computeQpResidual() should show that the MaterialProperty is being correctly evaluated at the DiracKernel point. Refs idaholab#2379.
stateful material property with a DiracKernel. Refs idaholab#2379.
…ing a NULL pointer. Refs idaholab#2379.
|
Results of testing 3ed6ece using moose_PR_pre_test recipe: Passed on: linux View the results here: https://www.moosebuild.com/view_job/1519 |
|
Results of testing 3ed6ece using moose_PR_test recipe: Passed on: linux View the results here: https://www.moosebuild.com/view_job/1520 |
Compute Material Properties at DiracKernel points
|
Great job John! Thanks for doing this! |
|
Yes, thanks John,. I’ll look at that bh07.e you sent in more detail over the coming days, but by eye it looks absolutely fine. Also all my other dirac tests will need to be re-visited, and I will probably make some more now. I’m so pleased this Materials stuff is done, thanks, a From: Derek Gaston <notifications@github.commailto:notifications@github.com> Great job John! Thanks for doing this! — |
This branch adds the ability to evaluate and use material properties at the points of DiracKernels, which was not supported before. Stateful material properties are currently not supported for DiracKernels, however. If you try to access one from a DiracKernel, MOOSE will throw an error.
@WilkAndy, this branch causes two of your tests
to diff for me. This may due to them not using correct MaterialProperty values before, so perhaps those tests could just be re-golded. Let me know if you have any questions.
Refs #2379.