Support vector of variables with InitialConditions

[permcody]

Description of the enhancement or error report

Currently in MOOSE, each variable must have a separate initial condition object. This has served us well over the years but there are reasons to generalize this a bit more for certain situations: phase-field and potentially transport where we have groups of variables that are all somewhat related and may be able to leverage similar logic for initialization.

For the phase-field case I have a specific goal in mind. Right now for initializing polycrystal structures we build a Voronoi tesselation and determine which element belong to each grain by calculating minimum distances to each grain center for every point in the domain. We repeat the tesselation and grain center minimization logic for each order parameter that we create. While this isn't terribly expensive yet, it's not very scalable. With the addition of graph coloring algorithms for the distribution of order parameters to grains, this up front logic can take a significant amount of time for a single IC, so we only want to run that logic once per simulation. Right now we are forced to either run the logic over and over again, or factor out all of the logic into a UserObject and abuse the initialSetup method to "execute" the logic before the initial condition runs. This solution is rather terrible.

Rationale for the enhancement or information for reproducing the error

I'm proposing that we promote the variable parameter to a vector so that similar variables may use the same object for initialization. Some important design aspects:

1. Nothing will change for existing single variable initial condition.
2. If a vector of variables is coupled in, we'll simply run the same initial condition several times with subsequent variables.

Later we'll be able to further optimize the initial condition setting logic by setting all of the initial conditions on all variables with a single pass through the mesh structure.

Identified impact

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

This is a large design change but shouldn't change the functionality of MOOSE.

Tag @idaholab/moose-team

[andrsd]

We could introduce VectorInitialCondition that has:

virtual std::vector<Real> value(const Point & p) = 0;

if we wanted to keep similarity with the current API. This would probably require a common base class for initial conditions, because value already exists in InitialCondition. Also, the common logic between InitialCondition and VectorInitialCondition would be moved into that common base class.

[permcody]

@andrsd - I don't think I want to go this direction for one simple reason, it's inconsistent with MOOSE. I already coded this up and it works but I don't like it. Currently there's no other system that takes a vector for the variable = parameter in the input file.

[andrsd]

The vector-valued variables are still planned, right? I thought, eventually, there would be things like VectorKernel, VectorBoundaryCondition, etc. But if the plan is different, it is fine with me...

[permcody]

Yes, but that would be a new type altogether and probably still just one of those. We have another plan to make the polycrystal ICs work better.

[aeslaughter]

On Thu, Apr 13, 2017 at 8:43 AM, Cody Permann notifications@github.com wrote:

@andrsd https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_andrsd&d=DwMFaQ&c=54IZrppPQZKX9mLzcGdPfFD1hxrcB__aEkJFOKJFd00&r=h7heP8xwI1i_HikChvhFbEBurKirgfOCdwgBxB9lM8c&m=_uWLQNpP94DsCeFfghp3IN4VK45Z_J-Mac7Jw9PaDZ0&s=_gtJU_e4dwk0N2eX4smqFZ3DbO0R8Lb7xtVxoaxFjM4&e=

• I don't think I want to go this direction for one simple reason, it's inconsistent with MOOSE. I already coded this up and it works but I don't like it. Currently there's no other system that takes a vector for the variable = parameter in the input file.

Not completely true, we list a vector for "displacements".

— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_idaholab_moose_issues_8878-23issuecomment-2D293915784&d=DwMFaQ&c=54IZrppPQZKX9mLzcGdPfFD1hxrcB__aEkJFOKJFd00&r=h7heP8xwI1i_HikChvhFbEBurKirgfOCdwgBxB9lM8c&m=_uWLQNpP94DsCeFfghp3IN4VK45Z_J-Mac7Jw9PaDZ0&s=7wryPANwsMXDYu7O8WohoDBmogVAGf51SmDG-6Pchds&e=, or mute the thread https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AAU1VbY4wgdRGF3g-2DioPJutDV-5F9mAe2Wks5rvjSFgaJpZM4M10G9&d=DwMFaQ&c=54IZrppPQZKX9mLzcGdPfFD1hxrcB__aEkJFOKJFd00&r=h7heP8xwI1i_HikChvhFbEBurKirgfOCdwgBxB9lM8c&m=_uWLQNpP94DsCeFfghp3IN4VK45Z_J-Mac7Jw9PaDZ0&s=86sCsEjUXg9n9oCDna7RXGVdmby7NcfehXub7ray-S8&e= .