Dependency Resolution for MOOSE

[permcody]

This is a big one:

We talked about changing MOOSE so that we can have dependency resolution based on which objects insid of which systems are coupled to one and other.

The idea is to change the coupling interfaces so that when values from any system are requested we keep track of the parent system and the object itself in the DependencyResolver. One idea is to have a pure virtual function in the coupling interface so that derived classes will supply their own system names so we don't have to do any RTTI. Once he have that done we should be able to determine a minimum execution order for any simulation based on the objects enabled for that simulation.

There are further extensions to this that we'll get to later where we'll be able to optimize this so that we'll be able to do all of these calculations in a single loop or "minimum" number of loops in cycles are present.

[friedmud]

A few more notes on this. Firstly, Cody and I have discussed this at length... so what is captured above represents our initial design.

This is really going to end up looking a lot like the Action system. We're going to have dependencies to be resolved and actions taken to resolve them. Is there any way we can just reuse that system? The "Actions" in this case will be things like "SerializeSolutionVector" and "ComputeKernelResiduals"...

[permcody]

In 04496ec1cd18dbb7cbff433d907b2336b0fb5214:

Dependency Resolution for UO and AuxKernels - refs #1050

[friedmud]

Added a diagram of the first "DAG" stuff we're going to do... which is in the element computation during residual evaluation.

[friedmud]

In ticket #1704 Yaqi was wanting to selectively re-evaluate Materials based on if they're going to be used or not. That would be a great first step for this system.

[friedmud]

Another note on this - I just ran into an interesting case. If the mesh displacements are computed by AuxKernels... then we need to make sure that those AuxKernels are computed before displacing the mesh (especially for initial residual computation).

This might involve putting a "MeshDisplacer" object into the dependency tree. It would need to depend on any objects that were computing into the fields specified to be the "displacements"....

Tricky.

[permcody]

The current idea is to make MooseObject inherit from the DependencyResolverInterface, the constructor for DependencyResolverInterface would also take the "this" pointer. The idea is that we would then add a call in each Interface throughout MOOSE to declare the dependency for the current object.

i.e. In "getPostprocessor()" we'd have a line like "addDependency(name)" and getDependentObjects(). Is there a better word than dependents and dependencies? Why are those words so damn close but mean completely different things?

[friedmud]

The constructor for DependencyResolverInterface wouldn't take this... the constructor for ALL other interfaces in MOOSE would take a DependencyResolverInterface *... for which we would pass this.

That way in getPostprocessor() we would call _dri->addDependency(name) where _dri is a DependencyResolverInterface * that is set to this

[aeslaughter]

We talked about this a bit a few weeks ago in the MOOSE cube and after spending a lot of time in the warehouses, I think we can get closer to complete dependency resolution by adding more intermediate base class objects:

MooseObject <--- ElementalMooseObject <--- ... (Anything that executes/computes on elements) MooseObject <--- NodalMooseObject <--- ... (Anything that executes/compute on nodes) MooseObject <--- ExecuteMooseObject <--- ... (Anything with a single execute call)

This would be able to resolve dependencies for each of the base class groups, of course, this wouldn't allow the dependencies between elemental and nodal to be resolved, but I am not sure we want that anyway: having a node loop, element loop, node loop, etc. seems like a bad idea.

Just wanted to get this written down since we talked about it.

[permcody]

Yeah, we've talked about this before and making it happen isn't quite as difficult as the implication for performance. Good to write things down though.

On Mon, Dec 14, 2015 at 8:35 AM Andrew E Slaughter notifications@github.com wrote:

We talked about this a bit a few weeks ago in the MOOSE cube and after spending a lot of time in the warehouses, I think we can get closer to complete dependency resolution by adding more intermediate base class objects:

MooseObject <--- ElementalMooseObject <--- ... (Anything that executes/computes on elements) MooseObject <--- NodalMooseObject <--- ... (Anything that executes/compute on nodes) MooseObject <--- ExecuteMooseObject <--- ... (Anything with a single execute call)

This would be able to resolve dependencies for each of the base class groups, of course, this wouldn't allow the dependencies between elemental and nodal to be resolved, but I am not sure we want that anyway: having a node loop, element loop, node loop, etc. seems like a bad idea.

Just wanted to get this written down since we talked about it.

— Reply to this email directly or view it on GitHub https://github.com/idaholab/moose/issues/1050#issuecomment-164469061.

[friedmud]

In the case where you have an element->node->element->node dependency... I don't see anything wrong with running the loops multiple times. It's up to users to decide whether or not it's necessary for their application...

The idea of intermediate classes could work... I've talked about "binning" objects that can execute simultaneously before... that could be one way to do it.

[friedmud]

Actually: a worse situation is when you have element->element dependencies... it means that you might need to run the element loop twice in a row!

[permcody]

This is a moving target. We keep talking about new ways of handling it. We have improved the interfaces enough that we can get more information in most cases. Regardless, we'll close this ticket and move discussion to the newer ticket: #6369