search

idaholab / moose

Multiphysics Object Oriented Simulation Environment
https://www.mooseframework.org
GNU Lesser General Public License v2.1
1.71k stars 1.04k forks source link

PolycrystalICs need to be more efficient #8810

Closed permcody closed 7 years ago

permcody commented 7 years ago

Description of the enhancement or error report

With the necessity of running graph coloring algorithms to setup a reduced order parameter model, we need to be smarter about how we set up polycrystal ICs for multiple variables. Right now each IC performs the same logic for each variable including building a full graph and coloring it. This is really expensive (PolycrystalReducedIC, ReconVarIC).

Rationale for the enhancement or information for reproducing the error

Some of the graph coloring algorithms may take several seconds to run per variable under certain conditions and we have to do this for each variable even though the graph doesn't change. The problem is that in order to accomplish this, we'll need to share data across ICs somehow. I'm not really coming up with an elegant solution right now. We could have the ICs access the ICs warehouse looking for the zeroth version of a similar variable and harvesting it's data structures. Since we use these ICs through Actions in all cases. We could have the Action create a shared object that gets used by everyone. I like this except it really means we wouldn't be able to use those ICs without the Action.

Identified impact

(i.e. Internal object changes, limited interface changes, public API change, or a list of specific applications impacted)

More efficient ICs

dschwen commented 7 years ago

We are already using actions for those ICs! I think having a generic action and then a set of user objects for the various types of ICs might be a design worth exploring.

permcody commented 7 years ago

OK - I have a half baked branch that's working on the Voronoi type problems: https://github.com/permcody/moose/tree/ic_refactor_newest

It dawned on me that rather than having two UserObjects working with each other to set up initial conditions, I might as well use one. So..... The new design is that PolycrystalUserObjectBase now inherits from FeatureFloodCount and does all of the "one off" logic of finding grain neighbors and building the adjacency matrix all inside one object. This make a lot of sense because we are inspecting grain information in this new object, but the GrainTracker is actually inspecting order parameter information which isn't quite the same thing. As I continue working through this branch, it'll actually mean that i can remove all of the specialized EBSD logic from the GrainTracker which I really like! Anyway, I'm looking for feedback on this design as I think this is it.

permcody commented 7 years ago

@laagesen, @dschwen - I'm still trying to decide on the right interface for these new IC objects. I had originally told you that I wanted it to be something like "get GrainID(s) (or featureID(s)) per element". However, I already found out that that interface is insufficient even for the simple Voronoi tessellation case when we have initial adaptivity turned on. The problem is that these new UserObjects run once before the initial condition must run all of the heavy logic to figure out grain neighbors and op parameter assignments once. Sure we can query these "const" UOs later for information and that happens when the ICs are needed but it also happens if we need to re-project the IC, but we'll be seeing new elements that we haven't seen before. My first thought was, OK, I'll just see if these new elements have a parent we've seen before, and that worked but of course completely defeats the purpose of adapting to the initial condition, since we don't get a better resolution of the grain boundaries that way.

So now I'm debating on whether the IC should just be "get grain ID(s) or feature ID(s) at a point". For Voronoi, this is natural. For EBSD, we can build a coarse element to grain map, then use point locator to figure out which element we are in and return the corresponding ID (Daniel, I realize that you attempted to put in a method to the EBSD reader that returns data based on a point, but I seem to recall that it didn't work quite right).

These are basically the two types of Polycrystal ICs that I'm aware of: "fixed resolution" like EBSD, or adaptive like "Voronoi". Am I missing any other normal use case?

laagesen commented 7 years ago

Hey Cody, traveling back from Phoenix today - will try to provide some comments tomorrow...

laagesen commented 7 years ago

I think the distinction between fixed resolution and adaptive ICs covers everything.

As far as I know, the only features other than grains that are made in any of the current IC's are circles/spheres of a single other phase. This may be what you already had in mind with making this system more flexible, but it would be nice to have the capability to add features other than spheres- for instance, ellipsoids or lenticular bubbles.