Add phase selection to ReconVarIC

[dschwen]

This enables

If I want to assign only the grains from a specific phase from the EBSD file to order parameters , I use ReconVarICAction and provide the phase number (phase = 2).

It also adds a test for this new mode.

In this patch all grain numbers start at zero internally. We store grain data in vectors and having an empty element at the start of a vector is not elegant. @permcody we may need to talk about this again (zero being a special value in GrainTracker?). Anyhow this offset business is confusing. I propose we have offsets at read-time (in case grain numbers start at one in the EBSD data file), internally store everything zero-based, and maybe have an option in the grain number auxkernel to shift back to the numbers in the ebsd file. This would give us the most flexibility .

Ping @frombs

Closes #5502

[tonkmr]

This looks good to me. It should finish up the full range of use cases we may have with EBSDReader.

[frombs]

@dschwen, did you implement your suggestion to perform the offset in EBSDReader? Dream3D currently outputs feature IDs starting at 1. I have been performing an additional step in MATLAB to renumber starting at 0. This is not ideal for other users. Either the offset needs to be performed in EBSDReader or I need to contact the Dream3D developers and ask for the capability to number the features starting at 0.

Are the new changes compatible with GrainTracker?

Can multiple instances of GrainTracker be run simultaneously in the case with multiple phases that contain many grains?

[dschwen]

@frombs the renumbering fix in EBSDReader is not yet in, but that'd be a 5min job. I'll talk to @permcody about GrainTracker

[dschwen]

I've decided to implement the id shifting. In this process I will rename a few concepts. I hope this makes stuff clearer:

Grains are indexed through multiple schemes:

• feature_id The grain number in the EBSD data file
• global_id The index into the global average data list
• local_id The index into the per-phase grain list. This is only unique when combined with phase number

I'm adding the feature_id_origin input parameter to the EBSDMesh class which allows users to specify where their feature ID numbering starts in the file. This will default to the Dream3D default, which I believe is 1 currently.

Phases are referred to using the numbers in the EBSD data file. In case the phase number in the data file starts at 1 the phase 0 will simply contain no grains.

[dschwen]

Actually this is all crap. I will renumber at will. This will make the feature_id_origin obsolete. This will be of tremendous help when cropping EBSD files (which yields discontinuous feature IDs)! I'll edit the post above accordingly.

[dschwen]

e4e811b implements these ideas. I'll adapt the AuxKernel to recover the EBSD file feature IDs. That commit adds a test file with arbitrarily assigned non-contiguous feature IDs (3,5,7,12).

[tonkmr]

This sounds great. Maximum flexibility is definitely what we want.

[dschwen]

Ok, I've added a test for this as well. However currently only TestEBSDAux does the right thing automatically. We still need to make the GrainTracker not report back internal IDs but original Feature numbers. That should be easy!

[dschwen]

This can be merged as is. Once #5931 is implemented I will add an AuxKernel that outputs the original feature IDs rather than the internal GrainTracker grain numbers.

[jwpeterson]

I'll wait for @permcody to merge this since it involves the grain tracker...

[permcody]

👍