DerivativeBaseMaterial variable coupling

[dschwen]

Currently DerivativeBaseMaterial defined an args catchall parameter for all coupled variables for a derivative material. This parameter needs to be moved into child classes and potentially be replaced with individual named addRequiredCoupledVar parameters.

Rather than enumerating the args variable vector DerivativeBaseMaterial will use _coupled_moose_vars to enumerate all coupled variables. This will allow child classes better control over coupled variables.

Please assign to me.

[dschwen]

@permcody , I factored out stuff into Coupleable::coupledValue(MooseVariable * var). Does that seem like the way to go? I could then do the same for the Old and Gradient methods.

[permcody]

@dschwen Would you capture our conversation and create a summary and design of the proposed changes for posterity? We need to document why this is changing. I'm going to mark this as high risk which means that it'll will contain some design information. Thanks!

[dschwen]

In short the idea is to handle coupling and some dependency resolution at MooseVariable level, rather than utilizing var_name (which is actually an input parameter name that can refer to a vector of coupled variables.

I am factoring out the core of all coupled(Value|Gradient|Second)(|Old|Older) etc. methods into an overloaded method that takes a MooseVariable as an argument, rather than a var_name, component pair. The coupledCallback is changed accordingly to accept a single MooseVariable``. Its overridden version inAuxKernel``` will now only remove the dependency on the passed in variable and not the entire coupled variable vector.

This refactoring will allow classes to operate on the _coupled_moose_vars vector, which is agnostic to how a variable was coupled (through one single input file parameter and vector coupling or through multiple single input parameters). This can be useful in base classes that need to do common tasks on all coupled variables, such as the DerivativeBaseMaterial.

df622f1 implements this proposed change.

[dschwen]

I'll add two PRs for this now. A first one for the framework change and a second one for the Derivative Material System changes (which will require application patches, and will depend on the first one). The holidays are coming up and if I don't open the PRs now I'll have forgotten what I was doing. These PRs are intended for discussion and to abuse the automatic testing.