-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Dependency Resolution for MOOSE #1050
Comments
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"... |
In 04496ec:
|
Added a diagram of the first "DAG" stuff we're going to do... which is in the element computation during residual evaluation. |
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. |
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. |
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? |
The constructor for That way in |
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) 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. |
Yeah, we've talked about this before and making it happen isn't quite as On Mon, Dec 14, 2015 at 8:35 AM Andrew E Slaughter notifications@github.com
|
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. |
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! |
(MooseObject *) refs idaholab#1050
(MooseObject *) refs idaholab#1050
Change constructor of GeometricSearchInterface (MooseObject *) refs idaholab#1050
(MooseObject *) refs idaholab#1050
MooseInterface and Dependency Resolution refs idaholab#1050, idaholab#6672
MooseInterface and Dependency Resolution refs idaholab#1050, idaholab#6672
MooseInterface and Dependency Resolution refs idaholab#1050, idaholab#6672
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 |
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.
The text was updated successfully, but these errors were encountered: