MaterialPropertyInterface::hasMaterialProperty not quite right for multi-block

[friedmud]

MaterialPropertyInterface::hasMaterialProperty() will return true even if on this block that material property is not defined.

To test, setup a system with two blocks... have a Kernel defined over the whole domain that could use a material property named "foo" (but is fine without it). Have "foo" only defined on one block.

If you use the normal construction to check to see if that material property exists and if so then to get its reference... then you will get an error saying "no material named foo defined on block 2" or whatever. This is because hasMaterialProperty() will return true as long as that property exists somewhere in the domain.

[permcody]

David removed missing_material_test - let's make sure that we do the right thing if a material is only defined on a subset of the blocks in the domain and a kernel that requires a material property over all the domains is in the simulation. This will essentially cover what was just removed.

[andrsd]

I removed that test, because it was wrong. It did not use any kernels that would need any materials. That test came from the time when materials were required - that is no longer true with MOOSE (for over a year now ;-)). So that test can come back but it needs to have kernels that actually need some material properties...

[aeslaughter]

I have a patch that fixes the problem with hasMaterialProperty. The patch moves this function to BlockRestrictable class. This allows for the blocks associated with the material (FEProblem::getMaterialPropertyBlocks) to be tested agains the blocks of the object.

Keeping hasMaterialProperty inside of MaterialInterface is problematic b/c it does not have access to the object blocks. The old method simply called the MaterialData::haveProperty, which return true if the property existed, regardless if the property was restricted.

I have not committed the patch b/c it will break applications, I need to implement this feature in BoundaryRestrictable (#2149) before everything will be working.

[aeslaughter]

In b58084d:

Created hasBoundaryMaterialProperty and hasBlockMaterialProperty methods associated with the Boundary/BlockRestrictable interfaces; hasMaterialProperty retains the original behavior (true if the material exists anywhere), while the new commands only return true if they are defined on the same blocks as the calling object (refs #1228)

[aeslaughter]

In de32d6b:

Fixed problem with debug moose_test (refs #1228)

[aeslaughter]

In 184818b:

Add parameter check in BlockRestrictable (refs #1228)